Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

From: Aaron Zauner <[email-masked]>
Date: Wed, 1 Mar 2017 13:11:25 +0000

> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Sean, Joe, Eric and all,
> 
> I would like to address my thoughts/suggestions on 2 issues in option a.
> 
> 1) The data limit should be addressed in term of blocks, not records. When the record size is not the full size, some user might not know what to do. When the record size is 1 block, the limit of 2^24.5 blocks (records) is way too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-block records is the limit which still achieves the margin of 2^-60.

I respectfully disagree. TLS deals in records not in blocks, so in the end any semantic change here will just confuse implementors, which isn't a good idea in my opinion.

Aaron

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 1 Mar 2017 13:18:54 +0000

From: Aaron Zauner <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Sean Turner <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, IRTF CFRG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option a.
1) The data limit should be addressed in term of blocks, not records. When the record size is not the full size, some user might not know what to do. When the record size is 1 block, the limit of 2^24.5 blocks (records) is way too low unnecessarily for the margin of 2^-60.  In that case, 2^34.5 1-block records is the limit which still achieves the margin of 2^-60.

Over the discussion of the PRs, the preference was blocks.

Quynh.

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 1 Mar 2017 14:24:37 +0000

> On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> 
> 
> From: Aaron Zauner <[email-masked]>
> To: 'Quynh' <[email-masked]>
> Cc: Sean Turner <[email-masked]>, "<[email-masked]>" <[email-masked]>, IRTF CFRG <[email-masked]>

I don't see a clear preference. I see Brian Smith suggested switching to blocks to be more precise in a PR. But in general it seems to me that "Option A" was preferred in this thread anyhow - so these PRs aren't relevant? I'm not sure that text on key-usage limits in blocks in a spec that fundamentally deals in records is less confusing, quite the opposite (at least to me). As I pointed out earlier: I strongly recommend that any changes to the spec are as clear als possible to engineers (non-crypto/math people) -- e.g. why the spec is suddenly dealing in blocks instead of records et cetera. Again; I really don't see any reason to change text here - to me all suggested changes are even more confusing.

Aaron

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 1 Mar 2017 14:31:30 +0000

Date: Wednesday, March 1, 2017 at 9:24 AM

On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Aaron,

The  technical reasons I explained are reasons for using records. I don’t see how that is confusing.

If you like records, then the record number = the total blocks / the record size in blocks: this is simplest already.

Quynh.

Aaron

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 1 Mar 2017 14:38:04 +0000

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
<[email-masked] on behalf of [email-masked]> wrote:
>>>>>1) The data limit should be addressed in term of blocks, not records.
>>>>>When the record size is not the full size, some user might not know
>>>>>what to do. When the record size is 1 block, the limit of 2^24.5
>>>>>blocks (records) is way too low unnecessarily for
>>>>> the margin of 2^-60.  In that case, 2^34.5 1-block records is the
>>>>>limit which still achieves the margin of 2^-60.
>>>>I respectfully disagree. TLS deals in records not in blocks, so in the
>>>>end any semantic change here will just confuse implementors, which
>>>>isn't a good idea in my opinion.
>>I don't see a clear preference. I see Brian Smith suggested switching to
>>blocks to be more precise in a PR. But in general it seems to me that
>>"Option A" was preferred in this thread anyhow - so these PRs aren't
>>relevant? I'm not sure that text on key-usage
>> limits in blocks in a spec that fundamentally deals in records is less
>>confusing, quite the opposite (at least to me). As I pointed out
>>earlier: I strongly recommend that any changes to the spec are as clear
>>als possible to engineers (non-crypto/math people)
>> -- e.g. why the spec is suddenly dealing in blocks instead of records
>>et cetera. Again; I really don't see any reason to change text here - to
>>me all suggested changes are even more confusing.
>>
>>
>
>
>Hi Aaron,
>
>
>If you like records, then the record number = the total blocks / the
>record size in blocks: this is simplest already.
>

That formula does not correctly compute how many records have been sent on
a connection, because the record size in blocks is variable, not constant.
You can modify it to get bounds on the total number of records sent, but
the bounds are sloppy because some records only consume 2 blocks (one for
encryption, one for masking in GHASH) while some consume far more.

It's simpler for an implementation to count how many records have been
sent on a connection .... by using the connection's sequence number. This
puts less burden on the implementation/implementer.

Cheers

Kenny

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 1 Mar 2017 14:48:36 +0000

From: "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 9:38 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, Aaron Zauner <[email-masked]<mailto:[email-masked]>>
Cc: IRTF CFRG <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
From: Aaron Zauner <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Sean Turner <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, IRTF
CFRG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).

On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
From: Aaron Zauner <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Sean Turner <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>, IRTF
CFRG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>>
wrote:
Hi Sean, Joe, Eric and all,
I would like to address my thoughts/suggestions on 2 issues in option
a.
1) The data limit should be addressed in term of blocks, not records.
When the record size is not the full size, some user might not know
what to do. When the record size is 1 block, the limit of 2^24.5
blocks (records) is way too low unnecessarily for
the margin of 2^-60.  In that case, 2^34.5 1-block records is the
limit which still achieves the margin of 2^-60.
I respectfully disagree. TLS deals in records not in blocks, so in the
end any semantic change here will just confuse implementors, which
isn't a good idea in my opinion.
Over the discussion of the PRs, the preference was blocks.

Hi Aaron,

The  technical reasons I explained are reasons for using records. I don’t
see how that is confusing.

I think the record size is configurable and it does not change regularly in the same session (or connection).  Somebody corrects me here!

Quynh.

Cheers

Kenny

---

From: Watson Ladd <[email-masked]>
Date: Wed, 1 Mar 2017 10:36:57 -0800

That is not how HTTP works. Lots of records are small because they result
from small writes.

On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)" <[email-masked]> wrote:

>
>
> From: "Paterson, Kenny" <[email-masked]>
> To: 'Quynh' <[email-masked]>, Aaron Zauner <[email-masked]>
> Cc: IRTF CFRG <[email-masked]>, "<[email-masked]>" <[email-masked]>
> I think the record size is configurable and it does not change regularly
> in the same session (or connection).  Somebody corrects me here!
>
> Quynh.
>
>
>
> Cheers
>
> Kenny
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 1 Mar 2017 18:44:08 +0000

From: Watson Ladd <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 1:36 PM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Aaron Zauner <[email-masked]<mailto:[email-masked]>>, "Paterson, Kenny" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

That is not how HTTP works. Lots of records are small

OK. What is the percentage ? Even all records were small, providing a correct number would be a good thing. If someone wants to rekey a lot often, I am not suggesting against that.

Quynh.

because they result from small writes.

On Mar 1, 2017 6:48 AM, "Dang, Quynh (Fed)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Hi Aaron,

Quynh.

Cheers

Kenny

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Mar 2017 08:18:21 +1100

On 2 March 2017 at 05:44, Dang, Quynh (Fed) <[email-masked]> wrote:
> OK. What is the percentage ? Even all records were small, providing a
> correct number would be a good thing. If someone wants to rekey a lot often,
> I am not suggesting against that.

It will vary greatly depending on circumstance.  Most of the time the
record size matches the MTU.  Other times it matches the write size,
which can be only a small number of octets.  For bulk transfers it can
approach the record maximum.  All on the same connection sometimes.

I really don't know what you are suggesting here.  The point is the
accounting in terms of records doesn't really give you any insight
into the number of blocks.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 2 Mar 2017 11:00:59 +0000

From: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 1, 2017 at 4:18 PM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Cc: Watson Ladd <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

On 2 March 2017 at 05:44, Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>> wrote:
OK. What is the percentage ? Even all records were small, providing a
correct number would be a good thing. If someone wants to rekey a lot often,
I am not suggesting against that.

Hi Martin,

Thank you for the information.

In the PRs’ discussions, I saw that Brian and Rich wanted blocks. You, Eric and other people were comfortably discussing the issue in term of blocks. Implementing and running TLS were your career, so I made suggestions based on blocks.

Aaron wanted records, so I gave him the equation to figure that out. I did not mean to suggest to use records.

Quynh.

---

From: Brian Smith <[email-masked]>
Date: Thu, 2 Mar 2017 11:44:12 -1000

Aaron Zauner <[email-masked]> wrote:
> I'm not sure that text on key-usage limits in blocks in a spec
> that fundamentally deals in records is less confusing, quite
> the opposite (at least to me).

1. Consider an implementation that negotiates with another
implementation to use a very large record size such as 1MB records. If
the limit is specified in terms of records then the limit would need
to be readjusted to the new max record size, or else the new extension
is potentially unsafe to use. This shows that specifying the limits in
terms of records is brittle.

2. If it is only safe to use an AES-GCM key for a certain number of
blocks, where in the code is the best place to enforce the limit on
the number of blocks? IMO, it is better to enforce it in the AES-GCM
implementation itself, underneath the TLS layer. In that case the
limit is best expressed in terms of the number of blocks. Specifying
the limit in terms of records would be optimizing for implementations
that enforce the limit at the wrong layer of abstraction.

> As I pointed out earlier: I strongly recommend that any changes
> to the spec are as clear als possible to engineers
> (non-crypto/math people) -- e.g. why the spec is suddenly
> dealing in blocks instead of records et cetera. Again; I really
> don't see any reason to change text here - to me all suggested
> changes are even more confusing.

Given a limit in blocks, the arithmetic to keep track of the number of
blocks is trivial, and very similar to the arithmetic that's already
needed to split up a large byte stream into records and keep track of
the record sequence number.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 2 Mar 2017 15:15:28 -0800

I also think that counting in blocks is cleaner. Counting in bytes is a
close alternative.

I have a few nits below:

> terms of records is brittle.

Hm, while I agree that counting in wrong units is the main problem here,
we over-count with records, which means that we re-key faster than needed.

> that enforce the limit at the wrong layer of abstraction.

Given that the event of reaching the limit requires TLS-level action,
checking the limit at the TLS level seems reasonable. The lower-level
block-cipher code should still have the logic to error out (using a more
relaxed limit).

> the record sequence number.

Also please consider counting in bytes. This may be more natural,
especially with AES-GCM that doesn't expose higher levels to the block
size granularity (as much as CBC does, anyway).

---

From: Hal Murray <[email-masked]>
Date: Thu, 02 Mar 2017 17:54:18 -0800

> I also think that counting in blocks is cleaner. Counting in bytes is a

Does counting bytes work?  If the real limit is blocks, I think you will have 
to round up the byte count when you send a partial block.

If re-keying too often isn't too expensive, you could get a safe answer by 
counting bytes and assuming that every byte went in a separate block.

You might want to round down many more orders of magnitude so the re-key code 
gets exercised often enough.  Or maybe provide a back door to set the limit 
so that path can be tested with reasonable resources.

-- 
These are my opinions.  I hate spam.

---

From: Andrey Jivsov <[email-masked]>
Date: Thu, 2 Mar 2017 18:32:59 -0800

> so that path can be tested with reasonable resources.

I like the idea of setting the rekey limits, so that the code can be
tested. There is no 3DES in TLS 1.3.

You refer to some under-counting.

The worst case is mod 16 = 1 byte sized TLS records, in which case the
"tails" will only be counted as 1 block per 16 TLS records v.s. desired
16. We are undercounting less than one 16-byte block per record.

One can count in record_size_in_bytes + 16 as one solution (overcount).

However, is it true that 1-byte terminal blocks must be counted as full
16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs
with distinguishing game. With 1-byte plaintext / ciphertext we are not
making statements about two values from the 1^128 members space. Rather,
we are discussing two values from the tiny 256 members space. Also, a
truncated AES-GCM encryption behaves as PRF and not PRP.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Mar 2017 11:22:08 +0200

Hi

As an implementer I have no problem counting records, bytes or blocks (OK, the last you usually don’t count directly but (n+15)/16 is not beyond the capabilities of any implementer)

So IMO whichever gives the tightest bound should be selected, and that means blocks.

Exercising the rekey code is up to developers, not document writers.

Yoav

---

From: Sean Turner <[email-masked]>
Date: Thu, 9 Mar 2017 21:18:37 -0500

After many emails about the wording for s5.5 Limits on Key Usage, it’s time to judge consensus on whether or not to make any changes to that section.  The important thing is that the SHOULD implement the key update from s4.5.3 was never in question.  There was no consensus to change the actual GCM limits on key usage; again the text related to ChaCha20/Poly1305 never really was in question.  The discussion has wound down to whether it was better to count records or bytes/blocks for the GCM limit calculation.  We didn’t see any strong consensus to change this description.  Therefore, we see no consensus to change the text in s5.5.  ekr please close PR#765 and PR#769.

J&S

> On Feb 10, 2017, at 12:07 AM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13 Section 5.5 “Limits on Key Usage”.  As it relates to rekeying, these limits have been discussed a couple of times and we need to resolve once and for all whether the TLS WG wants to:
> 
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]
> 
> Please indicate you preference to the TLS mailing list before Feb 17.  Note that unless there’s clear consensus to change the text will remain as is (i.e., option a).
> 
> J&S
> 
> [0] https://tlswg.github.io/tls13-spec/#rfc.section.5.5
> [1] https://github.com/tlswg/tls13-spec/pull/765
> [2] https://github.com/tlswg/tls13-spec/pull/769

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Mar 2017 10:42:08 -0500

Thanks.  I agree.  I think that the existing text is more helpful to the implementer.  If the details of the analysis do in the document, it should be in the security considerations.

Russ

> On Mar 9, 2017, at 9:18 PM, Sean Turner <[email-masked]> wrote:
>