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

On Tue, Apr 19, 2005 at 03:15:56PM -0700, Ari Medvinsky wrote:

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

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.

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

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.

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

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.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls