Re: [TLS] cross-domain cache sharing and 0rtt

[Stephen Farrell <[e-mail]>]

On 30/12/16 16:14, Eric Rescorla wrote:
> On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <[e-mail]>
> wrote:
> 
>>
>> Hiya,
>>
>> On 29/12/16 19:08, Eric Rescorla wrote:
>>> On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <
>> [e-mail]
>>>> wrote:
>>>
>>>>
>>>>
>>>> On 29/12/16 18:38, Eric Rescorla wrote:
>>>>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <
>>>> [e-mail]
>>>>>> 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.
>>>>
>>>
>>> Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes:
>>> https://tlswg.github.io/tls13-spec/#NewSessionTicket
>>
>> What I'm wondering is if we're maybe missing a server-side check
>> on that, with the possible attempted attack of a 0rtt replay in
>> mind. E.g. a MUST check for the server that SNI is the same as for
>> initial h/s before processing early data, (as is done for ALPN now)
>> and/or some guidance about what might not be an obvious relationship
>> between any 0rtt replay detection mechanisms and session ticket
>> equivalents
> 
> 
> I believe that the text I quote below already requires that check. The
> reason
> it's there and not in the 0-RTT text is that it is a requirement on
> resumption
> which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RTT
> requirement but not a resumption requirement.
> 
> I.e.,
> Can resume only if SNI is equal
> Can accept 0-RTT only if (resumed && ALPN is equal)

Fair enough. I didn't read enough text to get that clearly
I guess, which is my fault:-)

Thanks,
S.



> 
> -Ekr
> 
> 
> 
>> "Any ticket MUST only be resumed with a cipher suite that has the same KDF
>>> hash as that used to establish the original connection, and only if the
>>> client provides the same SNI value as in the original connection, as
>>> described in Section 3 of [RFC6066]
>>> <https://tlswg.github.io/tls13-spec/#RFC6066>."
>>>
>>> We have discussed relaxing that restriction, specifically to allow the
>>> following case:
>>>
>>> - Client connects to server with SNI=A and the server supplies a cert
>> with
>>> SNI=A, B
>>> - Client reconnects to server and tries to resume with SNI=B
>>>
>>> See PR: https://github.com/tlswg/tls13-spec/pull/777.
>>
>> I'd wonder if that optimisation is really worthwhile, esp if it
>> opens the door wider to 0rtt replay. (And it seems like it'd be
>> somewhat complex to take advantage of the optimisation anyway.)
>>
>>>
>>> However, the general consensus was to leave this out of the base spec,
>>
>> Seems right.
>>
>> Cheers,
>> S.
>>
>>> though we
>>> might supply an enhancement for that later (and potentially slightly
>> soften
>>> the above
>>> language to foreshadow such an enhancement).
>>>
>>> -Ekr
>>>
>>>
>>>
>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>