Subject: Re: [TLS] Data volume limits

From: Watson Ladd <[email-masked]>
Date: Fri, 1 Jan 2016 20:20:42 -0500

On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith <[email-masked]> wrote:
> Ilari Liusvaara <[email-masked]> wrote:
>>
>> OTOH, you can't drop an attacker knowing older key without doing
>> new key exchange.
>
>
> I think it would be very unfortunate to have the complexity of key update
> (the new keys are derived from the old keys) without having the benefits of
> rekeying (the new keys are independent of the old keys).

What complexity? Sending a special packet with a different protocol
that triggers a change in record layer state is not that tricky, and
even DTLS is designed to handle this already. In fact one could even
use the epoch number implicitly.

What benefits? The concern isn't that an attacker obtains the key, but
that confidentiality is lost. If we're worried about attackers who can
read memory the answer is clear: write in a language that doesn't
permit this.
>
> Note that NIST Special Publication 800-133 [1] defines these separate terms,
> and I suggest we use them in this conversation to avoid confusion:
>
> Key update: A procedure in which a new cryptographic key is computed as a
> function of the (old) cryptographic key that it will replace.
>
> Rekey: A procedure in which a new cryptographic key is generated in a manner
> that is independent of the (old) cryptographic key that it will replace.
>
> [1]
> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf.
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 4 Jan 2016 13:13:48 +0100

On 12/28/2015 10:09 PM, Salz, Rich wrote:
>> When the key is changed, the change procedure should involve new randomness. 
> 
> I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not a cryptographer, maybe one of the ones on this list can chime in.
> 
> "Crank the KDF" suffices.

The attacks against GCM are at the stage where even “periodically
increment the key by one“ would thwart them, right?

The risk is that without real re-key (introducing additional
randomness), someone might come up with a better attack that reduces the
security level below the design target, and which requires similar
effort as the existing GCM attack (four years of traffic at terabit
speed, it seems).

Real re-key is difficult to introduce as an afterthought (see my recent
response to Hubert), and I'd rather see such issues fixed at the cipher
level if at all possible.  The current update-key mechanism doesn't have
the complexity issue of real re-key, but it's ambiguous if it's a design
goal to paper over cipher deficiencies in the rest of the protocol.

Florian