Subject: [TLS] Consensus call on Implicit IV for AEAD

From: Joseph Salowey <[email-masked]>
Date: Fri, 3 Apr 2015 13:34:15 -0700

In the interim meeting we had consensus to use an implicit IV for AEAD.
The proposal was to use the record sequence number and pad with zeros as
described in pull request 155 (
https://github.com/tlswg/tls13-spec/pull/155/files).  This was also
discussed in the IETF-92 meeting in Dallas along with options to change the
offset.  The consensus was to stay with the original proposal.  We are
posting to the mailing list to confirm this consensus. If you have
comments,  please reply by April 17, 2015.

Thanks,

S&J

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 17:34:31 -0700

WFM

On 3 April 2015 at 13:34, Joseph Salowey <[email-masked]> wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD.  The
> proposal was to use the record sequence number and pad with zeros as
> described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files).  This was also
> posting to the mailing list to confirm this consensus. If you have comments,
> please reply by April 17, 2015.
>
> Thanks,
>
> S&J
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Daniel Migault <[email-masked]>
Date: Fri, 3 Apr 2015 22:05:05 -0400

Fine to me. BTW how do you position this toward FIPS/NIST Cryptographic
Module Validation program?

On Fri, Apr 3, 2015 at 8:34 PM, Martin Thomson <[email-masked]>
wrote:

> The

-- 
Daniel Migault
Ericsson

---

From: Brian Smith <[email-masked]>
Date: Fri, 3 Apr 2015 17:17:04 -1000

> please reply by April 17, 2015.

Right now, based on my reading of the draft minutes, it doesn't look
like there was a complete, reasoned discussion of the issue during
IETF 92, nor is it clear to what extent any kind of consensus or
agreement was expressed during the meeting. Perhaps the draft minutes
are incomplete, but the statement that there was a consensus to stay
with the original proposal doesn't seem consistent with draft minutes.

Conversely, there is a clear record of my objection to the
zero-padding mechanism on the mailing list, and there seems to be at
least some mild support for my suggested alternative of deriving the
initial nonce from the keyblock. I think I provided a good
justification for moving to the randomized initial nonce. I think that
the concerns about it being more work to support a randomized nonce in
crypto modules that attempt to enforce a cryptographic boundary are
valid,m but those concerns outweigh the security benefits of starting
with a randomized nonce. I would be happy to work with the people who
expressed that concern to show that a randomized initial nonce can
work well and isn't unreasonably burdensome even in such products.

I've also thought of another reason why it seems useful to start with
a randomized initial nonce: As mentioned previously on this list, in
reality many AES-GCM implementations are far from being constant-time.
As far as I can reason, AES-GCM with predictable nonces, combined with
predictable plaintext and/or chosen plaintext, seem more likely to
attack via side channel attacks than AES-GCM with randomized nonces.
This is another significant advantage of randomization.

Finally, Ilari Liusvaara noted in the previous thread on the topic
that SSH already does exactly what I'm proposing, or very similar.
And, he also noted that IPSEC partially randomizes the nonce, as does
TLS 1.2. It seems like zero padding would be a regression from what
TLS 1.2 does, in terms of security. I find that concerning.

Here's exactly what Ilari Liusvaara wrote in [1]:
> As to what other protocols do with GCM, both SSH and IPSec do derive
> initial nonce out of key block (like TLS 1.2 does).
[...]
> As to what other protocols do with GCM, SSH derives a full block and
> increments that. IPSec derives just a prefix (like TLS 1.2).

Cheers,
Brian

[1] https://www.ietf.org/mail-archive/web/tls/current/msg15578.html

---

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Apr 2015 00:01:26 -0400

On Friday, April 03, 2015 11:17:04 pm Brian Smith wrote:
> initial nonce from the keyblock.

Yeah, correct me if I missed it, but there didn't seem to be any real
opposition to adding randomization to the nonce. There was suggestion
of using XOR rather than ADD to mix random & sequence, but either could
work.

> TLS 1.2 does, in terms of security. I find that concerning.

I would think it shouldn't be too hard to get agreement that following
this pattern is something worth continuing. At worst, it won't hurt.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Apr 2015 07:07:41 -0700

On Fri, Apr 3, 2015 at 8:17 PM, Brian Smith <[email-masked]> wrote:

> Right now, based on my reading of the draft minutes,

Which draft minutes are you referring to? I only see interim minutes
on the site.

> it doesn't look

> with the original proposal doesn't seem consistent with draft minutes.

You can find the discussion (which may or may not be complete or
reasoned) at:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_TLS&chapter=chapter_0

Starting at around 2:37:30.

The consensus call starts at around 2:44:30.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 4 Apr 2015 22:53:26 +0300

> work well and isn't unreasonably burdensome even in such products.

The stated reason for not deriving IV from keyblock is to support
"hardware modules" that don't know about TLS.

I do not think such support is actually possible without
severe restrictions: One major problem (and there are others) is
interaction of resumption and TLS-unique (which is needed for
e.g. token binding). TLS-Unique value is public. But on resumption,
it needs to depend on resumption key, which is secret (resumption
key can be abused to misuse client certificates).

Second problem: If TLS-Extractor is to be supported, those values
are keying and publically binding at the same time (I have seen
examples of both in various widely used protocols). Keying means
there is no choice but to derive from secret values. Publically
binding means the values are public.

Deprecating either of TLS-Unique or TLS-Extractor or changing properties
thereof does not seem to be an option, so full TLS 1.3 needs to derive
public values out of private ones anyway.

Also, exposing nonce generation to "untrusted" code seems pretty
dangerous, given how fragile most fast AEAD ciphers are (it is difficult
to even imagine worse nAEAD in this regard than *-GCM).

> This is another significant advantage of randomization.

As a datapoint about (lack of) hardware support for AES-GCM: When
Cloudflare turned Chacha ciphers on, it took about one fourth
of the AES-GCM connection count (other ciphers didn't bulge).

> It seems like zero padding would be a regression from what

As brought up in the meeting, 128 bit ciphers are suspectable
to multi-key weakening (it is an generic attack against
symmetric ciphers). The answer was to use 256-bit ciphers, but
AES-256 isn't that widely supported (I think Chrome is planning
to deprecate it[1]).

Then when it comes to cipher-specific weaknesses (and we know
that ciphers have annoying tendency to stay in use way past
the best before date, *cough* RC4 *cough*), it depends on type
of weakness if having a known nonce significantly helps breaking
or not.

BTW: SSLv3 applied special handling for EXPORT ciphers: The
initial IV was derived in public way[2] (instead from keyblock
like non-export ciphers). Of course, didn't matter much,
given that all IVs were for CBC modes.

[1] Also on some security-oriented forums, one frequently
hears remarks about AES-256-CBC being worse than AES-128-GCM.

[2] I think this was a due to a restriction on export
ciphers that disallowed hiding the nonces.

-Ilari

---

From: Tom Ritter <[email-masked]>
Date: Sun, 5 Apr 2015 20:10:14 -0500

> please reply by April 17, 2015.

I apologize if I'm mistaken or this has been raised previously, but I
feel compelled to speak up and not assume it has.

The record sequence number is predictable. It's not in the clear on
the wire, but it begins at 0 and increments with every record.
(Right?)

This will result in a predictable IV for the AEAD mode.  We have two
AEAD modes today:
 - GCM - IV must be unique, being predictable doesn't matter (Right?)
 - poly1305 - IV/Nonce must be unique, being predictable doesn't matter (Right?)

But we also don't know what AEAD modes we will add in the future.  I'm
far from being 'up' on the CAESER competition, but I skimmed the first
~10 entries, and one, CMCC  is based on CBC mode. It seems like a
predictable IV = BEAST.  Am I right in thinking we will be
pigeonholing ourselves into only allowing AEAD modes that do _not_
require an unpredictable IV?

-tom

---

From: "David Leon Gil" <[email-masked]>
Date: Sun, 05 Apr 2015 18:35:13 -0700 (PDT)

In support of Tom, I would note that Namprempre et al.'s EUROCRYPT paper 'Reconsidering Generic Composition' is relevant: https://eprint.iacr.org/2014/206.pdf

They define a nonce-based AEAD (nAE) scheme as a function (inputs and outputs are bitstrings):

    (n, ad, p) \rarrow (c, t)

and requires that the resulting scheme be IND-CCA$ (?) iff

     $\forall m, \nexist m', m.ad = m'.ad \wedge m.n = m'.n \wedge m.p \nea m'.p$

I would strongly suggest that the TLS 1.3 recommendation impose this requirement for any AEAD suites specified in future.

--

Or, more simply: IVs must be indistinguishable from random bytes. Nonces must simply be unique.

Assuming that the 'IV' input to the TLS AEAD functions is predictable, it isn't an IV. It's a nonce. Please call it that, and disallow ivAE schemes.

—
Sent using alpine: an Alternatively Licensed Program for Internet News and Email

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 5 Apr 2015 19:13:04 -0700

> require an unpredictable IV?

I think we are restricting ourselves to AEAD modes that allow a predictable
nonce (this is the 5116 terminology). However, it's worth noting two points
about this:

1. All of the proposed constructions use related nonces in the sense that
if you knew the nonce for a single record, you could derive the nonce
for all records sent in that direction.

2. A predictable nonce does not mean that you have a predictable IV
for an underlying cipher. For instance, as AGL noted in a previous
e-mail [0], it is possible to construct an unpredictable IV from a
predictable
nonce.

-Ekr

[0] https://www.ietf.org/mail-archive/web/tls/current/msg15533.html

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Apr 2015 11:41:37 +0300

> On Apr 6, 2015, at 4:10 AM, Tom Ritter <[email-masked]> wrote:
> 

Yes, and in DTLS it’s even transmitted on the wire.

> - poly1305 - IV/Nonce must be unique, being predictable doesn't matter (Right?)

Yes to both questions. There’s also CCM and OCB and it’s true for them as well.

> require an unpredictable IV?

So either IVs (actually nonces) are compressible only for such ciphersuites that support using the record counter as nonce/IV (add a flag to the registry), or else we use some method such as AGL’s for generating unpredictable IVs from predictable nonces.

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Mon, 6 Apr 2015 06:25:03 -0500

On 6 April 2015 at 03:41, Yoav Nir <[email-masked]> wrote:
> So either IVs (actually nonces) are compressible only for such ciphersuites that support using the record counter as nonce/IV (add a flag to the registry), or else we use some method such as AGL's for generating unpredictable IVs from predictable nonces.

Thanks Yoav, ekr,

I obviously haven't followed all the arguments here (and from skimming
Brian's reply) - but I prefer defining a construction that makes the
IV given to the AEAD unpredictable and random. Doing that from a
predictable nonce seems okay.

-tom

---

From: Yoav Nir <[email-masked]>
Date: Mon, 6 Apr 2015 16:17:26 +0300

> On Apr 6, 2015, at 2:25 PM, Tom Ritter <[email-masked]> wrote:
> 

That depends. AES-GCM accepts a 64-bit IV. ChaCha20-Poly1305 is the same. If you feed it random bitstrings, you’re very likely to repeat a bitstring after a few billion records, and you have a good chance of repeating the IV even after many fewer records. So it’s much better to use a counter or 64-bit LFSR, even though they’re predictable. With a function that receives a 128-bit IV such as AES-CBC, randomization is fine. 

A good way for both is to encrypt a counter with a secret key (whether shared with the other side and then you can omit the IV or not and then you need to include it), but using a 64-bit cipher (DES?) to generate random-looking, non-repeating nonces for AES-GCM seems like a very weird idea.

So I’d rather have a nonce, and require whoever defines an AEAD based on CBC mode to either add an IV to the payload or define a way to calculate a non-predictable IV from that nonce.

Yoav

---

From: Daniel Migault <[email-masked]>
Date: Mon, 6 Apr 2015 09:38:21 -0400

We had similar discussions this in IPsecme WG in Dallas [1].

AES-CBC for example would require an unpredictable IV, which makes the IV
generation more complex. Keys to generate the IV have to be negotiated and
agreed. During the WG session, we agree to limit our scope for the implicit
IV on AES-CCM/GCM/CTR and making AES-CBC out of scope.

There are at least two ways to remove the IV, either you perform a
compression that can be applied to any algorithm or you define specific
protocol suites that have an implicit IV. With compression, you may design
a mechanism that works with any suite and design the IV compression so
highest requirements are fulfilled... hoping no other conditions may be
introduced in the future. By defining specific protocols like
(AES-CCM_IMPLICIT_IV) the protocol is designed specifically to meet IV
properties. The draft presented at IPsecme adopted the second approach.

The remaining discussion point raised was how to position this implicit IV
protocol with FIPS/NIST Cryptographic Module Validation program. I have not
had enough time to check that for now.

[1] https://tools.ietf.org/html/draft-mglt-6lo-aes-implicit-iv-01
BR,
Daniel

On Mon, Apr 6, 2015 at 7:25 AM, Tom Ritter <[email-masked]> wrote:

> > So either IVs (actually nonces) are compressible only for such
> ciphersuites that support using the record counter as nonce/IV (add a flag
> to the registry), or else we use some method such as AGL's for generating
> unpredictable IVs from predictable nonces.
>
>
> Thanks Yoav, ekr,
>

-- 
Daniel Migault
Ericsson

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Apr 2015 09:24:09 -0700

On 3 April 2015 at 20:17, Brian Smith <[email-masked]> wrote:
> a clear record of my objection to the
> zero-padding mechanism on the mailing list,

For the record then, the objection was this:

If you are concerned that someone might spend a large amount of
computing resources (2^60+ iterations) to gain themselves a reasonable
chance of decrypting a randomly selected session from a similar sized
set of sessions, pick a stronger cipher.

There's a history of attempting to paper over perceived weaknesses in
the crypto we use.  I get the belt and braces approach here, but I'd
rather see us develop stronger constructions (ChaCha+Poly uses a
longer key, for example).

If the complaint is specific to AES-GCM, I see nothing stopping
someone from proposing AES-GCMv2 that operates on extra keying
material internally in order to make the IV unpredictable.  I'd rather
keep the nonce sane though, it keeps it easy to reason about the
construction.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 6 Apr 2015 12:46:44 -0400

'I'd rather keep the nonce sane though, it keeps it easy to reason about the
construction.'

This is also the reason I would prefer not involving the nonce. It would
also help keeping the design for IPsec and TLS close.

-- 
Daniel Migault
Ericsson

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 6 Apr 2015 20:36:06 +0300

> set of sessions, pick a stronger cipher.

Which stronger cipher? AES-128 doesn't stand losing many bits before
becoming too weak, AES-192 is pretty much forgotten (I don't think it
even has codepoints) and AES-256 is seemingly being effectively
deprecated.

> longer key, for example).

So remove AES-128 entierely (MUST NOT negotiate) from 1.3?

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Apr 2015 10:46:52 -0700

> So remove AES-128 entierely (MUST NOT negotiate) from 1.3?

Your words, not mine.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 17 Apr 2015 15:47:39 +0300

On Fri, Apr 03, 2015 at 01:34:15PM -0700, Joseph Salowey wrote:
> posting to the mailing list to confirm this consensus.

I really do not like padding with zeroes, since it would weaken
encryption relative to TLS v1.2. And this is not just if the
symmetric encryption is already broken, but applies to all[1].

This is especially prominent with AES-128[2]. And "Just use AES-256"
does not solve the issue, since it will probably not be available
in important environments[3].

None of TLS v1.2, IPSec nor SSH use AES-GCM this way, all have
secret[4] fixed nonce-parts (SSH does use Chacha20 without per-
connection nonce[5]).

OTOH, the explicit per-record nonce field for AES-GCM seems really
unnecressary. Everybody uses it sequentially anyway, so it just
wastes 8 bytes per record.

[1] If the algorithm is broken, if the zeroes or even just known
nonce further help breaking depends on type of attack (but of
course, one rather not use such broken algorithms).[6]

[2] Substantial weakening happens far before collisions become
likely. So much less than AGL's "2^60" mentioned in the meeting.

[3] And I suppose nobody really likes AES-192 (despite the fact
that seemingly just about every CPU with "AES acceleration" is able
to accelerate that too). :->

[4] Secret meaning those are derived from the main key block.

[5] The encrypted stream looks like random noise, which makes it
harder to tell where packet boundaries are (and Chacha20 is
256-bit keys anyway).

[6] SSLv3 had known nonces for EXPORT ciphers, but secret ones
for strong ones. Hmm...

-Ilari

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 17 Apr 2015 14:04:11 -0700

> On Apr 17, 2015, at 5:47 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

Really?  Can you provide a citation?  Because if I’m reading it correctly, this is a claim that AES-128 is not a secure PRP, with significantly less than 2^60 known/chosen plaintexts, keys and compute time.

> to accelerate that too). :->

… and this is a claim that AES-192 and AES-256 are somehow substantially more secure than AES-128 as PRPs.

> [4] Secret meaning those are derived from the main key block.

… and this is a claim that adding an extra key, which is in the nonce instead of an actual key to the cipher, makes it more secure.

All this said, I agree that it’s wise to reduce the amount of cribtext you give an attacker, so long as it doesn’t cost too much complexity.  If we are really providing a fatal amount of cribtext, then we need to fix that, but then again, we should probably toss the cipher out at that point.

Cheers,
— Mike

---

From: Brian Smith <[email-masked]>
Date: Fri, 17 Apr 2015 11:30:31 -1000

Michael Hamburg <[email-masked]> wrote:
>> Ilari Liusvaara <[email-masked]> wrote:

It is a claim that AES-128-*GCM* *may* (emphasis on *GCM* and *may*)
not be a perfectly secure PRP, and/or that the key agreement scheme to
be used in TLS 1.3 *may* not not be perfect. I think those are
reasonable things to doubt, absent a proof to the contrary.

> All this said, I agree that it’s wise to reduce the amount of cribtext you give an attacker, so long as it doesn’t cost too much complexity.  If we are really providing a fatal amount of cribtext,…

The argument I was making is that (a) it seems unreasonable to assume
AES-128-GCM is perfect and that they key agreement scheme is perfect,
and (b) the cost of randomizing the starting point of the nonce
counter is so low that it is worthwhile to do it just in case.

I recently read the FIPS 140-2 implementer's guidance at [1]. I think
it is worthwhile for people discussing this to read what it has to say
about AES-GCM nonce handling, which starts on page 138. It recommends
an even more stringent handling of nonces for AES-GCM, summarizing the
approach proposed for TLS 1.3 as follows:

    It may be tempting to avoid meeting the IV generation
    requirements stated in this IG if it could be guaranteed
    that any key was used only once thus avoiding the (key, IV)
    collisions regardless of the method used to generate the
    IVs. The problem with this approach is that within the
    scope of the CMVP validation neither the module itself
    nor its Security Policy can enforce the single-use-key
    condition. The risk of introducing the identical (key, IV)
    pairs outweighs the possible benefits of relaxing the IV
    generation rules."

Where the "IV generation rules" are paraphrasing, "do it the way TLS
1.2 does, or else ensure every peer uses a unique identifier as a
prefix on nonces it uses for encryption."

No matter what we do, we should address this concern in the security
considerations of the TLS 1.3 spec by stating the assumptions we are
making and guarantees we are providing regarding (key, IV) uniqueness.

Cheers,
Brian

[1] http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf

---

From: Yoav Nir <[email-masked]>
Date: Sat, 18 Apr 2015 07:10:36 +0300

Hi

Making AEAD implicit on the record works for me. As far as using all zeros for the salt, it doesn’t make a lot of difference for ChaCha20-Poly1305, but it might make some for AES-GCM. Here’s a link to a post on the ipsec list that explains it better than I can:

http://www.ietf.org/mail-archive/web/ipsec/current/msg09751.html <http://www.ietf.org/mail-archive/web/ipsec/current/msg09751.html>

Yoav

> On Apr 3, 2015, at 11:34 PM, Joseph Salowey <[email-masked]> wrote:
> 
> In the interim meeting we had consensus to use an implicit IV for AEAD.  The proposal was to use the record sequence number and pad with zeros as described in pull request 155 (https://github.com/tlswg/tls13-spec/pull/155/files <https://github.com/tlswg/tls13-spec/pull/155/files>).  This was also discussed in the IETF-92 meeting in Dallas along with options to change the offset.  The consensus was to stay with the original proposal.  We are posting to the mailing list to confirm this consensus. If you have comments,  please reply by April 17, 2015.  
> 
> Thanks,
> 
> S&J