Subject: Re: [TLS] [Technical Errata Reported] RFC4492 (2389)

From: Sean Turner <[email-masked]>
Date: Wed, 23 Feb 2011 12:35:10 -0500

On 7/23/10 5:28 AM, Bodo Moeller wrote:
> On Jul 23, 2010, at 10:32 AM, RFC Errata System wrote:
>
>>
>> The following errata report has been submitted for RFC4492,
>> "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
>> Security (TLS)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=2389
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Juho Vähä-Herttua <[email-masked]>
>>
>> Section: 5.4
>>
>> Original Text
>> -------------
>> point: This is the byte string representation of an elliptic curve
>> point following the conversion routine in Section 4.3.6 of ANSI
>> X9.62 [7]. This byte string may represent an elliptic curve point
>> in uncompressed or compressed format; it MUST conform to what the
>> client has requested through a Supported Point Formats Extension
>> if this extension was used.
>>
>> enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
>>
>> ec_basis_trinomial: Indicates representation of a characteristic-2
>> field using a trinomial basis.
>>
>> ec_basis_pentanomial: Indicates representation of a
>> characteristic-2 field using a pentanomial basis.
>>
>> Corrected Text
>> --------------
>> point: This is the byte string representation of an elliptic curve
>> point following the conversion routine in Section 4.3.6 of ANSI
>> X9.62 [7]. This byte string may represent an elliptic curve point
>> in uncompressed or compressed format; it MUST conform to what the
>> client has requested through a Supported Point Formats Extension
>> if this extension was used.
>>
>> enum {
>> ec_basis_trinomial(1), ec_basis_pentanomial(2),
>> (255)
>> } ECBasisType;
>>
>> ec_basis_trinomial: Indicates representation of a characteristic-2
>> field using a trinomial basis.
>>
>> ec_basis_pentanomial: Indicates representation of a
>> characteristic-2 field using a pentanomial basis.
>>
>> Notes
>> -----
>> The ECBasisType enumeration is submitted as part of the ECParameters
>> structure and therefore needs numerical values. It is common to assign
>> numerical values starting from 1 to enums and maximum value of 255
>> should be enough, since currently there are only two known basis types
>> and it is unlikely to change in the near future.
>
> Thanks, Juho. Yes, the RFC text is wrong in not assigning enum values
> here, and the values that you suggest (1 and 2, with extra value 255 to
> clearly state the intended width) are the ones that the specification
> would have used.
>
> Using enum values 0 and 1 would have been equally possible, but this RFC
> tends to avoid value 0, except when specifying point compression in
> ECPointFormat, where 0 denotes the special "no compression" default. For
> ECBasisType, there's no similar special default.
>
> The implementations I'm aware of so far only provide named curves, i.e.
> ECBasisType is never actually encoded on the wire. If anyone knows an
> existing implementation supporting explicit characteristic-2 curves, I'd
> be glad to hear how it handles this issue -- I'd expect it would be
> using the enum values 1 and 2 as suggested here, but in case 0 and 1 are
> in actual use somewhere, we'd have to think about maintaining
> compatibility.
>
> Bodo

Bodo,

Finally getting around to this.  The question is whether the enum values 
are converted to external representation.  If they are not then it's 
okay that they're not there as 4.5 of TLS says:

   For enumerateds that are never converted to external representation,
   the numerical information may be omitted.

Are they converted?

There are two other places where enums aren't given values:

   enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

and

   enum { implicit, explicit } PublicValueEncoding;

Should these also be changed?

spt

>
>
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC4492 (draft-ietf-tls-ecc-12)
>> --------------------------------------
>> Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
>> Layer Security (TLS)
>> Publication Date : May 2006
>> Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
>> Category : INFORMATIONAL
>> Source : Transport Layer Security
>> Area : Security
>> Stream : IETF
>> Verifying Party : IESG
>
>

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 23 Feb 2011 21:37:43 +0200

On Feb 23, 2011, at 7:35 PM, Sean Turner wrote:
> Finally getting around to this.  The question is whether the enum values are converted to external representation.  If they are not then it's okay that they're not there as 4.5 of TLS says:
> 

The first "other place" is actually exactly the enum which was originally reported. The ECBasisType indeed is converted to external representation as can be seen in RFC 4492 section 5.4. struct ECParameters below the case explicit_char2. PublicValueEncoding instead is gotten from ClientCertificateType message and doesn't have external representation. As said in RFC 4492 section 5.7:

(This is "explicit"  in ECC cipher suites except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.)

The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) that aren't given values depend on cipher suite and don't need external representation. However, without the external representation of ECBasisType it is impossible for the parser to know if it should only parse "k" or "k1, k2 and k3" from the struct and it will fail, hence the errata.

Hope this helps, and feel free to correct me if necessary. I wasn't sure who the question was asked since the email was addressed to Bodo, but thought to clarify anyway.

Juho

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 24 Feb 2011 12:20:40 +0100

> > Should these also be changed?

The first "other place" is actually exactly the enum which was originally
> reported. The ECBasisType indeed is converted to external representation as
> can be seen in RFC 4492 section 5.4. struct ECParameters below the case
> explicit_char2. PublicValueEncoding instead is gotten from
> ClientCertificateType message and doesn't have external representation. As
> said in RFC 4492 section 5.7:
>
> (This is "explicit"  in ECC cipher suites except when the client uses the
> ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.)
>
> The other two enums (KeyExchangeAlgorithm and SignatureAlgorithm) that
> aren't given values depend on cipher suite and don't need external
> representation. However, without the external representation of ECBasisType
> it is impossible for the parser to know if it should only parse "k" or "k1,
> k2 and k3" from the struct and it will fail, hence the errata.
>
> Hope this helps, and feel free to correct me if necessary. I wasn't sure
> who the question was asked since the email was addressed to Bodo, but
> thought to clarify anyway.
>

Yes, thanks.

Just to avoid any confusion, let me clarify the context of my previous
statement that "ECBasisType is never actually encoded on the wire": this was
referring to my knowledge about *existing implementations*; it's clear from
the specification that you need to encode ECBasisType on the wire if you
support explicitly specified characteristic-2 curves for ECDHE ciphersuites.

Bodo