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

From: Peter Gutmann <[email-masked]>
Date: Fri, 28 Mar 2014 03:37:18 +0000

Russ Housley <[email-masked]> writes:

>Please look at RFC 6476.  In that document, Peter Gutmann uses traditional
>encryption and integrity functions to make an AEAD cipher.  Does this
>decision allow or prohibit such ciphers?

I had a similar question, the EtM draft uses the existing CBC as part of an
AEAD mechanism, in a manner that requires minimal changes and no
implementation of new cipher modes.  Does that count as AEAD, or does it have
to be a combined cipher mode?

Peter.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 28 Mar 2014 04:42:00 +0000

> to be a combined cipher mode?

[Joe] I don't think it counts as an AEAD mechanism.  It is not using the AEAD  cipher type defined in RFC 5246.   You could define EtM using CBC so that it fits the AEAD interface.  

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Mar 2014 10:14:38 +0100

> [Joe] I don't think it counts as an AEAD mechanism.  It is not using the AEAD  cipher type defined in RFC 5246.   You could define EtM using CBC so that it fits the AEAD interface.  

I don't think this is possible. Don't forget that the AEAD mechanism in
TLS is only applicable to stream ciphers, i.e, for ciphers that
plaintext equals ciphertext. So moving everything to "AEAD" would have
to create a new AEAD mode.

Overall, I think that this discussion about allowing only the true
"AEAD" is pointless. All TLS ciphersuites are Authenticated Encryption
by definition and there is no advantage by require them to fit into the
TLS true "AEAD" mode.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2014 06:57:14 -0700

On Fri, Mar 28, 2014 at 2:14 AM, Nikos Mavrogiannopoulos <[email-masked]>wrote:

> > [Joe] I don't think it counts as an AEAD mechanism.  It is not using the
> AEAD  cipher type defined in RFC 5246.   You could define EtM using CBC so
> that it fits the AEAD interface.
>

This is fairly straightforward to address by simply adopting
the same length approach that Peter's draft adopts. Yes, we
would need to update the text, but since we're talking about
a new document that doesn't seem like a problem.

> by definition and there is no advantage by require them to fit into the

The idea here is that TLS currently specifies *in TLS* how to compose
authentication and encryption which means that we have to specify
three interfaces for three different kinds of ciphers (stream, block, AEAD).
Since cryptographic practice seems to be moving towards AEAD as
a primitive, we have an opportunity to simplify matters by going to
an AEAD only interface which also has the virtue of having to specify
specific constructions in TLS.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 10:16:29 -0400

> specific constructions in TLS.

So let me get this straight: what we are planning to do is eliminate
the current MAC-encryption layer, and instead have a layer that takes
a plaintext TLS record and encapsulates as an encrypted one. The TLS
spec specifies the inputs, and the cipher has to specify how to go
from inputs to ciphertext, and be IND-CCA2+INT_PTXT secure.

This has a major advantage in that we lose a lot of length and
complexity from the spec. I don't see any disadvantages.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2014 07:23:24 -0700

On Fri, Mar 28, 2014 at 7:16 AM, Watson Ladd <[email-masked]> wrote:

> from inputs to ciphertext and be IND-CCA2+INT_PTXT secure.

Assuming I understand you correctly, then yes, this sounds right,
with the small caveat that we would probably not leave the question
of how to format the cleartext part of the (otherwise encrypted)
record header up to the cipher, since that's a TLS issue, though
we would expect it to be covered as part of the "additional data".

> complexity from the spec.

This was my thinking as well.

-Ekr