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

[Russ Housley]

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  wrote:
> 
> 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
> 
>> On Feb 10, 2017, at 12:07 AM, Sean Turner  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
>> 
>> [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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

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


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrey Jivsov]

On 03/02/2017 05:54 PM, Hal Murray wrote:
> 
> cry...@brainhub.org said:
>> I also think that counting in blocks is cleaner. Counting in bytes is a
>> close alternative. 
> 
> 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.
> 

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hal Murray]

cry...@brainhub.org said:
> I also think that counting in blocks is cleaner. Counting in bytes is a
> close alternative. 

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.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Brian Smith]

Aaron Zauner  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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

From: Martin Thomson <martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>>
Date: Wednesday, March 1, 2017 at 4:18 PM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>>, 
"c...@irtf.org<mailto:c...@irtf.org>" <c...@irtf.org<mailto:c...@irtf.org>>, 
"tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>
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) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 2 March 2017 at 05:44, Dang, Quynh (Fed)  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

From: Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>>
Date: Wednesday, March 1, 2017 at 1:36 PM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>>, 
"c...@irtf.org<mailto:c...@irtf.org>" <c...@irtf.org<mailto:c...@irtf.org>>, 
Aaron Zauner <a...@azet.org<mailto:a...@azet.org>>, "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
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)" 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:


From: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
Date: Wednesday, March 1, 2017 at 9:38 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, Aaron Zauner 
<a...@azet.org<mailto:a...@azet.org>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
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)"
<tls-boun...@ietf.org<mailto:tls-boun...@ietf.org> on behalf of 
quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner <a...@azet.org<mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner <a...@azet.org<mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
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.


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,


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.


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 s

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

[Watson Ladd]

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)" <quynh.d...@nist.gov> wrote:

>
>
> From: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk>
> Date: Wednesday, March 1, 2017 at 9:38 AM
> To: 'Quynh' <quynh.d...@nist.gov>, Aaron Zauner <a...@azet.org>
> Cc: IRTF CFRG <c...@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
> 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)"
> <tls-boun...@ietf.org on behalf of quynh.d...@nist.gov> wrote:
>
> From: Aaron Zauner <a...@azet.org>
> Date: Wednesday, March 1, 2017 at 9:24 AM
> To: 'Quynh' <quynh.d...@nist.gov>
> Cc: Sean Turner <s...@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
> CFRG <c...@irtf.org>
> Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769).
>
>
>
>
>
> On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) <quynh.d...@nist.gov> wrote:
> From: Aaron Zauner <a...@azet.org>
> Date: Wednesday, March 1, 2017 at 8:11 AM
> To: 'Quynh' <quynh.d...@nist.gov>
> Cc: Sean Turner <s...@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>, IRTF
> CFRG <c...@irtf.org>
> Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769).
>
> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) <quynh.d...@nist.gov>
> 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.
>
>
>
> 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,
>
>
> 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.
>
>
> 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.
>
>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

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


On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) 
> wrote:
From: Aaron Zauner >
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' >
Cc: Sean Turner >, 
">" >, IRTF 
CFRG >
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) 
> 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.

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,

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


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

From: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
Date: Wednesday, March 1, 2017 at 9:38 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, Aaron Zauner 
<a...@azet.org<mailto:a...@azet.org>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
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)"
<tls-boun...@ietf.org<mailto:tls-boun...@ietf.org> on behalf of 
quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner <a...@azet.org<mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 9:24 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).





On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:
From: Aaron Zauner <a...@azet.org<mailto:a...@azet.org>>
Date: Wednesday, March 1, 2017 at 8:11 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>, IRTF
CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769).
On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
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.


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,


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.


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.

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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

Hi,

On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
 wrote:
>From: Aaron Zauner 
>Date: Wednesday, March 1, 2017 at 9:24 AM
>To: 'Quynh' 
>Cc: Sean Turner , "" , IRTF
>CFRG 
>Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>(#765/#769).
>
>
>
>>
>>
>>>On 01 Mar 2017, at 13:18, Dang, Quynh (Fed)  wrote:
>>>From: Aaron Zauner 
>>>Date: Wednesday, March 1, 2017 at 8:11 AM
>>>To: 'Quynh' 
>>>Cc: Sean Turner , "" , IRTF
>>>CFRG 
>>>Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>>>(#765/#769).
>On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) 
>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.
>>
>>
>>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,
>
>
>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.
>

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 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 01 Mar 2017, at 13:18, Dang, Quynh (Fed)  wrote:
> 
> 
> 
> From: Aaron Zauner 
> Date: Wednesday, March 1, 2017 at 8:11 AM
> To: 'Quynh' 
> Cc: Sean Turner , "" , IRTF CFRG 
> 
> Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).
> 
>> 
>>> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed)  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.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

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


On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) 
> 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.

Quynh.



Aaron

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed)  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

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.


2) To achieve the margin of 2^-57 as the current text says, the limit number 
should be 2^36 blocks.


Regards,

Quynh.



From: Cfrg  on behalf of Sean Turner 
Sent: Friday, February 10, 2017 12:07 AM
To: 
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

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

[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
___
Cfrg mailing list
c...@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed) <quynh.d...@nist.gov> wrote:
> 
> Hi Kenny,
> 
> I am glad to see that you enjoyed the discussion more than what you planed 
> for the time on your vacation.  We love crypto and the IETF!
> 
> From: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk>
> Date: Wednesday, February 15, 2017 at 8:46 AM
> To: 'Quynh' <quynh.d...@nist.gov>
> Cc: Atul Luykx <atul.lu...@esat.kuleuven.be>, Yoav Nir <ynir.i...@gmail.com>, 
> IRTF CFRG <c...@irtf.org>, "tls@ietf.org" <tls@ietf.org>
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
> (#765/#769)
> 
>> Hi Quynh,
>> 
>> I'm meant to be on vacation, but I'm finding this on-going discussion 
>> fascinating, so I'm chipping in again.
>> 
>> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <quynh.d...@nist.gov> wrote:
>> 
>>> Hi Atul,
>>> 
>>> I hope you had a happy Valentine!
>>> 
>>> From: Atul Luykx <atul.lu...@esat.kuleuven.be>
>>> Date: Tuesday, February 14, 2017 at 4:52 PM
>>> To: Yoav Nir <ynir.i...@gmail.com>
>>> Cc: 'Quynh' <quynh.d...@nist.gov>, IRTF CFRG <c...@irtf.org>, 
>>> "tls@ietf.org" <tls@ietf.org>
>>> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
>>> (#765/#769)
>>> 
>>>>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>>>> Because he wants to lower the security level.
>>> 
>>> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically 
>>> the same: they are practically zero.
>> 
>> I'm not clear what you mean by "practically" here.
> 
> As far as I know, such chance has not happened in history for any targeted 
> search where the chance for hitting the target is 1 in 2^32.
> 
>> They're clearly not the same as real numbers. And if we are being 
>> conservative about security, then the extremes in your list are a long way 
>> apart.
>> 
>>> And, 2^-32 is an absolute chance in this case meaning that all attackers 
>>> can’t improve their chance: no matter how much computational power the 
>>> attacker has.
>> 
>> A sufficiently powerful adversary could carry out an exhaustive key search 
>> for GCM's underlying AES key. So I'm not sure what you're claiming here when 
>> you speak of "absolute chance".
> 
> I described my point not in a best way, sorry. For key recovery, if an 
> attacker can do 2^96 AES operations, his chance of finding the key is 2^-32, 
> but this chance will get improved if the attacker does more computation. On 
> the contrary, the chance for the distinguishing attack won’t change with the 
> proposed data limit.

Maybe I don't comprehend what you're trying to propose - but why change this 
paragraph then?

Coming from an HPC background: It seems to be that with frequent rekeying the 
chance of successfully performing an exhaustive search attack is -- even for 
the most advanced adversary -- so slim that we do not need to worry about that. 
In reality this is a cost-for-computation tradeoff that no one is going to 
invest in if there're more practical ways to attack (e.g. HUMINT/bad OPSEC, 
steal a private key, intrude a given network etc.) given the resources and thus 
money/power needed.

> 
>> 
>>> I don’t understand why the number 2^-60 is your special chosen number for 
>>> this ?
>> 
>> This is a bit subtle, but I'll try to explain in simple terms.
>> 
>> We can conveniently prove a bound of about this size (actually 2^-57) for 
>> INT-CTXT for a wide range of parameters covering both TLS and DTLS (where 
>> many verification failures may be permitted). Then, since we're ultimately 
>> interested in AE security, we would like to (roughly) match this for IND-CPA 
>> security, to get as good a bound as we can for AE security (the security 
>> bounds for the two notions sum to give an AE security bound - see page 2 of 
>> the "AE bounds" note).
>> 
>> In view of the INT-CTXT bound there's no point pushing the IND-CPA bound 
>> much lower than 2^-60 if the ultimate target is AE security. It just hurts 
>> the data limits more without significantly improving AE security.
> 
> I just checked the paper. There is a small error I think. AES-GCM in TLS 1.3 
> is a prf. Under a given key, every input block or just one repeated block 
> 2^35 times, their ciphertext blocks are 2^35 random 128-bit blocks assuming 
> the key has 128 bits of entropy. If there is a collision amon

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

[Aaron Zauner]

> On 15 Feb 2017, at 19:25, Martin Thomson  wrote:
> 
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are connections that
>> last for a long time and transfer large amounts of data. Think datacenter
>> synchronization. At packet-sized records 24 million records amounts to 36
>> GB. That is considerably larger than a 4 GB software update I downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
> 
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
> 
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

I agree with Yoav Nir here, it's certainly not a niche use* and one's 
implementation should not be forced to use a certain cipher mode if there would 
be better options (e.g. because -- as pointed out earlier -- hardware support 
is available).

* We'll all agree that most of the TLS traffic is made up by HTTPS requests, 
still, there are many other uses and we design protocols not just for the web. 
That's W3C.

Aaron



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Kenny,

I am glad to see that you enjoyed the discussion more than what you planed for 
the time on your vacation.  We love crypto and the IETF!

From: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
Date: Wednesday, February 15, 2017 at 8:46 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>, Yoav Nir 
<ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion 
fascinating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>
Cc: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the 
same: they are practically zero.

I'm not clear what you mean by "practically" here.

As far as I know, such chance has not happened in history for any targeted 
search where the chance for hitting the target is 1 in 2^32.

They're clearly not the same as real numbers. And if we are being conservative 
about security, then the extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers can’t 
improve their chance: no matter how much computational power the attacker has.

A sufficiently powerful adversary could carry out an exhaustive key search for 
GCM's underlying AES key. So I'm not sure what you're claiming here when you 
speak of "absolute chance".

I described my point not in a best way, sorry. For key recovery, if an attacker 
can do 2^96 AES operations, his chance of finding the key is 2^-32, but this 
chance will get improved if the attacker does more computation. On the 
contrary, the chance for the distinguishing attack won’t change with the 
proposed data limit.


I don’t understand why the number 2^-60 is your special chosen number for this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for 
INT-CTXT for a wide range of parameters covering both TLS and DTLS (where many 
verification failures may be permitted). Then, since we're ultimately 
interested in AE security, we would like to (roughly) match this for IND-CPA 
security, to get as good a bound as we can for AE security (the security bounds 
for the two notions sum to give an AE security bound - see page 2 of the "AE 
bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound much 
lower than 2^-60 if the ultimate target is AE security. It just hurts the data 
limits more without significantly improving AE security.

I just checked the paper. There is a small error I think. AES-GCM in TLS 1.3 is 
a prf. Under a given key, every input block or just one repeated block 2^35 
times, their ciphertext blocks are 2^35 random 128-bit blocks assuming the key 
has 128 bits of entropy. If there is a collision among the ciphertext blocks, 
it does not mean anything because it does not say anything about the plaintext 
blocks.



Finally, 2^-60 is not *our* special chosen number. We wrote a note that 
contained a table of values, and it's worth noting that we did not make a 
specific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without making 
rekeying a frequent event. It's a continuing surprise to me that you are 
pushing for an option that actually reduces security when achieving higher 
security does not seem to cause any problems for implementors.)

I respectfully disagree. As I explained before, 2^-32, 2^-57 and 2^-60 are all 
safe choices. If someone wants to rekey sooner (or often) for operational 
reason or any other reason, that would be just fine. I just hope that we don’t 
have text which might imply that 2^-32 is not a safe choice.  In our 
guidelines, we basi

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

[Martin Thomson]

On 16 February 2017 at 04:30, Yoav Nir  wrote:
> And now I’ve lost you. A moment ago I thought you were concerned that people 
> would fail to implement KeyUpdate. Are you now suggesting that it be removed 
> entirely from TLS 1.3?


No.  My point was that if GCM requires more updates than you can
handle (because you are running well in excess of 1Tbps perhaps, I
don't know, my crystal ball isn't that good), then use ChaCha where
you don't need to update so often.  Obviously there is a tradeoff
there given the relative availability of hardware support, which you
likely need at those rates, but again the crystal ball is imperfect in
telling us how that story plays out.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 15 Feb 2017, at 19:25, Martin Thomson  wrote:
> 
> On 16 February 2017 at 04:20, Yoav Nir  wrote:
>> No, not really, but TLS is not just the web, and there are connections that
>> last for a long time and transfer large amounts of data. Think datacenter
>> synchronization. At packet-sized records 24 million records amounts to 36
>> GB. That is considerably larger than a 4 GB software update I downloaded
>> over HTTPS a few years ago, but not out of the ballpark.
> 
> I realize that's going to require updates pretty often (once you open
> up the CWND), but I don't think that it is frequent enough to be a
> concern.
> 
> I well know that HTTP gets used at these volumes more often than
> people realize.  I'd rather recommend ChaCha for those niche uses
> though if the rate was sufficiently high.

And now I’ve lost you. A moment ago I thought you were concerned that people 
would fail to implement KeyUpdate. Are you now suggesting that it be removed 
entirely from TLS 1.3?

There’s no getting around the fact that AES-GCM is faster on certain processors 
than ChaCha, and speed is likely to be a major concern for exactly the same 
systems that use the high data volumes.

Yoav




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

On 15 Feb 2017, at 19:05, Martin Thomson  wrote:
> 
> Frankly, I'm more concerned that this isn't small enough and that it
> could it be practical to deploy an implementation that don't support
> KeyUpdate.  That would cause a real interop problem.

Maybe we should resurrect [1] and add 3DES support so as to grease KeyUpdate.

No, not really, but TLS is not just the web, and there are connections that 
last for a long time and transfer large amounts of data. Think datacenter 
synchronization. At packet-sized records 24 million records amounts to 36 GB. 
That is considerably larger than a 4 GB software update I downloaded over HTTPS 
a few years ago, but not out of the ballpark.

Yoav

[1] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 16 February 2017 at 04:20, Yoav Nir  wrote:
> No, not really, but TLS is not just the web, and there are connections that
> last for a long time and transfer large amounts of data. Think datacenter
> synchronization. At packet-sized records 24 million records amounts to 36
> GB. That is considerably larger than a 4 GB software update I downloaded
> over HTTPS a few years ago, but not out of the ballpark.

I realize that's going to require updates pretty often (once you open
up the CWND), but I don't think that it is frequent enough to be a
concern.

I well know that HTTP gets used at these volumes more often than
people realize.  I'd rather recommend ChaCha for those niche uses
though if the rate was sufficiently high.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

Kenny's response here is quite informative and clarifies this somewhat.

2^24.5 (the current text) is still a big number.  Though it might seem
a little small, I see no practical reason to change it.  In the most
perverse case, that means 520MB of one octet records (23MB of actual
data) before an update is forced.  It's hard to get excited about that
as a practical limitation.

Frankly, I'm more concerned that this isn't small enough and that it
could it be practical to deploy an implementation that don't support
KeyUpdate.  That would cause a real interop problem.

On 16 February 2017 at 00:46, Paterson, Kenny <kenny.pater...@rhul.ac.uk> wrote:
> Hi Quynh,
>
> I'm meant to be on vacation, but I'm finding this on-going discussion
> fascinating, so I'm chipping in again.
>
> On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) <quynh.d...@nist.gov> wrote:
>
> Hi Atul,
>
> I hope you had a happy Valentine!
>
> From: Atul Luykx <atul.lu...@esat.kuleuven.be>
> Date: Tuesday, February 14, 2017 at 4:52 PM
> To: Yoav Nir <ynir.i...@gmail.com>
> Cc: 'Quynh' <quynh.d...@nist.gov>, IRTF CFRG <c...@irtf.org>, "tls@ietf.org"
> <tls@ietf.org>
> Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
> (#765/#769)
>
> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
>
> Because he wants to lower the security level.
>
>
> I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically
> the same: they are practically zero.
>
>
> I'm not clear what you mean by "practically" here. They're clearly not the
> same as real numbers. And if we are being conservative about security, then
> the extremes in your list are a long way apart.
>
> And, 2^-32 is an absolute chance in this case meaning that all attackers
> can’t improve their chance: no matter how much computational power the
> attacker has.
>
>
> A sufficiently powerful adversary could carry out an exhaustive key search
> for GCM's underlying AES key. So I'm not sure what you're claiming here when
> you speak of "absolute chance".
>
>
> I don’t understand why the number 2^-60 is your special chosen number for
> this ?
>
>
> This is a bit subtle, but I'll try to explain in simple terms.
>
> We can conveniently prove a bound of about this size (actually 2^-57) for
> INT-CTXT for a wide range of parameters covering both TLS and DTLS (where
> many verification failures may be permitted). Then, since we're ultimately
> interested in AE security, we would like to (roughly) match this for IND-CPA
> security, to get as good a bound as we can for AE security (the security
> bounds for the two notions sum to give an AE security bound - see page 2 of
> the "AE bounds" note).
>
> In view of the INT-CTXT bound there's no point pushing the IND-CPA bound
> much lower than 2^-60 if the ultimate target is AE security. It just hurts
> the data limits more without significantly improving AE security.
>
> Finally, 2^-60 is not *our* special chosen number. We wrote a note that
> contained a table of values, and it's worth noting that we did not make a
> specific recommendation in our note for which row of the table to select.
>
> (Naturally, though, we'd like security to be as high as possible without
> making rekeying a frequent event. It's a continuing surprise to me that you
> are pushing for an option that actually reduces security when achieving
> higher security does not seem to cause any problems for implementors.)
>
> In your “theory”, 2^-112 would be in “higher” security than 2^-60.
>
>
> It certainly would, if it were achievable (which it is not for GCM without
> putting some quite extreme limits on data per key).
>
> Cheers,
>
> Kenny
>
> Quynh.
>
>
> The original text
> recommends switching at 2^{34.5} input blocks, corresponding to a
> success probability of 2^{-60}, whereas his text recommends switching at
> 2^{48} blocks, corresponding to a success probability of 2^{-32}.
>
> Atul
>
> On 2017-02-14 11:45, Yoav Nir wrote:
>
> Hi, Quynh
>
> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) <quynh.d...@nist.gov>
> wrote:
> Hi Sean and all,
> Beside my suggestion at
> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
> I have a second suggestion below.
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
> be
> encrypted on a given connection while keeping a safety margin of
> approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
> (partial or full) input blocks may be encrypted with one ke

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

[Paterson, Kenny]

Hi Quynh,

I'm meant to be on vacation, but I'm finding this on-going discussion 
fascinating, so I'm chipping in again.

On 15 Feb 2017, at 21:12, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>
Cc: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the 
same: they are practically zero.

I'm not clear what you mean by "practically" here. They're clearly not the same 
as real numbers. And if we are being conservative about security, then the 
extremes in your list are a long way apart.

And, 2^-32 is an absolute chance in this case meaning that all attackers can’t 
improve their chance: no matter how much computational power the attacker has.

A sufficiently powerful adversary could carry out an exhaustive key search for 
GCM's underlying AES key. So I'm not sure what you're claiming here when you 
speak of "absolute chance".

I don’t understand why the number 2^-60 is your special chosen number for this ?

This is a bit subtle, but I'll try to explain in simple terms.

We can conveniently prove a bound of about this size (actually 2^-57) for 
INT-CTXT for a wide range of parameters covering both TLS and DTLS (where many 
verification failures may be permitted). Then, since we're ultimately 
interested in AE security, we would like to (roughly) match this for IND-CPA 
security, to get as good a bound as we can for AE security (the security bounds 
for the two notions sum to give an AE security bound - see page 2 of the "AE 
bounds" note).

In view of the INT-CTXT bound there's no point pushing the IND-CPA bound much 
lower than 2^-60 if the ultimate target is AE security. It just hurts the data 
limits more without significantly improving AE security.

Finally, 2^-60 is not *our* special chosen number. We wrote a note that 
contained a table of values, and it's worth noting that we did not make a 
specific recommendation in our note for which row of the table to select.

(Naturally, though, we'd like security to be as high as possible without making 
rekeying a frequent event. It's a continuing surprise to me that you are 
pushing for an option that actually reduces security when achieving higher 
security does not seem to cause any problems for implementors.)

In your “theory”, 2^-112 would be in “higher” security than 2^-60.

It certainly would, if it were achievable (which it is not for GCM without 
putting some quite extreme limits on data per key).

Cheers,

Kenny

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I’m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
--
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Atul,

I hope you had a happy Valentine!

From: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 4:52 PM
To: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>
Cc: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, IRTF CFRG 
<c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level.

I respectfully disagree. 2^-32, 2^-33, 2^-57, 2^-60, 2^-112 are practically the 
same: they are practically zero.  And, 2^-32 is an absolute chance in this case 
meaning that all attackers can’t improve their chance: no matter how much 
computational power the attacker has.

I don’t understand why the number 2^-60 is your special chosen number for this 
? In your “theory”, 2^-112 would be in “higher” security than 2^-60.

Quynh.


The original text
recommends switching at 2^{34.5} input blocks, corresponding to a
success probability of 2^{-60}, whereas his text recommends switching at
2^{48} blocks, corresponding to a success probability of 2^{-32}.

Atul

On 2017-02-14 11:45, Yoav Nir wrote:
Hi, Quynh
On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
wrote:
Hi Sean and all,
Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.
Just replacing this sentence: "
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."
Regards,
Quynh.
I like the suggestion, but I’m probably missing something pretty
basic about it.
2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.
Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Thanks
Yoav
Links:
--
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 14 Feb 2017, at 23:52, Atul Luykx  wrote:
> 
>> Why is that 2^48 input blocks rather than 2^34.5 input blocks?
> Because he wants to lower the security level. The original text recommends 
> switching at 2^{34.5} input blocks, corresponding to a success probability of 
> 2^{-60}, whereas his text recommends switching at 2^{48} blocks, 
> corresponding to a success probability of 2^{-32}.

OK, missed that.

So I’m in favor of switching the phrasing to be about blocks rather than 
maximum-sized records, but not in favor of lowering the security level.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Atul Luykx]

Why is that 2^48 input blocks rather than 2^34.5 input blocks?
Because he wants to lower the security level. The original text 
recommends switching at 2^{34.5} input blocks, corresponding to a 
success probability of 2^{-60}, whereas his text recommends switching at 
2^{48} blocks, corresponding to a success probability of 2^{-32}.


Atul

On 2017-02-14 11:45, Yoav Nir wrote:

Hi, Quynh


On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) 
wrote:

Hi Sean and all,

Beside my suggestion at
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html [1],
I have a second suggestion below.

Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be
encrypted on a given connection while keeping a safety margin of
approximately 2^-57 for Authenticated Encryption (AE) security.
" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48
(partial or full) input blocks may be encrypted with one key. For
other suggestions and analysis, see the referred paper above."

Regards,
Quynh.


I like the suggestion, but I’m probably missing something pretty
basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or
(since an AES block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10
blocks.

Why is that 2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav



Links:
--
[1] https://www.ietf.org/mail-archive/web/tls/current/msg22381.html
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

Hi, Quynh

> On 14 Feb 2017, at 20:45, Dang, Quynh (Fed)  wrote:
> 
> Hi Sean and all,
> 
> Beside my suggestion at 
> https://www.ietf.org/mail-archive/web/tls/current/msg22381.html 
> , I have a 
> second suggestion below.
> 
> Just replacing this sentence: "
> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
>encrypted on a given connection while keeping a safety margin of
>approximately 2^-57 for Authenticated Encryption (AE) security.
> " in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or 
> full) input blocks may be encrypted with one key. For other suggestions and 
> analysis, see the referred paper above."
> 
> Regards,
> Quynh.

I like the suggestion, but I’m probably missing something pretty basic about it.

2^24.5 full-size records is 2^24.5 records of 2^14 bytes each, or (since an AES 
block is 16 bytes or 2^4 bytes) 2^24.5 records of 2^10 blocks.

Why is that 2^48 input blocks rather than 2^34.5 input blocks?

Thanks

Yoav




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Sean and all,


Beside my suggestion at 
https://www.ietf.org/mail-archive/web/tls/current/msg22381.html, I have a 
second suggestion below.


Just replacing this sentence: "

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.

" in Section 5.5 by this sentence: " For AES-GCM, up to 2^48 (partial or full) 
input blocks may be encrypted with one key. For other suggestions and analysis, 
see the referred paper above."


Regards,

Quynh.


From: Dang, Quynh (Fed)
Sent: Tuesday, February 14, 2017 1:20:12 PM
To: Atul Luykx; Dang, Quynh (Fed)
Cc: Markulf Kohlweiss; Antoine Delignat-Lavaud; IRTF CFRG; tls@ietf.org
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hi Atul,

From: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Markulf Kohlweiss <mark...@microsoft.com<mailto:mark...@microsoft.com>>, 
Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, IRTF 
CFRG <c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: just 
one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is 
equivalent to computation in the sense that data are produced by computation. 
2^x blocks = 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). And, 
1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <mark...@microsoft.com<mailto:mark...@microsoft.com>>, 
"Paterson, Kenny"
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner 
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, 
IRTF CFRG
<c...@irtf.org<mailto:c...@irtf.org>>, "<tls@ietf.org<mailto:tls@ietf.org>>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won’t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of 
Markulf Kohlweiss
<mark...@microsoft.com<mailto:mark...@microsoft.com>>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, 
IRTF CFRG
<c...@irtf.org<mailto:c...@irtf.org>>, "<tls@ietf.org<mailto:tls@ietf.org>>" 
<tls@ietf.or

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

[Dang, Quynh (Fed)]

Hi Atul,

From: Atul Luykx 
<atul.lu...@esat.kuleuven.be<mailto:atul.lu...@esat.kuleuven.be>>
Date: Tuesday, February 14, 2017 at 11:17 AM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Cc: Markulf Kohlweiss <mark...@microsoft.com<mailto:mark...@microsoft.com>>, 
Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, IRTF 
CFRG <c...@irtf.org<mailto:c...@irtf.org>>, "tls@ietf.org<mailto:tls@ietf.org>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hey Quynh,

When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext
pairs available to the adversary, it will still take roughly 2^128
operations to recover the key with AES.

Actually the same claim: my claim did not require any data requirement: just 
one ciphertext block.

This contrasts with any mode of
operation, where adversarial success probability increases according to
the amount of data available and the computational complexity required
to perform such an attack is not the limiting factor (which is the core
of the problem we're discussing right now).

IND-CPA is important. That is why I have always been supporting it. Data is 
equivalent to computation in the sense that data are produced by computation. 
2^x blocks = 2^x AES operations.

With 2^48 AES operations/input blocks, the actual margin is below 2^(-33). And, 
1 in 2^32 is 1 in 4,294, 967,296.00 which is safe.

Quynh.


Regardless, correct me if I'm wrong Quynh, but you seem to have two
issues with Eric's text:
1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of
caution instead of recommending that people switch when adversaries have
success probability 2^{-32}. I don't see the discussion progressing on
this point, and basically a decision needs to be made.

I don't think point 2 is a problem because it gives people a good enough
heuristic, however this can be fixed easily by minimally modifying the
original text.

Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:
Hi Markulf and all,
I provided more explanation below.
  From: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <mark...@microsoft.com<mailto:mark...@microsoft.com>>, 
"Paterson, Kenny"
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner 
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, 
IRTF CFRG
<c...@irtf.org<mailto:c...@irtf.org>>, "<tls@ietf.org<mailto:tls@ietf.org>>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Hi Markulf,
The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won’t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.
Regards,
Quynh.
From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of 
Markulf Kohlweiss
<mark...@microsoft.com<mailto:mark...@microsoft.com>>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, 
IRTF CFRG
<c...@irtf.org<mailto:c...@irtf.org>>, "<tls@ietf.org<mailto:tls@ietf.org>>" 
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)
Hello,
Our analysis of miTLS also supports option a)
A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.
When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).
The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.
Also, many users don’t know what “confidentiality bound” me

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

[Atul Luykx]

Hey Quynh,


When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.
The claim is stronger: regardless of the number of plaintext-ciphertext 
pairs available to the adversary, it will still take roughly 2^128 
operations to recover the key with AES. This contrasts with any mode of 
operation, where adversarial success probability increases according to 
the amount of data available and the computational complexity required 
to perform such an attack is not the limiting factor (which is the core 
of the problem we're discussing right now).


Regardless, correct me if I'm wrong Quynh, but you seem to have two 
issues with Eric's text:

1. the data limit recommendation is too strict, and
2. it only gives a data limit in terms of full records.

For point 1 it seems like most people would rather err on the side of 
caution instead of recommending that people switch when adversaries have 
success probability 2^{-32}. I don't see the discussion progressing on 
this point, and basically a decision needs to be made.


I don't think point 2 is a problem because it gives people a good enough 
heuristic, however this can be fixed easily by minimally modifying the 
original text.


Atul


On 2017-02-14 03:59, Dang, Quynh (Fed) wrote:

Hi Markulf and all,

I provided more explanation below.

 From: 'Quynh' <quynh.d...@nist.gov>
Date: Monday, February 13, 2017 at 10:45 AM
To: Markulf Kohlweiss <mark...@microsoft.com>, "Paterson, Kenny"
<kenny.pater...@rhul.ac.uk>, Sean Turner <s...@sn3rd.com>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com>, IRTF CFRG
<c...@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)


Hi Markulf,

The probability of a bad thing to happen is actually below (or
about) 2^(-33). It practically won’t happen when the chance is 1
in 2^32. And, to achieve that chance, you must collect 2^48 128-bit
blocks.

Regards,
Quynh.

From: TLS <tls-boun...@ietf.org> on behalf of Markulf Kohlweiss
<mark...@microsoft.com>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk>, Sean Turner
<s...@sn3rd.com>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com>, IRTF CFRG
<c...@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage"
PRs (#765/#769)


Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security
point of view, especially for a confidentiality bound.


When someone says AES-128 has 128 bits of security he or she means
that 2^128 AES operations will break the cipher with probability 100%:
finding the key and the plaintext.  It does not mean that attackers
have only 2^(-128) chance of success. If an attacker could run 2^100
AES operations, his or her chance of success is way below 2^(-32):
this does not mean that AES has a security level of 2^(-32) or
2^(-28).

The success probability 1/2^32 means that after 2^48 AES operations,
the attacker has a success probability of 2^-32 which is practically
zero.

Also, many users don’t know what “confidentiality bound” means.

The current text Eric wrote talks about a number 2^24.5 of full-size
records. In many situations, the record sizes are not full size, but
different sizes. My latest suggestion text does not assume full size
records, it covers variable record sizes, it just counts AES-input
blocks or AES operations.

Regards,
Quynh.


We verified an implementation of the TLS 1.3 record
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy
2017) where we arrive at a combined bound for authenticity and
confidentiality that is compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should
be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"

wrote:

On 10 February 2017 at 16:07, Sean Turner  wrote:

a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]

a) I'm happy enough with the current text (I've implemented that any

it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make
sense.
It's not obviously wrong any more, but the way it is written it is
very conf

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

[Tony Arcieri]

On Mon, Feb 13, 2017 at 3:21 PM, Aaron Zauner  wrote:

> I thought the cited paper sorted this out like a year ago.
>
> In favor of option a


I am also in favor of option A.

The wording in option B is simultaneously much more unclear and much more
verbose. I consider it a regression.

Option C is more similar to option A, but not an improvement, IMO.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 10 Feb 2017, at 07:07, Sean Turner  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]

I thought the cited paper sorted this out like a year ago.

In favor of option a

Aaron


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Markulf,

The probability of a bad thing to happen is actually below (or about) 2^(-33). 
It practically won’t happen when the chance is 1 in 2^32. And, to achieve that 
chance, you must collect 2^48 128-bit blocks.

Regards,
Quynh.

From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of 
Markulf Kohlweiss <mark...@microsoft.com<mailto:mark...@microsoft.com>>
Date: Monday, February 13, 2017 at 10:34 AM
To: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>, Sean Turner 
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: Antoine Delignat-Lavaud <an...@microsoft.com<mailto:an...@microsoft.com>>, 
IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of view, 
especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record 
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy 2017) where 
we arrive at a combined bound for authenticity and confidentiality that is 
compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 wrote:

On 10 February 2017 at 16:07, Sean Turner  wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

___
Cfrg mailing list
Cfrg at irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Markulf Kohlweiss]

Hello,

Our analysis of miTLS also supports option a)

A security level of 2^-32 seems too low from a provable security point of view, 
especially for a confidentiality bound.

We verified an implementation of the TLS 1.3 record 
(https://eprint.iacr.org/2016/1178, to appear at Security & Privacy 2017) where 
we arrive at a combined bound for authenticity and confidentiality that is 
compatible with the Iwata et al. bound.

Regards,
Markulf (for the miTLS team)

>Hi,
>
>My preference is to go with the existing text, option a).
>
>From the github discussion, I think option c) involves a less conservative
>security bound (success probability for IND-CPA attacker bounded by
>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>aware of the weaker security guarantees it provides.
>
>I do not understand option b). It seems to rely on an analysis of
>collisions of ciphertext blocks rather than the established security proof
>for AES-GCM.
>
>Regards,
>
>Kenny
>
>On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
> wrote:
>
>>On 10 February 2017 at 16:07, Sean Turner  wrote:
>>> a) Close these two PRs and go with the existing text [0]
>>> b) Adopt PR#765 [1]
>>> c) Adopt PR#769 [2]
>>
>>
>>a) I'm happy enough with the current text (I've implemented that any
>>it's relatively easy).
>>
>>I could live with c, but I'm opposed to b. It just doesn't make sense.
>>It's not obviously wrong any more, but the way it is written it is
>>very confusing and easily open to misinterpretation.
>>
>>___
>>Cfrg mailing list
>>Cfrg at irtf.org
>>https://www.irtf.org/mailman/listinfo/cfrg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Kenny,


AES-permutation is a permutation.  But, AES-GCM (AES in counter mode) is a PRF 
as long as the 128-bit IVs are unique under the encryption key.  The amount of 
plaintext is the same with the amount of ciphertext.


I originally talked about plaintext in my discussion, but several people asked 
me to talk about ciphertext instead (I thought maybe measuring ciphertext was 
easier than measuring plaintext in practice and that was why they asked me 
that).


The number of 128-bit blocks of plaintext is the same with the number of 
128-bit "one-time pad" keys produced by the AES key and the unique 128-bit IVs. 
These 128-bit "one-time pad" keys and the corresponding 128-bit ciphertext 
blocks are the same in the sense that they are both sets of pseudo-random 
128-bit blocks.  But, the 128-bit "one-time pad" keys are not stored, they have 
to either measure the amount of plaintext or ciphertext.


Regards,

Quynh.




From: Paterson, Kenny <kenny.pater...@rhul.ac.uk>
Sent: Friday, February 10, 2017 2:06:46 PM
To: Dang, Quynh (Fed); Sean Turner
Cc: IRTF CFRG; <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hi,

On 10/02/2017 18:56, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:

>Dear Kenny,
>
>From: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk>
>Date: Friday, February 10, 2017 at 12:22 PM
>To: 'Quynh' <quynh.d...@nist.gov>, Sean Turner <s...@sn3rd.com>
>Cc: IRTF CFRG <c...@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>(#765/#769)
>
>
>
>>Dear Quynh,
>>
>>
>>On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:
>>
>>
>>>Hi Kenny,
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>
>>>>My preference is to go with the existing text, option a).
>>>>
>>>>
>>>>
>>>>
>>>>From the github discussion, I think option c) involves a less
>>>>conservative
>>>>security bound (success probability for IND-CPA attacker bounded by
>>>>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>>>>aware of the weaker security guarantees it provides.
>>>>
>>>>
>>>>
>>>>
>>>>I do not understand option b). It seems to rely on an analysis of
>>>>collisions of ciphertext blocks rather than the established security
>>>>proof
>>>>for AES-GCM.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
>>>being a counter-mode encryption and each counter is a 96-bit nonce ||
>>>32-bit counter. I don’t know if there is another kind of proof that is
>>>more precise than that.
>>
>>
>>Thanks for explaining. I think, then, that what you are doing is (in
>>effect) accounting for the PRP/PRF switching lemma that is used (in a
>>standard way) as part of the IND-CPA security proof of AES-GCM. One can
>>obtain a greater degree of precision by using the proven bounds for
>>IND-CPA security of AES-GCM. These incorporate the "security loss" coming
>>from the PRP/PRF switching lemma. The current best form of these bounds
>>is
>>due to Iwata et al.. This is precisely what we analyse in the note at
>>http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
Limits on Authenticated Encryption Use in TLS - 
isg.rhul.ac.uk<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>
www.isg.rhul.ac.uk
Limits on Authenticated Encryption Use in TLS Atul Luykx and Kenneth G. 
Paterson March 8, 2016 Abstract 
Thistechnicalnotepresentslimitsonthesecurity(asafunctionofthe



>>equations (5) - (7) on page 6 of that note.
>>
>
>I reviewed the paper more than once. I highly value the work. I suggested
>to reference  your paper in the text.  I think the result in your paper
>is the same with what is being suggested when the collision probability
>allowed is 2^(-32).

Thanks for this feedback. I guess my confusion arises from wondering what
you mean by collision probability and why you care about it. There are no
collisions in the block cipher's outputs per se, because AES is a
permutation for each choice of key. And collisions in the ciphertext
blocks output by AES-GCM are irrelevant to its formal security analysis.

On the other hand, when in the proof of IND-CPA security of AES-GCM one
switches from a random permutation (which is how we model AES) to a random
function (which is what we need to argue in the end that the plaintext is
masked by a one-time pad, giving indistinguishability), then one needs to
deal with the probability that collisions occur in the function's outputs
but not in the permutation's. This ends up being the main contribution to
the security bound in the proof for IND-CPA security.

Is that what you are getting at?

If so, then we are on the same page, and what remains is to decide whether
a 2^{-32} bound is a good enough security margin.

Regards,

Kenny


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Rene,


I care about side channel attacks in general as much as you do. But my question 
was that how you carry out those attacks on GCM in TLS 1.3's servers and 
clients ? Do those side-channel attacks apply only to GCM in TLS 1.3 ?


Quynh.


From: Rene Struik <rstruik@gmail.com>
Sent: Friday, February 10, 2017 2:02:14 PM
To: Dang, Quynh (Fed); Sean Turner; <tls@ietf.org>
Cc: IRTF CFRG
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hi Quynh:

Not sure where to start (there is vast literature on side channel attacks and 
other implementation attacks). A good starting point would be the book [1], but 
one could also look at some NIST publications [2].

Side channel attacks differs from cryptanalytic attacks in that it does not 
merely study I/O behavior of crypto contructs, but also looks into what 
information can be obtained from what is going on "under the hood" of the 
computations (power consumption, radiation, timing, etc; or even invasive 
attacks). Most commonly one looks at crypto building blocks, but ultimately 
side channels can comprise any system behavior ("Lucky13" does, e.g., exploit 
this, if I remember correctly).

>From the last page of [2]: Finally, the most important conclusion from this 
>paper is that it is not only a necessity but also a must, in the coming 
>version of FIPS 140-3 standard, to evaluate cryptographic modules for their 
>resistivity against SCA attacks.

Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis Attacks - 
Revealing the Secrets of Smart Cards", Springer, 2007.
[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene,

From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Rene 
Struik <rstruik@gmail.com<mailto:rstruik@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]


There are cryptographic limits on the amount of plaintext which can be safely 
encrypted under a given set of keys. 
[AEAD-LIMITS]<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS> provides an 
analysis of these limits under the assumption that the underlying primitive 
(AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update 
Section 4.6.3<https://tlswg.github.io/tls13-spec/#key-update> prior to reaching 
these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted 
on a given connection while keeping a safety margin of approximately 2^-57 for 
Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record 
sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, 
which - in some implementations - have been shown to be successful at 
recovering keying material with a relatively small number of messages encrypted 
using the same key. While results are highly implementation-specific, thereby 
making it hard to provide precise guidance, prudence suggests that 
implementations should not reuse keys ad infinitum. Implementations SHALL 
therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure 
people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work 
for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner 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

[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
___
Cfrg mailing 

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

[Paterson, Kenny]

Hi,

On 10/02/2017 18:56, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:

>Dear Kenny, 
>
>From: "Paterson, Kenny" <kenny.pater...@rhul.ac.uk>
>Date: Friday, February 10, 2017 at 12:22 PM
>To: 'Quynh' <quynh.d...@nist.gov>, Sean Turner <s...@sn3rd.com>
>Cc: IRTF CFRG <c...@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
>Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>(#765/#769)
>
>
>
>>Dear Quynh,
>>
>>
>>On 10/02/2017 12:48, "Dang, Quynh (Fed)" <quynh.d...@nist.gov> wrote:
>>
>>
>>>Hi Kenny, 
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>
>>>>My preference is to go with the existing text, option a).
>>>>
>>>>
>>>>
>>>>
>>>>From the github discussion, I think option c) involves a less
>>>>conservative
>>>>security bound (success probability for IND-CPA attacker bounded by
>>>>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>>>>aware of the weaker security guarantees it provides.
>>>>
>>>>
>>>>
>>>>
>>>>I do not understand option b). It seems to rely on an analysis of
>>>>collisions of ciphertext blocks rather than the established security
>>>>proof
>>>>for AES-GCM.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
>>>being a counter-mode encryption and each counter is a 96-bit nonce ||
>>>32-bit counter. I don’t know if there is another kind of proof that is
>>>more precise than that.
>>
>>
>>Thanks for explaining. I think, then, that what you are doing is (in
>>effect) accounting for the PRP/PRF switching lemma that is used (in a
>>standard way) as part of the IND-CPA security proof of AES-GCM. One can
>>obtain a greater degree of precision by using the proven bounds for
>>IND-CPA security of AES-GCM. These incorporate the "security loss" coming
>>from the PRP/PRF switching lemma. The current best form of these bounds
>>is
>>due to Iwata et al.. This is precisely what we analyse in the note at
>>http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
>>equations (5) - (7) on page 6 of that note.
>>
>
>I reviewed the paper more than once. I highly value the work. I suggested
>to reference  your paper in the text.  I think the result in your paper
>is the same with what is being suggested when the collision probability
>allowed is 2^(-32).

Thanks for this feedback. I guess my confusion arises from wondering what
you mean by collision probability and why you care about it. There are no
collisions in the block cipher's outputs per se, because AES is a
permutation for each choice of key. And collisions in the ciphertext
blocks output by AES-GCM are irrelevant to its formal security analysis.

On the other hand, when in the proof of IND-CPA security of AES-GCM one
switches from a random permutation (which is how we model AES) to a random
function (which is what we need to argue in the end that the plaintext is
masked by a one-time pad, giving indistinguishability), then one needs to
deal with the probability that collisions occur in the function's outputs
but not in the permutation's. This ends up being the main contribution to
the security bound in the proof for IND-CPA security.

Is that what you are getting at?

If so, then we are on the same page, and what remains is to decide whether
a 2^{-32} bound is a good enough security margin.

Regards,

Kenny


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Rene Struik]

Hi Quynh:

Not sure where to start (there is vast literature on side channel 
attacks and other implementation attacks). A good starting point would 
be the book [1], but one could also look at some NIST publications [2].


Side channel attacks differs from cryptanalytic attacks in that it does 
not merely study I/O behavior of crypto contructs, but also looks into 
what information can be obtained from what is going on "under the hood" 
of the computations (power consumption, radiation, timing, etc; or even 
invasive attacks). Most commonly one looks at crypto building blocks, 
but ultimately side channels can comprise any system behavior ("Lucky13" 
does, e.g., exploit this, if I remember correctly).


From the last page of [2]: Finally, the most important conclusion from 
this paper is that it is not only a necessity but also a must, in the 
coming version of FIPS 140-3 standard, to evaluate cryptographic modules 
for their resistivity against SCA attacks.


Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis 
Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2] 
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf

[2]


On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:

Hi Rene,

From: TLS <tls-boun...@ietf.org <mailto:tls-boun...@ietf.org>> on 
behalf of Rene Struik <rstruik@gmail.com 
<mailto:rstruik@gmail.com>>

Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <s...@sn3rd.com <mailto:s...@sn3rd.com>>, 
"<tls@ietf.org <mailto:tls@ietf.org>>" <tls@ietf.org 
<mailto:tls@ietf.org>>

Cc: IRTF CFRG <c...@irtf.org <mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)


Dear colleagues:

I would suggest adding the following paragraph at the end of
Section 5.5:

[current text of Section 5.5]

There are cryptographic limits on the amount of plaintext which
can be safely encrypted under a given set of keys.[AEAD-LIMITS]
<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS>provides an
analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses. Implementations
SHOULD do a key updateSection 4.6.3
<https://tlswg.github.io/tls13-spec/#key-update>prior to reaching
these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be encrypted on a given connection while keeping a safety margin
of approximately 2^-57 for Authenticated Encryption (AE) security.
For ChaCha20/Poly1305, the record sequence number would wrap
before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side
channel attacks, which - in some implementations - have been shown
to be successful at recovering keying material with a relatively
small number of messages encrypted using the same key. While
results are highly implementation-specific, thereby making it hard
to provide precise guidance, prudence suggests that
implementations should not reuse keys ad infinitum.
Implementations SHALL therefore always implement the key update
mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just
to make sure people do not "forget" to implement key updates?}


How do you do side channel attacks on TLS ? Do these side-channel 
attacks work for AES-GCM only in TLS 1.3 ?





See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner 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

[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
___
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg



-- 
email:rstruik@gmail.com  | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363




--
email: rstruik@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Dear Kenny,


From: "Paterson, Kenny" 
<kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
Date: Friday, February 10, 2017 at 12:22 PM
To: 'Quynh' <quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>>, Sean Turner 
<s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)" 
<quynh.d...@nist.gov<mailto:quynh.d...@nist.gov>> wrote:

Hi Kenny,

Hi,


My preference is to go with the existing text, option a).


>From the github discussion, I think option c) involves a less
conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.


I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security
proof
for AES-GCM.




My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
being a counter-mode encryption and each counter is a 96-bit nonce ||
32-bit counter. I don’t know if there is another kind of proof that is
more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a
standard way) as part of the IND-CPA security proof of AES-GCM. One can
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss" coming
from the PRP/PRF switching lemma. The current best form of these bounds is
due to Iwata et al.. This is precisely what we analyse in the note at
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
equations (5) - (7) on page 6 of that note.

I reviewed the paper more than once. I highly value the work. I suggested to 
reference  your paper in the text.  I think the result in your paper is the 
same with what is being suggested when the collision probability allowed is 
2^(-32).

Regards,
Quynh.


Regards,

Kenny



Regards,
Quynh.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Rene,

From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Rene 
Struik <rstruik@gmail.com<mailto:rstruik@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Dear colleagues:

I would suggest adding the following paragraph at the end of Section 5.5:

[current text of Section 5.5]


There are cryptographic limits on the amount of plaintext which can be safely 
encrypted under a given set of keys. 
[AEAD-LIMITS]<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS> provides an 
analysis of these limits under the assumption that the underlying primitive 
(AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update 
Section 4.6.3<https://tlswg.github.io/tls13-spec/#key-update> prior to reaching 
these limits.

For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted 
on a given connection while keeping a safety margin of approximately 2^-57 for 
Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record 
sequence number would wrap before the safety limit is reached.

[suggested additional text]

The above upper limits do not take into account potential side channel attacks, 
which - in some implementations - have been shown to be successful at 
recovering keying material with a relatively small number of messages encrypted 
using the same key. While results are highly implementation-specific, thereby 
making it hard to provide precise guidance, prudence suggests that 
implementations should not reuse keys ad infinitum. Implementations SHALL 
therefore always implement the key update mechanism of Section 4.6.3.

{editorial note: perhaps, one should impose the limit 2^20, just to make sure 
people do not "forget" to implement key updates?}

How do you do side channel attacks on TLS ? Do these side-channel attacks work 
for AES-GCM only in TLS 1.3 ?




See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno

On 2/10/2017 12:07 AM, Sean Turner 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

[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
___
Cfrg mailing list
c...@irtf.org<mailto:c...@irtf.org>https://www.irtf.org/mailman/listinfo/cfrg



--
email: rstruik@gmail.com<mailto:rstruik@gmail.com> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

Dear Quynh,

On 10/02/2017 12:48, "Dang, Quynh (Fed)"  wrote:

>Hi Kenny, 
>
>>Hi,
>>
>>
>>My preference is to go with the existing text, option a).
>>
>>
>>From the github discussion, I think option c) involves a less
>>conservative
>>security bound (success probability for IND-CPA attacker bounded by
>>2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
>>aware of the weaker security guarantees it provides.
>>
>>
>>I do not understand option b). It seems to rely on an analysis of
>>collisions of ciphertext blocks rather than the established security
>>proof
>>for AES-GCM.
>>
>>
>
>
>My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as
>being a counter-mode encryption and each counter is a 96-bit nonce ||
>32-bit counter. I don’t know if there is another kind of proof that is
>more precise than that.

Thanks for explaining. I think, then, that what you are doing is (in
effect) accounting for the PRP/PRF switching lemma that is used (in a
standard way) as part of the IND-CPA security proof of AES-GCM. One can
obtain a greater degree of precision by using the proven bounds for
IND-CPA security of AES-GCM. These incorporate the "security loss" coming
from the PRP/PRF switching lemma. The current best form of these bounds is
due to Iwata et al.. This is precisely what we analyse in the note at
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf - specifically, see
equations (5) - (7) on page 6 of that note.

Regards,

Kenny 

>
>
>Regards,
>Quynh. 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Kenny,

From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of 
"Paterson, Kenny" <kenny.pater...@rhul.ac.uk<mailto:kenny.pater...@rhul.ac.uk>>
Date: Friday, February 10, 2017 at 4:06 AM
To: Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>>
Cc: IRTF CFRG <c...@irtf.org<mailto:c...@irtf.org>>, 
"<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs 
(#765/#769)

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

My suggestion was based on counting.  I analyzed AES-GCM in TLS 1.3  as being a 
counter-mode encryption and each counter is a 96-bit nonce || 32-bit counter. I 
don’t know if there is another kind of proof that is more precise than that.

Regards,
Quynh.



Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
<cfrg-boun...@irtf.org<mailto:cfrg-boun...@irtf.org> on behalf of 
martin.thom...@gmail.com<mailto:martin.thom...@gmail.com>> wrote:

On 10 February 2017 at 16:07, Sean Turner 
<s...@sn3rd.com<mailto:s...@sn3rd.com>> wrote:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

___
Cfrg mailing list
c...@irtf.org<mailto:c...@irtf.org>
https://www.irtf.org/mailman/listinfo/cfrg

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dang, Quynh (Fed)]

Hi Sean and all,


I agree with everyone that the text in (b) was not very good text.


The problem with (c) is that it is not precise at places and it leaves out a 
lot of informative discussions which users should know.


The sentence "The maximum amount of plaintext data that can be safely encrypted 
with  AES-GCM in a session is 2^48 128-bit blocks (2^52 bytes), assuming  
probability of success at 1/2^32" is not clear.  What is the success here? And, 
with 2^48 (full or partial) blocks, the collision probability is below (not at) 
2^(-32).


And, "safely encrypted", what does this mean? I would like not having a 
collision among 128-bit blocks of ciphertexts, but I dont see any damage to the 
data owner who sends the encrypted data over a TLS session.


I copied the text that I later proposed under the discussion of PR#769 below.


" To use AES-GCM to provide authenticity of authenticated data, confidentiality 
of plaintext content, and information leakage [0] protection for the plaintext 
safely, the limit of total ciphertext under a single key is ( 
(TLSCipherText.length / 16) / ceiling (TLSCipherText.length / 16) ) times 2^48 
128-bit blocks.


When the data limit is reached, the chance of having a collision among 128-bit 
blocks of the ciphertext is below 2^(-32) which is negligible.

Since the block size of AES is 128 bits, there will be collisions among 
different sets of ciphertext from multiple sessions using GCM (or any other 
modes of AES) when the total amount of the ciphertext of all considered 
sessions is more than 2^64 128-bit blocks. This fact does not seem to create a 
practical security weakness of using AES GCM.

For ChaCha20/Poly1305, the record sequence number would wrap before the safety 
limit is reached. See [AEAD-LIMITS] for further analysis.

[0]: Information leakage in the context of TLS is a chosen-plaintext 
distinguishing attack where the attacker provides 2 128-bit plaintext blocks to 
a GCM encryption engine, after seeing one encrypted block for one of the 2 
plaintext blocks, the attacker knows which plaintext block was encrypted. Or, 
it means that there is a collision among 128-bit blocks of the ciphertext. "

  1.  The text above uses blocks instead of bytes or records of ciphertext.
  2.  The partial block situation is taken into account.

"


Or, using good text from PR769 provided by brainhub, the first paragraph could 
be replaced by the following.


"To use AES-GCM to provide authenticity of authenticated data, confidentiality 
of plaintext content, and information leakage [0] protection for the plaintext, 
the limit of total ciphertext under a single key is 2^48 128-bit blocks with 
the ciphertext size being rounded up to the next 16-byte boundary. "


Regards,

Quynh.




From: Cfrg  on behalf of Sean Turner 
Sent: Friday, February 10, 2017 12:07:35 AM
To: 
Cc: IRTF CFRG
Subject: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

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

[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
___
Cfrg mailing list
c...@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Fri, Feb 10, 2017 at 04:44:58PM +1100, Martin Thomson wrote:
> On 10 February 2017 at 16:07, Sean Turner  wrote:
> > a) Close these two PRs and go with the existing text [0]
> > b) Adopt PR#765 [1]
> > c) Adopt PR#769 [2]
> 
> 
> a) I'm happy enough with the current text (I've implemented that any
> it's relatively easy).
> 
> I could live with c, but I'm opposed to b. It just doesn't make sense.
> It's not obviously wrong any more, but the way it is written it is
> very confusing and easily open to misinterpretation.

I couldn't make out what b) says, c) is much clearer.

However, even in a), let alone b) or c), the limits are so high that
one should do some greasing, or this feature seems like a prime
candidate for rusting shut.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Paterson, Kenny]

Hi,

My preference is to go with the existing text, option a).

>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker security guarantees it provides.

I do not understand option b). It seems to rely on an analysis of
collisions of ciphertext blocks rather than the established security proof
for AES-GCM.

Regards,

Kenny

On 10/02/2017 05:44, "Cfrg on behalf of Martin Thomson"
 wrote:

>On 10 February 2017 at 16:07, Sean Turner  wrote:
>> a) Close these two PRs and go with the existing text [0]
>> b) Adopt PR#765 [1]
>> c) Adopt PR#769 [2]
>
>
>a) I'm happy enough with the current text (I've implemented that any
>it's relatively easy).
>
>I could live with c, but I'm opposed to b. It just doesn't make sense.
>It's not obviously wrong any more, but the way it is written it is
>very confusing and easily open to misinterpretation.
>
>___
>Cfrg mailing list
>c...@irtf.org
>https://www.irtf.org/mailman/listinfo/cfrg

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 10 February 2017 at 16:07, Sean Turner  wrote:
> a) Close these two PRs and go with the existing text [0]
> b) Adopt PR#765 [1]
> c) Adopt PR#769 [2]


a) I'm happy enough with the current text (I've implemented that any
it's relatively easy).

I could live with c, but I'm opposed to b. It just doesn't make sense.
It's not obviously wrong any more, but the way it is written it is
very confusing and easily open to misinterpretation.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stanislav V. Smyshlyaev]

Dear Sean, dear all,

I find the existing limits quite reasonable and would prefer that we'll
stay conservative here, so I'd prefer option a) go with the existing text.


Best regards,
Stanislav Smyshlyaev


2017-02-10 8:07 GMT+03:00 Sean Turner :

> 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
>
> [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
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls