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

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Jun 2014 09:25:44 -0700

Per the direction below I have made the appropriate edits as a pull request:
https://github.com/tlswg/tls13-spec/pull/44.

I'll merge it in on Wednesday. Please let me know before then if
this seems substantially wrong. As usual, minor editorial issues
can be done by pull requests.

Note that the changes here were a little more involved and left a
few loose ends (e.g. issue #10). I'd like to try to handle any other
loose ends people find as separate issues if possible.

Thanks,
-Ekr

On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) <
[email-masked]> 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.
>
> 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
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Jun 2014 15:02:54 -0400

The draft was in a sort of halfway state between whether TLSCiphertext
has a fragment that is a selection or just embedding the AEAD elements
directly.  This should normalize it to the embedded view without the
extra GenericAEADCipher struct definition.

(i don't think this changes the logic of the draft at all)
---
 draft-ietf-tls-tls13.md | 25 +++++--------------------
 1 file changed, 5 insertions(+), 20 deletions(-)

This is https://github.com/tlswg/tls13-spec/pull/45

diff --git a/draft-ietf-tls-tls13.md b/draft-ietf-tls-tls13.md
index 2c21189..2a7f244 100644
--- a/draft-ietf-tls-tls13.md
+++ b/draft-ietf-tls-tls13.md
@@ -985,7 +985,7 @@ of {{RFC5116}}. The key is either the client_write_key or the server_write_key.
            opaque nonce_explicit[SecurityParameters.record_iv_length];
            aead-ciphered struct {
               opaque content[TLSPlaintext.length];
-          };
+           } fragment;
        } TLSCiphertext;
 
 type
@@ -1000,19 +1000,10 @@ length
 
 fragment
 : The AEAD encrypted form of TLSPlaintext.fragment.
-{:br }
-
-       struct {
-          opaque nonce_explicit[SecurityParameters.record_iv_length];
-          aead-ciphered struct {
-              opaque content[TLSPlaintext.length];
-          };
-       } GenericAEADCipher;
-
 
 Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD
 operation is constructed, and what is the length of the
-GenericAEADCipher.nonce_explicit part. In many cases, it is appropriate to use
+TLSCiphertext.nonce_explicit part. In many cases, it is appropriate to use
 the partially implicit nonce technique described in Section 3.2.1 of
 {{RFC5116}}; with record_iv_length being the length of the explicit part. In
 this case, the implicit part SHOULD be derived from key_block as
@@ -2731,18 +2722,12 @@ This section describes protocol types and constants.
         ContentType type;
         ProtocolVersion version;
         uint16 length;
-        select (SecurityParameters.cipher_type) {
-            case aead:   GenericAEADCipher;
+        opaque nonce_explicit[SecurityParameters.record_iv_length];
+        aead-ciphered struct {
+            opaque content[TLSPlaintext.length];
         } fragment;
     } TLSCiphertext;
 
-    struct {
-       opaque nonce_explicit[SecurityParameters.record_iv_length];
-       aead-ciphered struct {
-           opaque content[TLSPlaintext.length];
-       };
-    } GenericAEADCipher;
-
 ##  Change Cipher Specs Message
 
     struct {
-- 
2.0.0

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jun 2014 12:07:23 -0700

> This is https://github.com/tlswg/tls13-spec/pull/45

It looks like a good change to me.  But it's probably not the sort of
thing we need to discuss that much, it's purely editorial.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jun 2014 12:17:15 -0700

This looks basically sound to me. I'll give it a once-over on github and
assuming
it still looks ok, merge it in.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 18 Jun 2014 15:20:42 -0400

> thing we need to discuss that much, it's purely editorial.

I agree this shouldn't need much discussion.  i posted it to the list
here because there was no feedback in 6 days after submitting the
initial pull request.

	--dkg

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jun 2014 12:26:15 -0700

On Wed, Jun 18, 2014 at 12:20 PM, Daniel Kahn Gillmor <[email-masked]

> here because there was no feedback in 6 days after submitting the

That was just me doing batch processing :)

-Ekr