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

From: "Ari Medvinsky" <[email-masked]>
Date: Tue, 19 Apr 2005 15:15:56 -0700

Bodo,

1) SHA1 issue:

Since we are defining new cipher suites I don't think that it makes
sense to say that we should not use a stronger hash function just
because there are existing cipher suites that already use Sha1 or Md5.

The PRF problem needs to be addressed separately and should not be
gaiting factor. Moreover, even if we are to wait until TLS 1.2, the
approach to simply use SHA-256 whenever SHA1 is specified will not work
for backward compatibility reasons.

2) Chaining with certs using mixed crypto (ECC/RSA) issue:

I agree with your comments.  However, the current version of the draft
leaves this issue ambiguous.  All that is needed is a couple of
additional sentences which state that mixed chains are permitted (or not
permitted) - it just needs to be explicit. 

Ari Medvinsky
Program Manager 
Windows Security

-----Original Message-----
From: Bodo Moeller [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2005 10:54 AM
To: Ari Medvinsky
Cc: Eric Rescorla; [email-masked]; Joshua Ball; Jeff Spelman; Stefan
Santesson; Cristian Ilac
Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc

On Mon, Apr 18, 2005 at 02:02:47PM -0700, Ari Medvinsky wrote:

> 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).

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).

> 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?

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.)

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 19 Apr 2005 21:43:36 -0600

> because there are existing cipher suites that already use Sha1 or Md5.

Existing ciphersuites using SHA-1 surely don't *force* us to use SHA-1
for new ciphersuites.  It's just that sticking to SHA-1 for now allows
us to use a harmonized approach to solve the problem for many
ciphersuites to minimize differences between ciphersuites.

If it was already precisely certain how the existing TLS ciphersuites
would be fixed, then we'd have an example to follow -- but I don't
think this is quite clear yet:

A straightforward approach would be to simply plug in SHA-256 instead
of SHA-1, thus introducing larger MAC tags.  A disadvantage is that
SHA-256 is slower, and obviously that MAC tags would be longer.  The
latter problem can be lessened by using SHA-192 instead (so that MAC
tags would be just four bytes longer than they are now), or by
truncating the MAC even more.  But in any case, the newer SHAs are
slower than SHA-1.  The future preferred MAC function for TLS might
end up being something different from any SHA-{1,192,256,...} HMAC;
so by using SHA-192 or SHA-256 now, we possibly will create more
confusion between different ciphersuites and protocol versions in the
future.

> for backward compatibility reasons.

Backward compatibility would be no problem: Protocol version
negotiation can decide which MAC to use, just like SSL 3.0
ciphersuites uses a slightly different MAC construction than the same
ciphersuites in TLS 1.0.  (This time, the difference would be more
significant.)  Those who want to totally avoid SHA-1 would have to
insist on the appropriate minimum protocol version.

> permitted) - it just needs to be explicit. 

Agreed.  The approach that seems to make most sense here is to come up
with a wording that can be added similarly both to
draft-ietf-tls-rfc2246-bis-09.txt and to draft-ietf-tls-ecc-09.txt.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Apr 2005 21:23:22 -0700

> ciphersuites to minimize differences between ciphersuites.
Indeed. 

And given that there's as yet no evidence that the current problems
with SHA-1 impact HMAC, I don't think it's really supercritical
to rush this transition.

-Ekr

---

From: Jack Lloyd <[email-masked]>
Date: Wed, 20 Apr 2005 08:53:00 -0600

> insist on the appropriate minimum protocol version.

But if I feel that SHA-1 is fine with HMAC (which I do given the current
results), and don't want the space and computational overhead of something like
SHA-256 (I don't think it actually matters that much but some people seem to),
I'm stuck using an older protocol version forever. We already have a mechanism
which allows the two parties to negotiate which algorithms they would prefer to
use, why not use that instead of overloading the protocol version when it's not
necessary? If the ciphersuite system is really so broken that it's such a
burden to add a set of 10-15 new ciphersuites which use SHA-256 for the HMAC, I
think that is something which should be examined.

-Jack

---

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

> I'm stuck using an older protocol version forever.

Only if the future protocol version really switches to SHA-256.  I did
not mean to imply that this is what will definitely happen.  Future
TLS versions may use an entirely different, and possibly much more
efficient, technique for message authentication (such as something
based on universal hashing).

>                                                    We already have a mechanism

An alternative to using the protocol version or the ciphersuite would
be a new TLS extension for hash algorithm negotiation.  And of course,
defining new versions of the existing ciphersuites still remains a
possibility if this is deemed advantageous.  There are many options
for how to proceed, and as we don't have to rush away from SHA-1 HMAC,
it's really above all about keeping the options open for now.