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

From: "Ari Medvinsky" <[email-masked]>
Date: Mon, 18 Apr 2005 14:02:47 -0700

I have a couple of questions/comments on this draft:

1)	The cipher suites defined in section 6 all use SHA1.  Although
from a security standpoint the use of SHA1 (or MD5 for that matter) is
not subject to the vulnerabilities that were recently discovered with
these hash functions - it would still be a good idea to define the new
cipher suites to use SHA 256 or SHA 512 .  For example, this would be
useful for compliance reasons (to eliminate all reliance on MD5/SHA1).

2)	Some additional verbiage/clarification is needed when using
ECDH_ECDSA & ECDHE_ECDSA.  For a client or server certificate chain
(e.g., length of chain is greater than 2) - do all the certificates in
the chain have to be based on ECDSA? Or are mixed crypto certs (signed
with RSA) allowed higher up in the chain? 

Ari Medvinsky
Program Manager
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Rescorla
Sent: Friday, April 08, 2005 6:56 PM
To: [email-masked]
Subject: [TLS] WGLC for draft-ietf-tls-ecc

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

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 19 Apr 2005 11:53:37 -0600

> useful for compliance reasons (to eliminate all reliance on MD5/SHA1).

This is of course a valid concern.  My reason for not adressing this
in draft-ietf-tls-ecc-09.txt was that this issue applies to all TLS
ciphersuites equally (the main TLS specification defines a few with
MD5 and many with SHA; various ciphersuites defined elsewehere use
SHA).  Additionally there's SHA-1 and MD5 in the TLS PRF
(pseudo-random function) used to derive keys from the handshake
secrets, and we can't define this away in the TLS-ECC specification
without violating the modularity of the TLS protocol design.

So my preferred solution to these issues would be to have a future
version of the TLS protocol (TLS 1.2, maybe?) specificy

- a new PRF not based on MD5 and SHA-1, and

- the use of a different MAC whenever ciphersuites that were
  originally defined for TLS 1.0 said "use SHA-1".

Then the hash issues won't have to be adressed independently for each
set of ciphersuites.  This way, we avoid allocating a huge number of
additional ciphersuite identifiers (which would happen if additional
spefications are written to define a SHA-256 version of each
ciphersuite originally defined with SHA-1).

> with RSA) allowed higher up in the chain? 

Here the rationale is based on the observation that the main TLS
specification does go into this level of detail either: It only says
that for the DH_DSS key exchange algorithm, the "algorithm used to
sign the certificate MUST be DSS"; similar for DH_RSA, it "MUST be
RSA".

Presumably chains would usually be consistent in the choice of
signature algorithms: i.e. either all RSA, all DSA ("DSS"), or all
ECDSA, with only the end-entity certificate possibly deviating.  Other
chains are not forbidden by the respective specification, they would
just be less useful in practice because they increase the risk that
certificates would not be accepted.  This is something that CAs can
take into account in their signing practice.  If they don't, this
means that certain chains might not be accepted by certain parties
(but non-acceptance is a problem must be expected all the time if a
party does not like a CA's signing practice).

(Also, the parties can work around the problem sometimes by relying
not just on root CAs for trust, but directly on intermediate CAs: If
Alice as a CA signs the certificate for another CA Bob and Bob signs
the certificate for Carol, then another party Dave can verify Carol's
certificate either by accepting Alice's certificate as trustworthy or
by accepting Bob's certificate as trustworthy.  In the latter case, it
does not matter what signing algorithm Alice has used.)