Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sat, 26 Apr 2014 15:24:22 +0000

The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github.

Joe
[For the chairs]
On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) <[email-masked]> wrote:

> TLS has supported a number of different cipher types for protecting the record layer.   In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher.  The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier.   AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms.  The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014.
> 
> Thanks,
> 
> Joe
> [Speaking for the TLS chairs]
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Fedor Brunner <[email-masked]>
Date: Tue, 29 Apr 2014 10:44:52 +0200

The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA.
What is the mandatory cipher in TLS 1.3 ?

Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for
ECDHE ?

Fedor

On 26.04.2014 17:24, Joseph Salowey (jsalowey) wrote:
> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type
AEAD. The Editor is requested to make the appropriate changes to the
draft on github.
>> TLS has supported a number of different cipher types for protecting
the record layer.   In TLS 1.3 these include Stream Cipher, CBC Block
Cipher and AEAD Cipher.  The construction of the CBC mode within TLS has
been shown to be flawed and stream ciphers are not generally applicable
to DTLS. Using a single mechanism for cryptographic transforms would
make security analysis easier.   AEAD ciphers can be constructed from
stream ciphers and block ciphers and are defined as protocol independent
transforms.  The consensus in the room at IETF-89 was to only support
AEAD ciphers in TLS 1.3. If you have concerns about this decision please
respond on the TLS list by April 11, 2014.

---

From: Ralph Holz <[email-masked]>
Date: Tue, 29 Apr 2014 19:32:00 +0200

Hi,

On 04/29/2014 10:44 AM, Fedor Brunner wrote:

> The Mandatory Cipher Suite for TLS 1.2 was
> TLS_RSA_WITH_AES_128_CBC_SHA. What is the mandatory cipher in TLS
> 1.3 ?
> 
> Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519
> for ECDHE ?

For current TLS 1.2, the UTA BCP [1] suggests
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. It also asks for
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to be supported by implementations.

It might be nice to keep the BCP in line with TLS 1.3 suggestions.

As for the symmetric ciphers... I acknowledge there is resistance
against GCM due to sidechannel issues, but really, with the current
combination of encryption and MACs, I see no alternative there bar the
new stream ciphers.

Maybe it's time Peter's draft is finally moved forward - although I
still object to the use of extensions to indicate encrypt-then-mac.

(Part of my reasoning is that using extensions complicates the
protocol, which leads to more complexity in implementations)

Ralph

[1] http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/?include_text=1

[2] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05

> AEAD. The Editor is requested to make the appropriate changes to
> the draft on github.
> 
>> Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey
>> (jsalowey)
> <[email-masked]> wrote:
> 
> the record layer.   In TLS 1.3 these include Stream Cipher, CBC
> Block Cipher and AEAD Cipher.  The construction of the CBC mode
> within TLS has been shown to be flawed and stream ciphers are not
> generally applicable to DTLS. Using a single mechanism for
> cryptographic transforms would make security analysis easier.
> AEAD ciphers can be constructed from stream ciphers and block
> ciphers and are defined as protocol independent transforms.  The
> consensus in the room at IETF-89 was to only support AEAD ciphers
> in TLS 1.3. If you have concerns about this decision please respond
> on the TLS list by April 11, 2014.
>>> 
>>> Thanks,
>>> 
>>> Joe [Speaking for the TLS chairs] 
>>> _______________________________________________ TLS mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Apr 2014 10:37:00 -0700

> combination of encryption and MACs, I see no alternative there bar the

Another alternative would be AES-CTR + HMAC....

> still object to the use of extensions to indicate encrypt-then-mac.

The WGLC for this ended Monday. I would expect Peter to produce a new
draft relatively soon and then we should be able to send it to the IESG.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Tue, 29 Apr 2014 13:46:00 -0400

> The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github.

Sorry - I'm coming late here.  Does this also imply the complete 
elimination of the integrity only cipher suites?

With respect to the AEAD approach and with respect to composited AEAD 
cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman 
for example), does this also imply that the key expansion phase will 
never be used to generate MAC keys, and that the cipher suite has to 
provide whatever mechanisms that are required to split the AEAD key into 
underlying encryption/integrity keys if required?

Next (reading from the commited editors copy), this refers to 5116 which 
uses a one-size fits all approach that doesn't really fit all sizes, 
especially for composited AEAD.  E.g.  the draft describes this 
generally as an incrementing value.  For AEAD suites that comply with 
5116, that should be part of the suite specification - not TLS.  For 
TLS, this just needs to be an normatively opaque, per-message field.    
Instead,  place an Informative section which recommends how to do this 
with AEAD suites that currently exist.

  And finally, as I've noted many times before, deriving IV/nonce 
material from the master_secret at the same time as deriving keys is not 
securely supportable in hardware.

---

From: [email-masked] (Martin Rex)
Date: Tue, 29 Apr 2014 20:27:44 +0200 (CEST)

> Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for

Support for ECC is/was a mere option in TLSv1.2.
The specification of Curve25519 for use with rfc4492 is not yet
standardized, same for ChaCha and Poly1035.

What you're asking for is something that has very little in common
with any prior version of TLS, and in particular ZERO interop with
the currently installed base.

TLSv1.2 (rfc5246) had the intention to be backwards-interoperable
with the installed base (otherwise they would have not added the
silly definition of an (md5,rsa) digital signature to TLSv1.2
(you may want to remove that bogosity from the v1.3 draft),
but the amount of interoperability problems with the installed
base was significantly enough to deter adoption of the protocol
for >4 years.

Looking at the amount of changes that are being considered and
discussed here for TLSv1.3, I would not be surprised if the
resulting adoption rate for TLSv1.3 would make the IPv6 adoption rate
appear blazing fast...

-Martin