Re: [TLS] Data limit for GCM under a given key.

[Tony Arcieri]

On Friday, November 6, 2015, Watson Ladd  wrote:

> On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh  > wrote:
> > I did not talk  under indistinguishability framework. My discussion was
> about confidentiality protection and authentication.
>
> What is the definition of "confidentiality protection" being used here?
>

I too am confused by Quynh's statement. Indistinguishability is the modern
bar for confidentiality and authentication.

Quynh, are you talking about anything less than IND-CCA2? If you are, that
is less than the modern bar I would personally consider acceptable.


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

Re: [TLS] Data limit for GCM under a given key.

[Dave Garrett]

On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> Update: we discussed this extensively in Yokohama and based on Watson's
> feedback and offline comments from David McGrew, the consensus was that we
> needed to add some sort of rekeying mechanism to support long-lived flows.
> Expect a PR on this next week.
> 
> Note: We'll still need guidance to implementations on when to re-key, but
> we don't expect to have a hard protocol limit.

If re-keying is back up for discussion, let me restate my request for it to be 
routine, rather than only an niche-case feature. Any re-key schedule should be 
considered valid, but the spec should set a "SHOULD"-level requirement that the 
minimum be once every N hours or M terabytes, whichever comes first (where N & 
M are some bike-shedable numbers with some expectation of randomization in 
values for each period).


Dave

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

Re: [TLS] Data limit for GCM under a given key.

[Eric Rescorla]

Update: we discussed this extensively in Yokohama and based on Watson's
feedback and offline comments from David McGrew, the consensus was that we
needed to add some sort of rekeying mechanism to support long-lived flows.
Expect a PR on this next week.

Note: We'll still need guidance to implementations on when to re-key, but
we don't expect to have a hard protocol limit.

-Ekr



On Fri, Nov 6, 2015 at 4:59 PM, Tony Arcieri  wrote:

> On Friday, November 6, 2015, Watson Ladd  wrote:
>
>> On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh  wrote:
>> > I did not talk  under indistinguishability framework. My discussion was
>> about confidentiality protection and authentication.
>>
>> What is the definition of "confidentiality protection" being used here?
>>
>
> I too am confused by Quynh's statement. Indistinguishability is the modern
> bar for confidentiality and authentication.
>
> Quynh, are you talking about anything less than IND-CCA2? If you are, that
> is less than the modern bar I would personally consider acceptable.
>
>
> --
> Tony Arcieri
>
>
> ___
> 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] Data limit for GCM under a given key.

[Watson Ladd]

On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh  wrote:
> I did not talk  under indistinguishability framework. My discussion was about 
> confidentiality protection and authentication.

What is the definition of "confidentiality protection" being used here?
>
> Quynh.
> 
> From: Watson Ladd 
> Sent: Wednesday, November 4, 2015 3:17:00 PM
> To: Dang, Quynh
> Cc: Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] Data limit for GCM under a given key.
>
> On Wed, Nov 4, 2015 at 2:29 PM, Dang, Quynh  wrote:
>> Hi Eric and all,
>>
>>
>> The limit of 2^48 packets under a given key for GCM you mentioned today is
>> the limit for SRTP
>> (https://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-17#section-6).
>> The nonce space of the IV construction is only 48 bits and that is why it
>> has the limit of 2^48. The limit here should be 2^48 blocks, not records as
>> stated in the document.
>>
>>
>> As I explained before, GCM is counter mode for encryption. For a given key,
>> the nonce never repeats globally, then confidentiality of the encrypted data
>> is preserved. When the nonce space is 2^n values, then 2^n message blocks
>> can have secure confidentiality protection.
>
> This is completely untrue. If you actually understood the definitions,
> and thought about the matter for 15 minutes, you would realize that
> permutations are distinguishable from functions after 2^(n/2) queries
> with high probabilities, and this breaks IND-$. This is an elementary
> result found on page 134 of Boneh-Shoup.
>
>>
>>
>> Regarding to authentication, as I explained before, if the tag size is n,
>> then you have collision issue among the tags when the number of tags goes
>> around 2^(n/2) which is not a good thing, but strictly speaking, this does
>> not break your authentication.
>
> Carter-Wegman security results are weaker than for PRF-based MACs.
>>
>>
>> However, rekeying often is a good thing which could help prevent disaster to
>> keep go on if there is something wrong with the IV or the key.
>>
>>
>> Quynh.
>>
>>
>>
>>
>> 
>> From: Dang, Quynh
>> Sent: Monday, November 2, 2015 3:00 PM
>> To: Watson Ladd
>> Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla
>> Subject: Re: [Cfrg] Collision issue in ciphertexts.
>>
>>
>> Now, you talked about a MAC function (with AES). I previously talked about
>> encryption.
>>
>>
>> If I , the only person, uses the MAC key, when I generate more than 2^64 MAC
>> values (Let's say each MAC value is 96 bits), I have many collided MAC
>> pairs. But, I am the only one (beside the person(s) verifying my MACs) who
>> knows the MAC key in order to generate those  verified MAC values.
>>
>>
>> If the MAC length is k bits, an attacker is allowed to send 2^n failed
>> verifications, his or her chance of success is approximately 2^n / 2^k.
>> Let's imagine n is 64 and k is 96, the success chance is 1/2^36 which is
>> practically ZERO!
>>
>>
>> If I am an attacker, I would choose a message that I want to be verified,
>> and I keep changing the MAC key to generate different MAC values with
>> different keys and hope one of them will get verified.  Let's assume the MAC
>> key to be 96 bits ( 96 bits of random bits, the other 32 bits are known). In
>> theory, when I get close to 2^96 attempts, I would expect some chance of
>> success. To deal with this attacker, one would change the MAC key when the
>> number of failed attempts gets close to a number that you don't want. For
>> example, if you don't want a success chance of an attack to be above 1 /
>> 2^36, then you need to change your MAC key when the number of failed
>> verifications reaches 2^64 when your MAC length is 96 bits.
>>
>>
>> After you change the MAC key, I ( the attacker) will have to start
>> everything again because all of the failed MACs I generated before are
>> useless now.
>>
>>
>> 
>> From: Watson Ladd 
>> Sent: Monday, November 2, 2015 5:07 AM
>> To: Dang, Quynh
>> Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla
>> Subject: Re: [Cfrg] Collision issue in ciphertexts.
>>
>>
>>
>> On Nov 2, 2015 2:14 AM, "Dang, Quynh"  wrote:
>>>
>>> Hi Eric,
>>>
>>>
>>> As you asked the question about how many ciphertext blocks should be safe
>>> under a single key, I think it is safe to have 2^96 blocks under a given key
>>> if the IV (counter) is 96 bits.
>>
>> This is wrong for PRP, right for PRF. It's not that hard to find the right
>> result.
>>
>>>
>>>
>>> When there is a collision between two ciphertext blocks when two different
>>> counter values are used , the chance of the same plaintext was used twice is
>>> 1^128.  Collisions start to happen a lot when the number of ciphertext
>>> blocks are above 2^64. However, each collision just reveals that the
>>> corresponding plaintext blocks are probably different ones.
>>
>> Which breaks 

Re: [TLS] Data limit for GCM under a given key.

[Eric Rescorla]

On Fri, Nov 6, 2015 at 7:50 PM, Eric Rescorla  wrote:

>
>
> On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir  wrote:
>
>>
>> > On 7 Nov 2015, at 11:39 AM, Dave Garrett 
>> wrote:
>> >
>> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
>> >> Update: we discussed this extensively in Yokohama and based on Watson's
>> >> feedback and offline comments from David McGrew, the consensus was
>> that we
>> >> needed to add some sort of rekeying mechanism to support long-lived
>> flows.
>> >> Expect a PR on this next week.
>> >>
>> >> Note: We'll still need guidance to implementations on when to re-key,
>> but
>> >> we don't expect to have a hard protocol limit.
>> >
>> > If re-keying is back up for discussion, let me restate my request for
>> it to be routine, rather than only an niche-case feature. Any re-key
>> schedule should be considered valid, but the spec should set a
>> "SHOULD"-level requirement that the minimum be once every N hours or M
>> terabytes, whichever comes first (where N & M are some bike-shedable
>> numbers with some expectation of randomization in values for each period).
>>
>> N and M will be different depending on the algorithms, no?
>>
>> I think before we start with pull requests we should be certain of what
>> the requirements are for this rekeying.
>>
>
> These were discussed extensively both in the interim and at IETF. The
> purpose of rekeying in this context is to deal with cryptographic
> exhaustion, namely having more ciphertext under the same key than is safe
> for a
> given algorithm (where safe is defined by an analysis like the one Watson
> has posted upthread).
>

To be clear, I'm not saying that there aren't other reasons for rekeying,
just that the problem agreed to address is the one above.

-Ekr


> Are we OK with just generating new keys from the same internal state (so
>> the handshake message is pretty much only “rekey now”),
>
>
> I believe this is what we agreed both in Seattle and in Prague.
>
> -Ekr
>
>
>
>> or
>> Do we want freshness (usually in the form of new mutual nonces, or
>> Do we want forward secrecy so another diffie-hellamn exchange?
>>
>> Yoav
>> ___
>> 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] Data limit for GCM under a given key.

[Dang, Quynh]

Tony,


You are correct. An Indistinguishability bound promises you no attacks will be 
below the bound assuming the claimed property(ies) of the underline function in 
the construction (mode) hold(s).


A distinguishing attack below the bound tells you that the construction or the 
underlined function is not strong or ideal as you would like, but it does not 
directly (100%) lead to a break of plaintext confidentiality or authenticity.  
Here, confidentiality protection of plaintext(s) is that an attacker who does 
not know the key can not find out any part of the plaintext(s) by decryption. 
And, I explained the point in the previous emails.


Under indistinguishability framework, one should not even go to 2^32 blocks 
with GCM when the IV space is 2^64 because there is a high probability of 
ciphertext collision with 2^32 ciphertexts.


Quynh.





From: Tony Arcieri 
Sent: Friday, November 6, 2015 7:59 PM
To: Watson Ladd
Cc: Dang, Quynh; tls@ietf.org
Subject: Re: [TLS] Data limit for GCM under a given key.

On Friday, November 6, 2015, Watson Ladd 
> wrote:
On Wed, Nov 4, 2015 at 3:43 PM, Dang, Quynh  wrote:
> I did not talk  under indistinguishability framework. My discussion was about 
> confidentiality protection and authentication.

What is the definition of "confidentiality protection" being used here?

I too am confused by Quynh's statement. Indistinguishability is the modern bar 
for confidentiality and authentication.

Quynh, are you talking about anything less than IND-CCA2? If you are, that is 
less than the modern bar I would personally consider acceptable.


--
Tony Arcieri

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

[TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the 
IETF.

Title   : ChaCha20-Poly1305 Cipher Suites for Transport Layer 
Security (TLS)
Authors : Adam Langley
  Wan-Teh Chang
  Nikos Mavrogiannopoulos
  Joachim Strombergson
  Simon Josefsson
Filename: draft-ietf-tls-chacha20-poly1305-02.txt
Pages   : 7
Date: 2015-11-06

Abstract:
   This document describes the use of the ChaCha stream cipher and
   Poly1305 authenticator in the Transport Layer Security (TLS) and
   Datagram Transport Layer Security (DTLS) protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Adam Langley]

On Tue, Nov 3, 2015 at 8:25 AM, Benjamin Kaduk  wrote:
> %   1.  The 64-bit record sequence number is serialized as an 8-byte,
> %   big-endian value and padded on the left with 4 zeroes.
>
> I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...)
>
> "padded on the left" also has some potential for ambiguity (though not as 
> much); something about "four zero octets are prepended to the stream" might 
> be less ambiguous.

Sorry, I missed seeing this for -02, but I now have locally, for the
next revision:

"The 64-bit record sequence number is serialized as an 8-byte,
big-endian value and padded on the left with four 0x00 bytes."


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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