Subject: [TLS] WGLC for rsa-aes-gcm and ecc-new-mac

From: <[email-masked]>
Date: Tue, 12 Feb 2008 14:42:03 +0200

<wg chair hat on>

This message starts a WG last call on the following two drafts:

  draft-ietf-tls-rsa-aes-gcm-02
  draft-ietf-tls-ecc-new-mac-04

prior to sending them to the IESG for publication as Proposed 
Standard (rsa-aes-gcm) and Informational (ecc-new-mac).

Please send your comments to the WG mailing list by Wednesday 
March 5th. Comments along the lines "I've read it and it looks 
OK" are helpful and encouraged.

Best regards,
Pasi
_______________________________________________
TLS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Feb 2008 14:29:03 +0100

> OK" are helpful and encouraged.

With the following fixes, I think the documents are OK.  I haven't
implemented them though, so there may be still be other issues.

For draft-ietf-tls-ecc-new-mac-04:

* Section 1 says "This document specifies TLS ECC cipher suites which
  replace SHA-256 and SHA-384 rather than SHA-1.".  I can't parse this.
  s/replace/uses/?

* Section 2.1 and 2.2, where is P_SHA-256 defined etc?  RFC 4346bis
  mentions P_SHA256 but not P_SHA-256.

* Section 2.2, what should be done if AES-GCM decrypt fails?  Unlike
  most others ciphers, AES-GCM can fail to decrypt data.  Either a
  discussion, or a pointer to discussion elsewhere, to specify the
  behaviour in TLS would be useful.  There may be side-channel
  considerations here, so it may be relevant to add that decrypt errors
  should not be leaked.

For draft-ietf-tls-rsa-aes-gcm-02:

* Section 1, typo "ciphersutes".

* Section 3, same as for the other document, what should be done if
  AES-GCM decrypt fails?

/Simon

---

From: "Wan-Teh Chang" <[email-masked]>
Date: Tue, 12 Feb 2008 06:40:41 -0800

draft-ietf-tls-ecc-new-mac-04.txt:

Change "AES_128_GCM_SHA384" to "AES_256_GCM_SHA384" (two occurrences).

Wan-Teh

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Feb 2008 21:51:58 -0800

On Tue, Feb 12, 2008 at 02:42:03PM +0200, [email-masked] wrote:

> March 5th. [...]

Given the form of rfc4346-bis that has now evolved, the ecc-new-mac
specification really should include ECDHE_RSA versions of the
ciphersuites that it specifies -- i.e., ciphersuites relying on RSA
for server authentication (since this is what the current base of
installed certificates mostly offers) but on ECDH for forward secrecy.

(Using the RFC 4492 ciphersuite for this purpose would mean using
the legacy TLS PRF.)

For sake of completeness, one might also want to add ECDH_RSA to the
picture.

So I don't really agree with draft-ietf-tls-ecc-new-mac-## unless the
following ciphersuites are added, since I wouldn't really like to see
yet another boring ciphersuite specification just to cover these:

       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};

       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};

... plus optionally:

       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};

       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};

, all with the obvious semantics.

Bodo

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 13 Feb 2008 08:49:26 -0500

And the point of mixing an RSA-based suite into an ECC-based draft would be..?   The idea is to move from RSA to ECC.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bodo Moeller
Sent: Wednesday, February 13, 2008 12:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] WGLC for rsa-aes-gcm and ecc-new-mac

... plus optionally:

Bodo

---

From: "Bodo Moeller" <[email-masked]>
Date: Wed, 13 Feb 2008 10:48:31 -0800

> And the point of mixing an RSA-based suite into an ECC-based draft would be..?   The idea is to move from RSA to ECC.

You have just answered your own question, haven't you?

These ciphersuites are part of the transition path, in particulary if
we take into account the intrinsincally different time behavior of
authentication security and encryption security in scenarios where we
have an ephemeral data exchange as in TLS (rather than long-term data
storage) but may require long-term encryption security.

ECDH ciphersuites with RSA-based authentication mean that we can use
ECC with the certificates that are around now (i.e., without having to
obtain additional certificates specificallly for ECC).  Should it
happen that two years from now 2048-bit RSA and 2048-bit DH are
routinely broken but ECDH is unaffected, our current TLS sessions
using one of these mixed ECDHE_RSA ciphersuites will remain secure: An
adversary who now records all the data of our TLS connections won't be
able to decrypt it (but might sooner or later be able to decrypt data
from sessions using DHE_RSA ciphersuites).

Also, the ECDH ciphersuites with RSA for authentication are quite nice
for clients without a lot of computing power, since RSA signature
verification (with e = 0x10001 and the like) is very quickly done
compared to verification in most other signature schemes.

Bodo

>  >   draft-ietf-tls-ecc-new-mac-04
[...]
>  installed certificates mostly offers) but on ECDH for forward secrecy.
[...]