Subject: [TLS] Pull Request: Removing the AEAD explicit IV

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Mar 2015 16:54:56 -0700

PR: https://github.com/tlswg/tls13-spec/pull/155
Target merge date: 3/21

Currently:

- AES-GCM uses a partially explicit nonce
- The ChaCha20 draft uses the sequence number as the nonce.

As Stephen Kent has observed, the idea behind the explicit IV is to allow
the
cryptographic module implementing the AEAD algorithm to ensure non-reuse
of the nonce. However, for ChaCha I believe we came to the conclusion that
it
was acceptable to use the sequence number as the nonce, as the module can
check for sequential usage. This saves 8 octets on the wire.

In the interim in Seattle, we came to the conclusion that we should make
all AEAD algorithms behave this way, which also simplifies the spec some.
I've formatted this into a PR to verify the consensus on the list. Please
comment
here if you object and on the PR if you have editorial comments.

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

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Tue, 17 Mar 2015 14:06:52 -0400

Sorry for being pedantic but...

The Nonce is the fixed (per connection) part of the quantity of bits 
that are encrypted to produce one block of cipher text that's XOR'd with 
the plain text to produce the encrypted message block.   The Nonce plus 
the message sequence number is the per-message initialization vector.   
The Nonce plus the message sequence number plus the block number is the 
per block value to be encrypted.   At least for CCM and GCM.

The Nonce is common across all messages within a session. (*sigh* the 
more general meaning of nonce is that of a unique per-invocation value 
but given that all per-message/per-block "nonce" usages contain the 
per-connection nonce it would be useful to not overload this too much - 
among other reasons:  an IV is not always a nonce but can be, a nonce is 
not usually an IV but can be, most messages require an IV, most blocks 
don't).  So maybe we call this the "Session Nonce" for clarity?

In original TLS, the IV produced during session setup was actually not 
"the" IV, but "an" IV used for the first message.  Then McGrew's AEAD 
modes repurposed the IV data produced as a nonce for the AEAD modes.

So what you're proposing is to eliminate the determination of the Nonce 
as part of the session negotiation and make it a fixed value.  E.g., we 
have an explicit nonce which is always zero which produces a per-message 
IV based on the sequence number of '0's | <sequence counter> | <block 
counter>.  As a side effect that also eliminates the per-message IV 
field (which aren't actually used by the currently defined AEAD modes 
AFAICT).

That works for the currently defined pure AEAD modes (CCM/GCM at least, 
haven't looked at chacha).   Will that work in all cases for constructed 
AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode 
and an integrity mode and derive the E and I keys from a single key 
internal to the constructed mode - say AES-CBC with CMAC for example).  
Short answer is probably not.

Basically, this complete eliminates the ability to use CBC (or any 
cipher mode that requires an explicit per message IV) from TLS. Not 
arguing for or against this at this point, but not clear that everyone 
understands the side effects of this decision.

Mike

On 3/16/2015 7:54 PM, Eric Rescorla wrote:
> As Stephen Kent has observed, the idea behind the explicit IV is to 
> allow the
> of the nonce. However, for ChaCha I believe we came to the conclusion 
> that it
> I've formatted this into a PR to verify the consensus on the list. 
> Please comment
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Tue, 17 Mar 2015 11:21:24 -0700

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns
<[email-masked]> wrote:
> AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode and
> an integrity mode and derive the E and I keys from a single key internal to
> the constructed mode - say  AES-CBC with CMAC for example).  Short answer is
> probably not.

I believe that it will, although I welcome counterexamples.

The AEAD interface requires only an nonce (i.e. unique, but not
unpredictable) and, under this proposal, that's all that TLS will
provide.

CBC modes require an IV (i.e. unpredictable). If you wished to make an
AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something
like this:

Define the key length to be twice as large as the AES key and split it
internally into a CBC key and an IV key. For each record, generate the
IV by AES(key = IV_key, block = nonce) then encrypt the plaintext
using CBC with that IV and the CBC key. (And you might need extra key
bytes for the HMAC too, but that's beside the point here.) Basically
you can generate the IVs using AES-CTR as a PRNG.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Mar 2015 11:22:09 -0700

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <[email-masked]>
wrote:

> The Nonce is the fixed (per connection) part of the quantity of bits that
> are encrypted to produce one block of cipher text that's XOR'd with the
> plain text to produce the encrypted message block.   The Nonce plus the
> message sequence number is the per-message initialization vector.   The
> Nonce plus the message sequence number plus the block number is the per
> block value to be encrypted.   At least for CCM and GCM.
>
> more general meaning of nonce is that of a unique per-invocation value but
> given that all per-message/per-block "nonce" usages contain the

I realize that the terminology is confusing, but I'm using the terms from
RFC 5116
section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this
context, the
nonce is not per-connection but rather per AEAD function invocation:

      A nonce N.  Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key, unless each and every nonce is zero-
      length.

In this context, the AEAD function is invoked once for each TLS record
encryption.

> So what you're proposing is to eliminate the determination of the Nonce as
> part of the session negotiation and make it a fixed value.  E.g., we have
> an explicit nonce which is always zero which produces a per-message IV
> based on the sequence number of '0's | <sequence counter> | <block
> counter>.  As a side effect that also eliminates the per-message IV field
> (which aren't actually used by the currently defined AEAD modes AFAICT).
>

AES-GCM uses this field, which is the motivation for this change.

> Basically, this complete eliminates the ability to use CBC (or any cipher
> mode that requires an explicit per message IV) from TLS.  Not arguing for
> or against this at this point, but not clear that everyone understands the
> side effects of this decision.
>

As discussed at the interim, I don't believe that this is correct. See
AGL's message
for a proposed construction.

-Ekr

Mike
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Mar 2015 22:19:53 +0200

> On Mar 17, 2015, at 8:21 PM, Adam Langley <[email-masked]> wrote:
> 

Right. Or you could do like in https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 , generate the IV randomly and locally and call it part of the ciphertext (see appendix A). The AEAD interface has no requirement that the ciphertext have the same length as the plaintext. In fact CBC requires padding, so the ciphertext is larger anyway.

I do like your way better, but it requires a larger state on both client and server. 

I’m also wondering if we can mass convert all the existing CBC ciphersuites for TLS 1.3, so that ciphersuite 0x00,0x0a could be TLS_RSA_WITH_3DES_EDE_CBC_SHA in TLS 1.2, but transform into one of these AEAD constructions for TLS 1.3 without having to allocate new identifiers.

Yoav

---

From: Michael StJohns <[email-masked]>
Date: Wed, 18 Mar 2015 11:31:44 -0400

> you can generate the IVs using AES-CTR as a PRNG.

I wouldn't use AES-CTR to generate IVs for AES-CBC, but I take your 
point.    I was actually asking about more than CBC.  See below.

This is what I got from SP800-38A appendix C
> For the CBC and CFB modes, the IVs must be unpredictable. In 
> particular, for any given plaintext, it must not be possible to 
> predict the IV that will be associated to the plaintext in advance of 
> the generation of the IV.

> There are two recommended methods for generating unpredictable IVs. 
> The first method is to apply the forward cipher function, under the 
> same key that is used for the encryption of the plaintext, to a nonce. 
> The nonce must be a data block that is unique to each execution of the 
> encryption operation. For example, the nonce may be a counter, as 
> described in Appendix B, or a message number. The second method is to 
> generate a random data block using a FIPS-approved random number 
> generator.

But that's what's defined for CBC and will work with the per-session 
nonce with per-message sequence number as described above.

While at this time we've only got defined cipher suites for CBC, CCM and 
GCM, (and I should have stated my comment more to this point), will 
there never be other potential modes that provide some desired security 
characteristics not currently present that also require explicit 
per-message IVs?

Eliminating the message-wrapping down to the AEAD construct is one thing 
as you can build AEAD modes out of other modes.  I wonder that we're 
constraining the protocol so much that other, useful, modes might be 
excluded in the future.   E.g. will any of the modes on this list 
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html end up 
in TLS cipher suites at some point?  Of these, which require per-message 
IVs that can't be generated as above?

---

From: Michael StJohns <[email-masked]>
Date: Wed, 18 Mar 2015 11:48:39 -0400

On 3/17/2015 2:22 PM, Eric Rescorla wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The Nonce is the fixed (per connection) part of the quantity of
>     bits that are encrypted to produce one block of cipher text that's
>     XOR'd with the plain text to produce the encrypted message
>     block.   The Nonce plus the message sequence number is the
>     per-message initialization vector.   The Nonce plus the message
>     sequence number plus the block number is the per block value to be
>     encrypted.   At least for CCM and GCM.
>
>     The Nonce is common across all messages within a session.  
>     (*sigh* the more general meaning of nonce is that of a unique
>     per-invocation value but given that all per-message/per-block
>     "nonce" usages contain the per-connection nonce it would be useful
>     to not overload this too much - among other reasons:  an IV is not
>     always a nonce but can be, a nonce is not usually an IV but can
>     be, most messages require an IV, most blocks don't).  So maybe we
>     call this the "Session Nonce" for clarity?
>
>
> I realize that the terminology is confusing, but I'm using the terms 
> from RFC 5116

David used Nonce properly here, but it becomes confusing when taken to 
using the same key with multiple messages.

Each message ALSO needs a Nonce - e.g. a unique value.  But the other 
term for a per-message nonce is generally an IV.  At the message level a 
nonce is always an IV but an IV isn't always a nonce.

We form the per-message nonce (e.g. the IV) from the per-session nonce 
and the per-message sequence number and a fixed value.  That's also the 
per-block nonce for the first block.

So being clearer - using Session Nonce for the value that's the same 
with all messages and using IV (which is also a per-message Nonce for 
CCM and GCM and should be described as such) for the value used to 
initialize the per-message encryption/decryption/sign/verify would 
probably make things clearer rather than trying to figure out *which* 
Nonce we're talking about.

>
>     So what you're proposing is to eliminate the determination of the
>     Nonce as part of the session negotiation and make it a fixed
>     value.  E.g., we have an explicit nonce which is always zero which
>     produces a per-message IV based on the sequence number of '0's |
>     <sequence counter> | <block counter>. As a side effect that also
>     eliminates the per-message IV field (which aren't actually used by
>     the currently defined AEAD modes AFAICT).
>
>

Yup.  Forgot about that.  Mainly because I thought implementers were 
interpreting the "

The nonce_explicit MAY be the 64-bit sequence number." as if the GCMNonce package/explicit IV could be omitted.  Didn't actually make sense not to do it that way.

For this you're going to set the "SALT" to all zeroes instead of getting them from the IV field of the master secret expansion  - correct?

>
>     That works for the currently defined pure AEAD modes (CCM/GCM at
>     least, haven't looked at chacha). Will that work in all cases for
>     constructed AEAD modes?  (e.g. where we build an AEAD mode out of
>     an encryption mode and an integrity mode and derive the E and I
>     keys from a single key internal to the constructed mode - say 
>     AES-CBC with CMAC for example).  Short answer is probably not.
>
>     cipher mode that requires an explicit per message IV) from TLS. 
>     Not arguing for or against this at this point, but not clear that
>     everyone understands the side effects of this decision.
>
>

Yup.

>>     As Stephen Kent has observed, the idea behind the explicit IV is
>>     to allow the
>>     of the nonce. However, for ChaCha I believe we came to the
>>     conclusion that it
>>     I've formatted this into a PR to verify the consensus on the
>>     list. Please comment
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Mar 2015 08:58:39 -0700

On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns <[email-masked]>
wrote:

> Each message ALSO needs a Nonce - e.g. a unique value.  But the other term
> for a per-message nonce is generally an IV.  At the message level a nonce
> is always an IV but an IV isn't always a nonce.
>

The term in RFC 5116 uses for this input is "nonce". I don't think it's
helpful
to use a different term here than is used in RFC 5116. Please note that
all the ciphers here need to conform to the RFC5116 interface, so whatever
the individual ciphers call their nonce inputs is not relevant here.

We form the per-message nonce (e.g. the IV) from the per-session nonce and
> the per-message sequence number and a fixed value.  That's also the

In this PR there is no fixed value. We simply use the sequence number and
pad to
the left as required, so I don't think there should be much room for
confusion.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Wed, 18 Mar 2015 18:36:58 -0400

On 3/18/2015 11:58 AM, Eric Rescorla wrote:
>
>
> On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns 
>     David used Nonce properly here, but it becomes confusing when
>     taken to using the same key with multiple messages.
>
>
>     Each message ALSO needs a Nonce - e.g. a unique value. But the
>     other term for a per-message nonce is generally an IV.  At the
>     message level a nonce is always an IV but an IV isn't always a nonce.
>
>
> The term in RFC 5116 uses for this input is "nonce". I don't think 
> it's helpful

David used David's language for 5116.  It's instructive to note Russ's 
language in the CCM RFC matches what ended up in the NIST version, but 
that David's language in his GCM RFC didn't match what ended up in the  
document he sent proposing GCM to NIST nor what NIST finally published 
as the mode.  I'm not sure why that is. From David's GCM submission:

> The primary purpose of the IV is to be a nonce, that is, to be 
> distinct for each invocation of the encryption operation for a fixed key.

Then there's the mixture of the IV with the salt to form a nonce in the 
GCM IPSEC document that's yet another different way of putting it.

If you say "IV" or Initialization Vector - I know that's the value I 
need to begin encryption or decryption of a message.  If you say Nonce, 
I have no idea of whether its an IV, a value mixed in to indicate 
timeliness (e.g. a challenge nonce), a per-session/per-sender nonce 
that's used as part of the IV to allow the same key to be used by 
multiple senders or what.

Ah well....

>
>
>     We form the per-message nonce (e.g. the IV) from the per-session
>     nonce and the per-message sequence number and a fixed value. 
>     That's also the per-block nonce for the first block.
>
>
> In this PR there is no fixed value. We simply use the sequence number 
> and pad to

This is kind of sophistry.  Padding to the left is exactly equivalent to 
"fixed nonce of zeros".

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Mar 2015 15:39:25 -0700

On Wed, Mar 18, 2015 at 3:36 PM, Michael StJohns <[email-masked]>
wrote:

> David used David's language for 5116.
>

Perhaps, but this is the document we are normatively referencing for AEAD.

-Ekr

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 18 Mar 2015 21:00:18 -0700

I don't object, but for the sake of debate I do want to ask how much
deference we owe to RFC5116 here?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Mar 2015 21:10:08 -0700

> deference we owe to RFC5116 here?

Only as much as we need to get the job done.  It establishes
terminology for a thing we use (i.e., the AEAD "API").

I don't see any reason not to use the term "nonce" as used in RFC
5116.  It's not imprecise in any way.  It's arguably more correct than
"IV", which has conflicting connotations.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 18 Mar 2015 21:21:34 -0700

I'm afraid that by radically changing the record layer we may be
working ourselves into a corner. If we're going to make a change this
radical, why not make equally radical changes to simplify the protocol
further if that's possible? I'm also not sure what we're supposed to
be gaining from this change: while it's true that we don't need to
send the explicit nonce, I don't know that we are losing anything from
having it. Yes, I know the ChaCha draft does it a seemingly more
sensible way, but the last thing we need is to further increase the
codesize of TLS implementations.

I do know that a recently implemented extension to FreeBSD won't work
anymore without some changes. (see
http://2015.asiabsdcon.org/timetable.html.en#P7A for an abstract)

Sincerely,
Watson Ladd

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 18 Mar 2015 21:24:20 -0700

Why would the extension break?

-- 
Colm

---

From: Watson Ladd <[email-masked]>
Date: Wed, 18 Mar 2015 21:43:31 -0700

> Why would the extension break?

Because it currently supports the TLS 1.2 record layer and AEAD mode,
not the now different TLS 1.3 one. I confirmed this would be a minor
issue with the author yesterday.  Sure, we can say that for any
implementation, and this hasn't yet made it into the wild yet, but now
both the kernel and userland sides need changes for TLS 1.3. Add in
some release cycles and LTS releases, and you get some more sites that
will not upgrade for a long time. It's not the only example: I've
heard rumors that some implementations do the record layer in more
unusual ways, while having the handshake in more softwarelike things.

I'm not claiming this is a particularly big nit, rather something that
tells me to lean on the conservative side when changing things related
to the record layer as compared to the handshake.

Sincerely,
Watson Ladd

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

---

From: Brian Smith <[email-masked]>
Date: Thu, 19 Mar 2015 01:33:57 -1000

Watson Ladd <[email-masked]> wrote:
> If we're going to make a change this
> further if that's possible?

That's already happening.

> I'm also not sure what we're supposed to
> having it.

1. The explicit nonce is a place to potentially leak secret data.
2. The explicit nonce is a place where a PRNG could be used poorly,
and/or a poor PRNG could be used.
3. Security properties of an explicit nonce cannot practically be
verified by the receiver, whereas the receiver could (and in fact
would have to) verify that an implicit nonce based on the record
sequence number is safe.
4. The implicit IV reduces per-record overhead on the wire by 16 or 32
bytes. For some applications that's substantial.

There are other advantages that aren't so simple to describe.

> Yes, I know the ChaCha draft does it a seemingly more

This change would not contribute substantial complexity to most TLS
libraries that would implement it. Most TLS libraries already have
similar logic to deal with implicit vs. explicit IVs in CBC mode for
SSL3/TLS1 vs. TLS 1.1+.

Also, the proposed changes to the handshake state machine for TLS 1.3
are much larger. It seems we can't substantially simplify the protocol
proportionately increasing the complexity of implementations that need
to also implement earlier versions.

Cheers,
Brian

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Mar 2015 09:20:54 -0700

> That's already happening.

No it's not: the draft is still longer than the TLS 1.2 RFC, and seems
to demand support for every single usecase. This seems at odds with
absolute simplification, where we would throw out less important
features, and radically reduce the complexity.

> and/or a poor PRNG could be used.

You are not supposed to use random nonces with GCM.

> would have to) verify that an implicit nonce based on the record

The receiver cannot determine that the sender isn't sending an extra
copy to the secret police anyway. Of course, this implicit nonce
strategy will prevent certain bugs involving being unable to count,
and may be worth it.

> bytes. For some applications that's substantial.

This is an actual advantage.
> similar logic to deal with implicit vs. explicit IVs in CBC mode for

A million here, a million there: pretty soon you start spending real money.

> to also implement earlier versions.

Adding new states and transitions to a state machine doesn't increase
complexity that much: if the transition doesn't apply, you don't take
it. But adding additional special casing all over the place to deal
with TLS 1.3 does increase complexity much more.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 09:25:47 -0700

On Thu, Mar 19, 2015 at 9:20 AM, Watson Ladd <[email-masked]> wrote:

> No it's not: the draft is still longer than the TLS 1.2 RFC,

The TLS 1.3 draft is 91 pages long (
https://tools.ietf.org/html/draft-ietf-tls-tls13-05)
RFC 5246 is 103 pages long (https://tools.ietf.org/html/rfc5246)

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Mar 2015 10:02:39 -0700

> RFC 5246 is 103 pages long (https://tools.ietf.org/html/rfc5246)

Thanks for the correction.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Mar 2015 19:40:01 +0200

> features, and radically reduce the complexity.

Got examples of features that could be removed or at least rendered
truly optional (besides things like 0RTT[1])?

> with TLS 1.3 does increase complexity much more.

Unfortunately, to fix the TLS handshaking mechanism, calls for handshake
totally different from one TLS 1.2 has.

The overall architecture of TLS 1.3 handshake looks good to me, the
divisions it makes look to harden the handshake a lot against various
attacks. Unfortunately, the handshake currently looks to have rather large
implementation security gap.

Additionally, in practice, the capablity to send a handshake that can
be downnegotiated is needed.

[1] If 0RTT was an extension with positive acknowledgement, server could
just leave it unimplemented and things would still work, albeit possibly
with extra RTT.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 10:52:18 -0700

> just leave it unimplemented and things would still work, albeit possibly

I agree it must be possible to do a server that does not do 0-RTT.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Thu, 19 Mar 2015 10:55:54 -0700

> truly optional (besides things like 0RTT[1])?

Update: most connections are short-lived. Changing client auth state during
a connection: restarting works fine. The 1 RTT idea being proposed involves
remembering unnecessary state.

AGL mentioned the ability to have fragmentation of Client Hellos in the
record layer.

> be downnegotiated is needed.

This should be doable without increasing the complexity of current code
that much. The issue with the handshake isn't so much the parsing (
although nested length encoding is a bad idea, compared to length encoded
tokens) but the state machine. Adding new transitions and states carefully
shouldn't be too bad.

Most implementations already keep a ruuning hash, so the enhanced handshake
prorocol can fit in. We should tighten up the description significantly,
explaining exactly which steps are expected when.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 11:27:49 -0700

On Thu, Mar 19, 2015 at 10:55 AM, Watson Ladd <[email-masked]> wrote:

> Update: most connections are short-lived.
>
At the interim we discussed having a simple re-key mechanism that
was less general than Update. I think we could have that but nothing
would also probably be fine.

Changing client auth state during a connection: restarting works fine.

Would that this were so. Unfortunately, there are existing HTTP-based
systems
which rely on this feature and will be fairly put out if we don't supply
it. That may
not be a totally dispositive argument, but re-starting is not really a
drop-in
replacement.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Mar 2015 20:31:05 +0200

> remembering unnecessary state.

Update as an extension?

I think splitting the secrets for both directions is a good idea: The
secrets can be derived just before being needed (which cuts down oppurtunity
for errors) and one can just derive the symmetric keys from both.

Additionally, changing client auth state during a connection can be very
dangerous (it depends on protocol riding on top and the context it runs
in).

Client-to-server IRCS? OK. HTTP/2 from web browser? Ouch.
 
> AGL mentioned the ability to have fragmentation of Client Hellos in the

Doesn't seem to be really needed, except for certificate messages. No
other messages seem to be large enough to warrant record-layer fragmentation
under reasonable conditions.

Heck, even dh8k keyshare message (which is likely the largest handshake
message in practice aside of certificates) easily fits inside one IPv6
minMTU datagram, complete with all the needed headers.

> explaining exactly which steps are expected when.

Agreed, the endpoints should always know what is to be sent or received
next (and anything else is an protocol error).

A few weeks back I tried to construct a state machine for TLS 1.3. The
nasty problem I ran into was handling the handshake "restart" (the
state machine can't ever be allowed to loop). Also, client certificate
handling caused problems.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Thu, 19 Mar 2015 09:53:54 -1000

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

My concern about this is the same one already raised on the CFRG mailing list:
   http://www.ietf.org/mail-archive/web/cfrg/current/msg04867.html
in response to:
   http://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html

In particular, massively parallel attacks on many keys at once seem
like the most promising way to break AES-128. It seems bad to have
popular endpoints encrypting the same plaintext block (e.g. "GET /
HTTP/1.1\r\n") with the same nonce (1) with different keys. That seems
like exactly the recipe for making such attacks succeed.

It seems like it would be better, instead, to require that the initial
nonces to be calculated from the keyblock established during key
agreement, and then have them incremented as counters (with
wraparound) in the same fashion as being proposed. This, combined with
the fact that the key agreement will always be using ephemeral keys,
should prevent any such massively-parallel attack from working.

Note that this is a concern more for AES-128 than it is for ChaCha20
because ChaCha20 mitigates the issue by using a 256-bit key.

Other than disagreeing with how the initial nonce is determined, I
agree that the implicit counter approach is better than the explicit
per-record nonce approach.

I think this issue should be addressed before this change is made.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 12:58:30 -0700

> like exactly the recipe for making such attacks succeed.

Are other people concerned about this issue? I seem to remember this
being discussed in the interim and AGL being opposed to this change.

> agreement,

Is there any reason why these should be derived from the keyblock
as opposed to from purely public information such as the random
values?

> and then have them incremented as counters (with
> wraparound) in the same fashion as being proposed.

Can you explain why you think they need to change? I note that TLS 1.2
currently does not behave in this fashion.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Thu, 19 Mar 2015 10:11:40 -1000

> as opposed to from purely public information such as the random

Intuitively, I expect the attacker to have more difficulty if they
don't know the nonce than if they do. In general, we should not
divulge more than the minimum amount of information in cleartext. And,
in particular, one of the design goals is to encrypt as much of the
handshake as possible, and the nonce selection is part of the
handshake.

I wouldn't be surprised if somebody pointed out a good reason to avoid
deriving them out of the key block, though I don't know of one now.

> currently does not behave in this fashion.

I think you interpreted my suggested as <initial-nonce> || <record
sequence number>. I just mean that the per-record nonce should be
calculated as <initial-nonce> + <record sequence number>. It seems
better to start all the initial bits of the nonce in a randomly-chosen
state, instead of just a prefix, if there's no conflicting
considerations to do otherwise.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Mar 2015 13:17:51 -0700

On Thu, Mar 19, 2015 at 1:11 PM, Brian Smith <[email-masked]> wrote:

> sequence number>.

I did. It doesn't help here that TLS uses '+' for concatenation :(

> I just mean that the per-record nonce should be

So to be clear we would generate a random V of length
N_MIN and then for each record the nonce would be
SN + V?

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Mar 2015 13:25:20 -0700

> being discussed in the interim and AGL being opposed to this change.

I would phrase it as an extended key to the AEAD and keep the nonce
the same, but I'm not opposed so starting at a random point in the
nonce space and counting from there. However, since the AES-GCM AEAD
is already defined I can see the practical argument for having TLS do
the nonce masking.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 19 Mar 2015 22:31:41 +0200

> deriving them out of the key block, though I don't know of one now.

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 supporting "hardware", there are values in TLS that are both
public and have to be derived from key block, so any HSM has to know
about TLS to be able to know what should be exportable and what isn't.

And if the HSM accepts arbitrary nonces, one can break the encryption
fast.

> considerations to do otherwise.

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).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Mar 2015 11:58:06 -0700

Adam, Brian, what would you think of XOR rather than addition?

E.g., generate a per-connection value V and then do:

Nonce = Seq XOR V?

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Sat, 21 Mar 2015 12:20:24 -0700

> E.g., generate a per-connection value V and then do:

It's invertable so can't break uniqueness. So that would be ok too. Is
V a 12-byte (or whatever) value and thus fixes the upper 4 (or
whatever) bytes of the nonce?

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Mar 2015 12:22:44 -0700

> whatever) bytes of the nonce?

I was thinking that we would generate an N_MIN long V and XOR
it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 21 Mar 2015 21:53:56 +0200

> it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed.

A few thing to note:

- RFC5116 allows N_MIN=0, which means the scheme can operate without
  nonces, but there doesn't seem to be any such registered algorithms.
- There are registred AEAD algorithms with N_MIN<8, N_MAX>8.
- Some registered algorithms have huge N_MAX.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Mar 2015 13:04:03 -0700

> > it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed.

I meant N_MIN here, btw.

> - There are registred AEAD algorithms with N_MIN<8, N_MAX>8.

This is the one that concerns me (though the general problem is a concern
for all of these).

Perhaps instead use max(N_MIN, 8)?

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Sun, 22 Mar 2015 16:10:56 -1000

> E.g., generate a per-connection value V and then do:

Would the sequence number be logically the same size as the nonce (128
bits or 256 bits), or would the spec will forbid sending 2^64 or more
records under the same key? Either solution prevents the need to worry
about the record number overflowing, but my answer depends on which
approach is chosen.

The advantage of XOR is that it is easy to implement correctly,
because mutli-machine-word XOR is easier to implement than
multi-machine-word unsigned integer addition with wraparound during
overflow. However, XOR is also easier to implement *wrongly* without
anybody noticing, by only doing the XOR for a single machine word
(e.g. only the lower 32 bits on a 32-bit machine). It's not so
practical to do a conformance test that sends/receives 2^32+1 or
2^64+1 records..

It seems harder to implement addition wrongly without anybody noticing
because all of the overflow cases should be triggered during interop
testing and thus any bugs found and corrected. So, without knowing the
answer to my question above, I prefer addition.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Mar 2015 20:20:27 -0700

On Sun, Mar 22, 2015 at 7:10 PM, Brian Smith <[email-masked]> wrote:

> records under the same key?

What I had in mind was the latter.

-Ekr

> Either solution prevents the need to worry

---

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Mar 2015 20:37:18 -0700

> What I had in mind was the latter.

I don't think that we are in a position to have more than 2^64 records
sent.  Not that I expect anyone will need that.  (in the spirit of the
640K limit :)