The contents of the SubjectPublicKeyInfo/algorithm field:

# tshark -r kudelski-vuln.pcapng -Y tls.handshake.certificate -O tls -ober.decode_unexpected:TRUE

    Algorithm Id: 1.2.840.10045.2.1 (id-ecPublicKey)
        SEQUENCE
            INTEGER: 1
            SEQUENCE
                OID: 1.2.840.10045.1.1 (ISO assigned OIDs, USA.10045.1.1)
                INTEGER: 0x00ffffffffffffffffffffffffffffffffffffffffffffff…
            SEQUENCE
                OCTETSTRING: ffffffffffffffffffffffffffffffffffffffffffffffff…
                OCTETSTRING: b3312fa7e23ee7e4988e056be3f82d19181d9c6efe814112…
                Padding: 0
                BITSTRING: a335926aa319a27a1d00896a6773a4827acdac73
            OCTETSTRING: 04d6eb7932e25502ae5151a3609384c13041904be25b912b…
            INTEGER: 0x00ffffffffffffffffffffffffffffffffffffffffffffff…
            INTEGER: 1

The OIDs above:

    id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }

    secp192r1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
     prime(1) 1 }

SubjectPublicKeyInfo/algorithm is an AlgorithmIdentifier from https://tools.ietf.org/html/rfc5480#section-2

      AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm   OBJECT IDENTIFIER,
        parameters  ANY DEFINED BY algorithm OPTIONAL
      }

For algorithm id-ecPublicKey, 'parameters' is defined by https://tools.ietf.org/html/rfc5480#section-2.1.1

     ECParameters ::= CHOICE {
       namedCurve         OBJECT IDENTIFIER
       -- implicitCurve   NULL
       -- specifiedCurve  SpecifiedECDomain
     }
       -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
       -- Details for SpecifiedECDomain can be found in [X9.62].
       -- Any future additions to this CHOICE should be coordinated
       -- with ANSI X9.

Heh, our sample does not look like an namedCurve of type OBJECT IDENTIFIER.
The X9.62 reference points to RFC 3279 where we can find more about explicitly specified curves in https://tools.ietf.org/html/rfc3279#section-2.3.5

      ECParameters ::= SEQUENCE {
         version   ECPVer,          -- version is always 1
         fieldID   FieldID,         -- identifies the finite field over
                                    -- which the curve is defined
         curve     Curve,           -- coefficients a and b of the
                                    -- elliptic curve
         base      ECPoint,         -- specifies the base point P
                                    -- on the elliptic curve
         order     INTEGER,         -- the order n of the base point
         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
         }

      ECPVer ::= INTEGER {ecpVer1(1)}

      FieldID ::= SEQUENCE {
         fieldType   OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY fieldType }

      Curve ::= SEQUENCE {
         a         FieldElement,
         b         FieldElement,
         seed      BIT STRING OPTIONAL }

      FieldElement ::= OCTET STRING

      ECPoint ::= OCTET STRING

I'll have a look at implementing it.

Change 35986 had a related patch set uploaded by Peter Wu:
pkcs1: recognize explicit curve parameters

https://code.wireshark.org/review/35986

With the proposed patch, Wireshark will now display:

    subjectPublicKeyInfo
        algorithm (id-ecPublicKey)
            Algorithm Id: 1.2.840.10045.2.1 (id-ecPublicKey)
            ECParameters: specifiedCurve (0)
                specifiedCurve
                    version: ecpVer1 (1)
                    fieldID
                        fieldType: 1.2.840.10045.1.1 (prime-field)
                        Prime-p: 0x00fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffff…
                    curve
                        a: fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffffff…
                        b: b3312fa7e23ee7e4988e056be3f82d19181d9c6efe8141120314088f5013875ac656398d…
                        Padding: 0
                        seed: a335926aa319a27a1d00896a6773a4827acdac73
                    base: 04d6eb7932e25502ae5151a3609384c13041904be25b912b77fe4333c0b1486fb0cd8155…
                    order: 0x00ffffffffffffffffffffffffffffffffffffffffffffffffc7634d81f4372ddf581a0d…
                    cofactor: 1

From the commit message:

    Add support for explicit curve parameters according to RFC 3279. This
    allows an exploitation attempt of CVE-2020-0601 to be detected through
    the pkcs1.specifiedCurve_element filter name. Be aware though that the
    certificate is encrypted in TLS 1.3, so a negative match does not imply
    that no exploitation has happened.

Change 35986 merged by Alexis La Goutte:
pkcs1: recognize explicit curve parameters

https://code.wireshark.org/review/35986

Fixed in v3.3.0rc0-465-gaaad273ec1