On 29/12/16 18:38, Eric Rescorla wrote:
> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie
>> wrote:
> 
>>
>> Hiya,
>>
>> On 29/12/16 17:37, Adam Langley wrote:
>>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
>>> specifies that (EC)DH values must be fresh for both parties in TLS
>>> 1.3.
>>>
>>> For clients, this is standard practice (as far as I'm aware) so should
>>> make no difference. For servers, this is not always the case:
>>>
>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
>>>   ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
>>>     than a day.
>>>   ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
>> ...
>>
>> As an individual, I'd be in favour of this change but reading
>> over [1], section 5, I wondered if we'd analysed the effects of
>> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
>> The situation being where session ID based caches or session ticket
>> equivalents in tls1.3 are shared over multiple domains.
>>
>> I don't recall this being explicitly considered, but maybe that's
>> just me forgetting. And hopefully the analysis is that such re-use
>> doesn't enable broader replay of early data, but there may be
>> something worth a mention in the tls1.3 spec, e.g. that there may
>> be linkages between the duration for which entries are maintained
>> in resumption and replay detection caches.
>>
> 
> This question seems essentially orthogonal to the question of ECDHE key
> reuse
> because even if you use the same ECDHE key in perpetuity you get unique
> traffic keying material for each connection.

Fair enough, I probably should've started a new thread so have
done that now.

S

> 
> -Ekr
> 
> 
>> Cheers,
>> S.
>>
>>>
>>> [1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
>>> pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
>>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
>>>
>>>
>>> Cheers
>>>
>>> AGL
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to