Subject: [TLS] Comments on nonce construction and cipher text size restriction.

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 24 May 2016 15:20:17 +0000

Hi Eric,

1. For this text:  "plus the length of the output of the signing algorithm. " in the last paragraph of Section 4.8.1, did you mean "plus the output of the signing algorithm." ?

2. "The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 256. An endpoint that receives a record that exceeds this length MUST generate a fatal "record_overflow" alert. " . There could be a cipher that generates ciphertext longer than plaintext in some cases plus the tag. If the tag was 256 bits, then this requirement would disallow that cipher unnecessarily when a record size is 2^14.

3. "The padded sequence number is XORed with the static client_write_iv or server_write_iv, depending on the role." I think the ivs are not needed.

4. The current way nonce is specified would disallow ciphers that use any other ways of generating the nonce such as random nonces.

Regards,

Quynh.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 09:13:45 -0700

On 24 May 2016 at 08:20, Dang, Quynh (Fed) <[email-masked]> wrote:
> 1. For this text:  "plus the length of the output of the signing algorithm.
> " in the last paragraph of Section 4.8.1, did you mean "plus the output of
> the signing algorithm.” ?

The text is correct.  It is talking about the length of the structure,
not its contents.

> 2. "The length (in bytes) of the following TLSCiphertext.fragment. The
> length MUST NOT exceed 2^14 + 256. An endpoint that receives a record that
> exceeds this length MUST generate a fatal "record_overflow" alert. " . There
> could be a cipher that generates ciphertext longer than plaintext in some
> cases plus the tag. If the tag was 256 bits, then this requirement would
> disallow that cipher unnecessarily when a record size is 2^14.

The value 256 is octets, not bits.  If you are aware of a need for an
authentication tag longer than 256 octets, now would be a great time
to tell all of us.

> 3. "The padded sequence number is XORed with the static client_write_iv or
> server_write_iv, depending on the role.” I think the ivs are not needed.

We discussed this at quite some length.  I originally took your
position, but the IVs add an extra layer of safety at very little
cost.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 May 2016 19:58:45 +0300

On Tue, May 24, 2016 at 03:20:17PM +0000, Dang, Quynh (Fed) wrote:
> Hi Eric,
> 
> 1. For this text:  "plus the length of the output of the signing
> algorithm. " in the last paragraph of Section 4.8.1, did you mean
> "plus the output of the signing algorithm." ?

The paragraph seems to talk about the length, so plus length of seems
correct.

> 2. "The length (in bytes) of the following TLSCiphertext.fragment.
> The length MUST NOT exceed 2^14 + 256. An endpoint that receives a
> record that exceeds this length MUST generate a fatal "record_overflow"
> alert. " . There could be a cipher that generates ciphertext longer
> than plaintext in some cases plus the tag. If the tag was 256 bits,
> then this requirement would disallow that cipher unnecessarily when
> a record size is 2^14.

It is not in bits, it is in bytes. So to blow the limit, you would need
cipher that expands the plaintext by 256 bytes (remember the typebyte
counts as plaintext input here).

And what algorithm would have >2040 bits of expansion?

Variable-tau MRAEs could have larger expansions, but practical
parameters limit expansion much below that value.

> 3. "The padded sequence number is XORed with the static client_write_iv
> or server_write_iv, depending on the role." I think the ivs are not
> needed.

Oh, they are needed (as in, security will be degraded if IVs are
removed).
 
> 4. The current way nonce is specified would disallow ciphers that
> use any other ways of generating the nonce such as random nonces.

None of the present algorithms is able to handle a random nonce,
you would need much longer nonces.

And also, it is much easier to just count than try to randomly
generate "nonces" (and as far as it is known, more secure,
due to random "nonces" having tendency to repeat).

And TLS breaks in truly catastrophic way if GCM nonce ever
repeats (and wasn't there just such problem in multiple TLS
implmenentations)?

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 24 May 2016 10:44:15 -0700

On Tue, May 24, 2016 at 9:13 AM, Martin Thomson <[email-masked]>
wrote:

> or

Is this more safe? wouldn't this disclose the key in the event that the
HKDF and the underlying hash turned out to have some cryptanalytical flaw
that meant it wasn't back-tracking resistant? I think otherwise TLS can
survive such a flaw because the output of the PRF is not directly
discernible on the wire.

-- 
Colm

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 24 May 2016 17:46:48 +0000

On 5/24/16, 12:13 PM, "Martin Thomson" <[email-masked]> wrote:

>>algorithm.
>> the signing algorithm.² ?
>

>authentication tag longer than 256 octets, now would be a great time

My misreading of the text. Thanks.
>> server_write_iv, depending on the role.² I think the ivs are not needed.
>

I don¹t see any extra layer here.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 24 May 2016 17:56:04 +0000

On 5/24/16, 12:58 PM, "[email-masked] on behalf of Ilari

>Oh, they are needed (as in, security will be degraded if IVs are

I don¹t think so. 

>you would need much longer nonces.

True. 
>due to random "nonces" having tendency to repeat).

I did not recommend using short random nonces. If the current construction
of nonces is for GCM, than that would be fine and recommended. But,
currently, it is written as for all ciphers.  If the construction of nonce
is not fixed, then an encryption mode just needs to specify its own way of
generating nonces. 

>repeats (and wasn't there just such problem in multiple TLS

See comment above. 

Quynh.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 May 2016 21:03:17 +0300

> survive such a flaw because the output of the PRF is not directly

It seems like failing backtracking resistance would need really major
breakage in PRF-hash. And the whole TLS will fall apart pretty badly
WAY before that point with broken PRF.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 11:42:59 -0700

> I don¹t see any extra layer here.

The argument here is that there are only 2^128 keys and some protocols
have predictable plaintext.  A predictable nonce would allow an
attacker to do some pre-calculation with a large number of keys to get
a chance of a collision (and a break).  It's a long bow, but not
entirely implausible.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 24 May 2016 19:00:27 +0000

>a chance of a collision (and a break).  It's a long bow, but not

Ciphers use nonces are designed/proved to be secure when nonces are
predictable: nonces are not random values.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 May 2016 12:04:29 -0700

> predictable: nonces are not random values.

I think you may be misunderstanding. There is a time/space tradeoff here
when the
nonces are predictable that does not exist when they are random. This is
not a
vulnerability in the cipher and applies even if the keystream generator at
the core
of the cipher is PRF_k(nonce).

-Ekr

---

From: Quynh Dang <[email-masked]>
Date: Tue, 24 May 2016 16:13:47 -0400

Are you worried about 2^96 precomputation and the risk of 1/2^32 of
cracking your key?

Quynh.
On May 24, 2016 3:05 PM, "Eric Rescorla" <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 May 2016 13:22:24 -0700

No, a smaller computation (say 2^{64}) and then collecting 2^{40}
connections all of which encipher the same plaintext (e.g., "GET /...")

-Ekr

On Tue, May 24, 2016 at 1:13 PM, Quynh Dang <[email-masked]> wrote:

>> vulnerability in the cipher and applies even if the keystream generator
>> at the core

---

From: Quynh Dang <[email-masked]>
Date: Tue, 24 May 2016 17:19:01 -0400

If that is what you are worried about, then that would make sense.

Quynh.
On May 24, 2016 4:23 PM, "Eric Rescorla" <[email-masked]> wrote:

>>> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed) <[email-masked]
>>> > wrote:
>>>
>>>>
>>>>