Subject: [TLS] Pull request: Remove length from AEAD Ciphers

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Aug 2014 09:34:22 -0700

Per discussion in Toronto. Fixes:
https://github.com/tlswg/tls13-spec/issues/67
https://github.com/tlswg/tls13-spec/issues/47

https://github.com/tlswg/tls13-spec/pull/77

Target merge date: 8/28.

Please comment here or on github if you see issues.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Aug 2014 13:38:47 +0200

> https://github.com/tlswg/tls13-spec/pull/77

If it is merged as is there will be two types of AEAD ciphersuites. The
pre-TLS 1.3 and the post TLS 1.3. From the post-TLS 1.3 the ones that
require padding wouldn't work with pre-TLS 1.3 while the others would.

So let's suppose we have TLS_AEAD_AES_128_CBC_SHA1 defined sometime
after TLS 1.3 is published. What would a TLS 1.2 implementation do if
faced with this ciphersuite? Should it implement it using the TLS 1.3
semantics, or it shouldn't implement it at all? What if two
implementations make a different choice in that dilema? The whole AEAD
ciphersuite handling is becoming quite complex.

The rules seem to be:
- ciphersuites defined using the original AEAD: only after TLS 1.2
- ciphersuites defined after TLS 1.3: if the ciphersuite requires
padding only after TLS 1.3, otherwise only after TLS 1.2.

There is space for quite some bugs there, and quite some improvisation
for implementors that would like to have the new AEAD format in old
versions. The text should at least mention what is the intention for
that.

I think the simplest way to solve the ambiguities, would be to have an
extension that would enable the new AEAD format, rather than rely on the
TLS 1.3 version. That way negotiation would be straightforward; if the
extension is present the new AEAD format will be used regardless the TLS
version.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Aug 2014 08:14:52 -0700

On Wed, Aug 27, 2014 at 4:38 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> pre-TLS 1.3 and the post TLS 1.3.

Yes, and they will use the same code points. This is already true with,
for instance, the IV between version 1.0 and 1.1 and the version
field between SSLv3 and TLS 1.0

> ciphersuite handling is becoming quite complex.

Sure. I would suggest we address this problem if/when someone
actually defines such a cipher suite, which can either update
RFC 5246 appropriately or say "do not use in TLS 1.2".

> versions. The text should at least mention what is the intention for

I'm happy to do that.

> extension is present the new AEAD format will be used regardless the TLS

I would prefer not to do this. One advantage of having a new version number
is
not having a bunch of extension-optional behavior when you really only
want one.

Best,
-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Aug 2014 08:20:16 -0700

<snip>
What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just
fine: we don't need variable expansion as it doesn't give us
more, so why support it?
Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Aug 2014 08:29:04 -0700

> fine: we don't need variable expansion as it doesn't give us

I would look at this differently: we don't know in advance that variable
expansion won't ever give us anything useful, and having the length
is an impediment to ever adding them. This certainly doesn't preclude
you arguing against someone defining a CBC+HMAC AEAD suite
(and I do imagine someone will want to do so.)

-Ekr

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 27 Aug 2014 11:29:29 -0400

> What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just fine: we don't need variable expansion as it doesn't give us more, so why support it?

Less disastrous consequence of (inadvertent) IV reuse for CBC?

(Yes, your code would *never* do that, but there are other, less skilled, programmers around. :-)

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Aug 2014 15:04:26 -0700

> Less disastrous consequence of (inadvertent) IV reuse for CBC?

Nonces don't repeat, IVs are random. Reuse isn't the issue for CBC,
determinism is. TLS gets this wrong, badly, and repeatedly.

> (Yes, your code would *never* do that, but there are other, less skilled, programmers around. :-)

Misuse-resistant AEAD schemes like SIV mode exist and do not have
variable-length ciphertext expansion. Why do we need CBC+HMAC as an
AEAD scheme? What problem is it solving that the existing ones don't?
Furthermore, if we are willing to consider this change, why not
changes to the Finished message to simplify the proof, or using a
well-studied key agreement scheme? I don't understand the logic being
applied: features are being put forward piecemeal, hindering debate
and analysis, while large and well-known issues (like the complexity
of implementations, which changes like the above don't help) aren't on
the table because they could require changes to implementations.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Aug 2014 08:03:30 +0300

> Nonces don't repeat, IVs are random. Reuse isn't the issue for CBC,

Reuse in CBC tells an observer how many of the initial blocks are identical. This is more of an issue for IPsec (where the initial blocks cover IP and TCP header, which tend to have a lot of fields repeat), but it’s information disclosure any place you use it. This has been rationale for why we needed 128-bit block ciphers in the first place.

Yoav

---

From: Paul Lambert <[email-masked]>
Date: Thu, 28 Aug 2014 12:06:10 -0700

On 8/27/14, 3:04 PM, "Watson Ladd" <[email-masked]> wrote:
>
>Nonces don't repeat, IVs are random.

The above definitions do not represent industry practice for the terms.  I
agree that IVs generally should mean random, but there are various
protocols that map a counter into an IV.  Historical background of IV is
from military use and extended the concept of a Message Indicator (which
should be random).

Likewise, many protocols have a Œrandom nonce¹.

>Reuse isn't the issue for CBC,

Yes - it is tough following this list and what it is trying to accomplish
at a high level.

Even the idea of length on all the supposedly opaque fields is unnecessary
and confusing.
If two implementations know the encoding and structure of a set of AEAD
protected fields
than the length and processing should be implicit.

Paul

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Aug 2014 12:19:26 -0700

> than the length and processing should be implicit.

Paul,

Can you explain what you mean here? The length in question is the length
of the plaintext. So, the problem is that if an AEAD cipher has
content-dependent
padding (or more likely content-length dependent padding) then it is not
possible to determine the plaintext-length value from the ciphertext.

-Ekr

---

From: Paul Lambert <[email-masked]>
Date: Thu, 28 Aug 2014 16:28:35 -0700

Hi Eric,

Can you explain what you mean here?
Sure … but please forgive any ignorance shown on
current TLS specifics versus my generic opinions on
encapsulation methods.

The length in question is the length
of the plaintext. So, the problem is that if an AEAD cipher has content-dependent
padding (or more likely content-length dependent padding) then it is not
possible to determine the plaintext-length value from the ciphertext.

First - I’m assuming that it is already known what cipher–suite is in use.
The cipher-suite would need to be consistent for a session, or provided for use
In the message prior to the AEAD protected information.

If you know the cipher suite (e.g. AEAD cipher) in use, the cipher-suite
definition can directly imply the encoding and representation of all
fields including the length of fields and the presence or absence of
length fields.

>From a general perspective, the encryption process should be
allowed to increase or decrease the length of the protected
Information. Compression might be possible (please, no nits
on this, I know of the TLS compression attacks).  Expansion
Is typical given the common use of an IV and Check Value.

Note that I am necessarily differentiating between
the expansion due to non-stream cipher block size
alignement or from the addition of leading or trailing
fields used as part of the overall AEAD processing.

On block aligned AEAD approaches.  There are a variety of ways
to indicate the original length of the plain-text.  For example,
the padding field has been used to carry the size of
the padding … and hence determine the original plaintext.
Equally valid would be the inclusion of a length field in the
protected data.  The presence of the length field would be
implicit in the definition of the cipher-suite.

As an aside …
If an observer is looking at an encapsulation (AEAD
protected in this discussion), all fields ideally should be
Indistinguishable.  The protected data should be a single
opaque octet string (IMHO).  It would be desirable
to make it difficult to determine the cipher-suite in
use by outside observation.  The algorithms in use
should not be obvious to a casual observer.

Typical nonce/IV usage of CCM and GCM tend to break
this goal.  The use of a counter clearly will show the
boundaries of the IV.  An explicit length of the IV is still
not required for parsing.  Other approaches of course could
be defined to ensure non-unique, but uniformly distributed
IV values.  So … I hope this digression on IV does not side track
the original concept (all fields size and usage determined
by cipher suite).

Paul

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Aug 2014 16:34:39 -0700

> implicit in the definition of the cipher-suite.

We might want to explicitly hide the length of the plaintext from an
outside observer.  Therefore, it makes sense that the length of the
plaintext be, at least in some circumstances, unknown prior to
decryption.  However, the TLS 1.2 AEAD formulation *requires* that the
plaintext length be included in the protected additional data.  You
cannot decrypt an AEAD block unless you have all of the additional
data, so these are directly opposed goals.

Yes, you could signal the amount of padding outside the encrypted
envelope, but that would be a ciphersuite-specific choice (and
arguably a bad one).  The TLS 1.2 formulation requires that length be
*generically* available.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 29 Aug 2014 08:46:46 +0200

> RFC 5246 appropriately or say "do not use in TLS 1.2". 

That must be decided now when the change is done. Otherwise we cannot
predict the intentions of a future document author; nor assume that such
a document would pass from the WG.

> I would prefer not to do this. One advantage of having a new version
> number is

What I'm most worried is that this will happen anyway, since at some
point it will be asked from the WG to allow any new ciphersuites to be
used in old TLS versions (it has already happened with TLS < 1.2 and
GCM).

> fine: we don't need variable expansion as it doesn't give us

I don't believe that's the question we are facing. I believe the
question is when. Documents already exist [0], and it is the intention
of the TLS chairs to move that way (or at least that was mentioned in
IETF 87 during tls 1.3 discussion [1]; that may be out of date though).

regards,
Nikos

[0]. http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05
[1]. http://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf