Subject: [TLS] WGLC for draft-ietf-tls-ecc

From: Eric Rescorla <[email-masked]>
Date: Fri, 08 Apr 2005 18:56:16 -0700

This is a Working Group Last Call for draft-ietf-tls-ecc-09.txt
The target status for this document is Information.

Please send comments to the mailing list as followups to this
message.

The Last Call will last for two weeks, ending on April 22.
Note: I will be out of e-mail contact for 2 weeks starting
April 20th, so in practice I won't be able to deal with 
comments before May 5th.

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Nils Larsch <[email-masked]>
Date: Wed, 13 Apr 2005 20:06:08 +0200

some comments:

 > 5.1  Client Hello Extensions
...
 >         enum { uncompressed (0), ansiX962_compressed (1),
 >                ansiX962_hybrid (2), reserved (3 .. 255)
 >         } ECPointFormat;
 >
 >         struct {
 >             ECPointFormat ec_point_format_list<1..28-1>
 >         } ECPointFormatList;
 >
 >    Three point formats are included in the definition of ECPointFormat
 >    above.  The uncompressed point format is the default format in that
 >    implementations of this document MUST support it.  The
 >    ansiX962_compressed format reduces bandwidth by including only the
 >    x-coordinate and a single bit of the y-coordinate of the point.  The
 >    ansiX962_hybrid format includes both the full y-coordinate and the
 >    compressed y-coordinate to allow flexibility and improve efficiency
 >    in some cases.  Implementations of this document MAY support the
 >    ansiX962_compressed and ansiX962_hybrid point formats.  (These three
 >    formats are described in [6].)  Values 248 through 255 are reserved
 >    for private use.

what's the pratical value of including the hybrid format ?

 >    Items in ec_point_format_list are ordered according to the client's
 >    preferences (favorite choice first).
 >
 >    A client that can parse only the uncompressed point format includes
 >    an extension consisting of the following octets:
 >
 >         00 ?? 00 02 01 00
 >
 >    A client that prefers the use of the ansiX962_compressed format over
 >    uncompressed may indicate that preference by including an extension
 >    consisting of the following octets:
 >
 >         00 ?? 00 03 02 01 00

this is somewhat problematic: for example openssl (0.9.8-dev) should
support every of the above mentioned named curves and it can handle
compressed points for GF(p) as well (as the point compression algorithm
for characteristic 2 is patented point compression for GF(2^m) curves is
disabled by default in openssl). But there's no way in express this using
the above extensions: one can either list every supported curve and offer
no point compression or restrict the list of curves to "prime"-curves and
offer point compression.

...
 > 5.3  Server Certificate
...
 >    Actions of the sender:
 >
 >    The server constructs an appropriate certificate chain and conveys it
 >    to the client in the Certificate message.  If the client has used a
 >    Supported Elliptic Curves Extension, the public key in the server's
 >    certificate MUST respect the client's choice of elliptic curves; in
 >    particular, the public key MUST employ a named curve (not the same
 >    curve as an explicit curve) unless the client has indicated support
 >    for explicit curves of the appropriate type.  If the client has used
 >    a Supported Point Formats Extension, both the server's public key
 >    point and (in the case of an explicit curve) the curve's base point

every ec point appearing in the cert chain must adhere to the supported
point format and not only the public key and the generator of the server
certificate (otherwise the client might be unable to verify the cert chain).

 >    MUST respect the client's choice of point formats.  (A server that
 >    cannot satisfy these requirements must not choose an ECC cipher suite
 >    in its ServerHello message.)
...
 >
 > 5.9  Elliptic Curve Certificates
 >
 >    X509 certificates containing ECC public keys or signed using ECDSA
 >    MUST comply with [11] or another RFC that replaces or extends it.

as no one knows what will be in future versions of these RFCs this
might be challenging to implement ;-)

 >    Clients SHOULD use the elliptic curve domain parameters recommended
 >    in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
 >
 > 5.10  ECDH, ECDSA and RSA Computations
 >
 >    All ECDH calculations (including parameter and key generation as well
 >    as the shared secret calculation) MUST be performed according to [5]
 >
 >
 >
 > Gupta, et al.            Expires October 9, 2005               [Page 26]
 >
 > Internet-Draft          ECC Cipher Suites for TLS             April 2005
 >
 >
 >    using the ECKAS-DH1 scheme with the identity map as key derivation
 >    function, so that the premaster secret is the x-coordinate of the
 >    ECDH shared secret elliptic curve point, i.e. the octet string Z in
 >    IEEE 1363 terminology.
 >
 >    Note that a new extension may be introduced in the future to allow
 >    the use of a different KDF during computation of the premaster
 >    secret.  In this event, the new KDF would be used in place of the
 >    process detailed above.  This may be desirable, for example, to
 >    support compatibility with the planned NIST key agreement standard.
 >
 >    All ECDSA computations MUST be performed according to ANSI X9.62 [6]
 >    or its successors.  Data to be signed/verified is hashed and the
 >    result run directly through the ECDSA algorithm with no additional
 >    hashing.  The default hash function is SHA-1 [7] and sha_size (see
 >    Section 5.4 and Section 5.8) is 20.  However, an alternative hash
 >    function, such as one of the new SHA hash functions specified in FIPS
 >    180-2 [7], may be used instead if the certificate containing the EC
 >    public key explicitly requires use of another hash function.  (The
 >    mechanism for specifying the required hash function has not been
 >    standardized but this provision anticipates such standardization and
 >    obviates the need to update this document in response.  Future PKIX
 >    RFCs may choose, for example, to specify the hash function to be used
 >    with a public key in the parameters field of subjectPublicKeyInfo.)

the ability whether or not the client/server supports the new ecc asn.1
features should perhaps be indicated in yet another tls extension

Cheers,
Nils

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 13 Apr 2005 15:10:23 -0600

On Wed, Apr 13, 2005 at 08:06:08PM +0200, Nils Larsch wrote:

>> [...] draft-ietf-tls-ecc-09.txt

> some comments:

Thanks for the comments.  All these are issues that I have previously
considered.  This does, of course, not necessarily mean that my
answers as given below are the best ones, so you are certainly invited
to argue against them :-)

> what's the pratical value of including the hybrid format ?

The practical value surely is very limited; support for hybrid format
is mostly for completeness, given existing standards that allow it.
(If someone has an ECC certificate that happens to use hybrid format,
this allows them to use it for TLS.)  These are small advantages, but
then this is a simple thing to add to the protocol -- support for the
hybrid format is completely optional, after all.

> no point compression or restrict the list of curves to "prime"-curves and

Yes, I am aware of this restriction.  My reason for keeping the
ECPointFormat type as above was that generally the default format,
uncompressed, is a very good choice anyway (it means just a few more
bytes and its use can usually save some computation time), and that
the restriction keeps the protocol a little simpler and the TLS
extensions a little shorter.

Point formats other than uncompressed are most likely to be of use in
closed environments, e.g. to accommodate specific certificates.  In
such scenarios, common parameters will have been somehow negotiated
offline anyway, such as by deploying clients that support only a
single curve in the first place.  Then the online negotiation through
TLS extensions would be just to confirm that the current handshake can
really finish as expected (so that the server can switch to
appropriate parameters, e.g. an RSA certificate, when an "outsider"
client connects).

On the other hand, servers meant to use ECC certificates with any
ECC-capable client, friend or foe, will need certificates employing
the uncompressed format anyway.  Thus, point format negotiation has
considerable less value in such open scenarios.

So the short design rationale is as follows:

- Point format negotiation can be important for some closed
  environments;

- but point format negotiation is not important enough that we have to
  bother doing it in a perfectly flexible way.

Now obviously this is just one way to view it.  Would you prefer
to have more fine-grained ECPointFormat values, such as

    uncompressed,
    ansiX962_compressed_prime,
    anxiX962_compressed_char2,
    ansiX962_hybrid_prime,
    ansiX962_hybrid_char2

?  This would't be too complicated either.  And, possibly more
importantly, this set of possibilities would be easier to explain :-)

If this is preferred, I wouldn't mind changing the specification
accordingly.

> certificate (otherwise the client might be unable to verify the cert chain).

I am aware of the possible certificate chain verification problem.
The specification is meant to guarantee that the key exchange can
proceed without problems, but not necessarily that certificate
verification is always possible.  Keep in mind that certificate
verification can fail due to other reasons, notably due to an unknown
root CA, or various features present in X.509 certificates (such as
unknown extensions that are tagged critical).  We cannot avoid all of
these problems in general.

If the client uses the trusted_ca_keys TLS extension from RFC 3546,
then problem of encountering a totally unknown root CA can be avoided.
But in this case, the problem of unsupported point formats (or
unsupported curves, or various X.509 problems) can just as well be
avoided through CA policies: As long as the CAs stick to uncompressed
format as a good default, there will be no verification problems
(apart from the usual X.509 nightmare).

> might be challenging to implement ;-)

I am not sure about what the best wording would be here ...  I think,
however, that the current wording is reasonable (note that it's "or",
not "and", so this does not tell you that you have to support future
RFCs).

> features should perhaps be indicated in yet another tls extension

Possibly.  But here the same reasoning applies as above in the
comments for section 5.3: We cannot even hope to completely negotiate
every feature that may affect certificate verification; sometimes
authentication may fail because of this, but the handshake will
proceed anyay.  Any important additional details should be taken into
account in CA policies.

Bodo

---

From: Nils Larsch <[email-masked]>
Date: Wed, 20 Apr 2005 11:42:31 +0200

Bodo Moeller wrote:
...
> is mostly for completeness, given existing standards that allow it.

with the same reasoning one could include curves with normal basis,
but I guess no one really wants this

> hybrid format is completely optional, after all.

I would prefer not to include this point format unless there a
real use case for it (something I doubt)

> extensions a little shorter.

yep, but the price for this is that point compression is nearly
useless for open source software

> closed environments, e.g. to accommodate specific certificates.  In

I doubt that extensions are necessary in this case at all (as all
parameters, like point compression, are fixed)

...
> If this is preferred, I wouldn't mind changing the specification

I would prefer the more fine grained point compression values

> verification is always possible. 

if the cert verification fails a successful key exchange isn't that
useful

> Keep in mind that certificate

of course not, but if the client/server explicitly states that it
can handle only certain point compression format wouldn't it make
sense to use this information for the cert validation as well ?

Nils

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 20 Apr 2005 14:41:31 -0600

> but I guess no one really wants this

The difference is that normal basis representations would require
additional type specifications and explanations in the ECC-TLS
specification.  For hybrid format, it's just about saying how parties
can negotiate this format if they want; so the additional complexity
to the specification is marginal, given that the actual point format
is defined elsewhere.  (And hybrid format is purely optional, so the
additional effort for implementors is marginal too.)

What do others think on this?

> useless for open source software

But would you actually want to *use* point compression in the
handshake, or would you use the uncompressed format as the preferred
option anyway?

I can see some scenarios where this complication could become a
problem: A client supporting both prime fields and characteristic-2
fields talks to a server using an ECC certificate involving a prime
field, with a point given in compressed coordinates.  If the client
supports point compression only for prime fields, it cannot let the
server know that it does support point compression at all (because the
current extension would also imply point compression support for
characteristic-2 curves).  So no ECC handshake would be possible.

Hopefully, such scenarios wouldn't really occur in practice (why use a
server certificate with point compression in the first place?).  But
adapting the protocol to this possibility may still be a good idea.

> parameters, like point compression, are fixed)

For such scenarios, the extensions would be used to find out that the
current handshake is indeed taking place between parties that conform
to the agreement from the close group.  (The same client may also
connect to outside servers, switching to RSA if necessary; or a server
may also have connections from outside clients.)

But it is certainly true that more fine-grained ECPointFormat values

> I would prefer the more fine grained point compression values

OK.  Does anyone else have an opinion on this?

> if the cert verification fails a successful key exchange isn't that

This depends.  Sometimes verification is just about granting
additional rights: If authentication fails, the other party can still
get some business done, just with limitations.  (E.g., SMTP servers
will accept mail to local recipients from any sender; only mail
relaying requires successful authentication.)

> sense to use this information for the cert validation as well ?

If the other party has options in building the certificate chain, then
nothing in the specification prevents it from using this information.
But if it does not have such options, then sending a chain where the
root CA certificate or an intermediate CA certificate violates the
constraints does not main that verification is doomed to fail!  The
verifying party will not be able to use these particular certificates
for verification, due to its limitations.  However, it is possible
that the verifying party directly trusts a non-root CA occuring in the
chain and thus does not have to bother to even look at the problematic
root and intermediate CA certificates.