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

[Eric Rescorla <[e-mail]>]

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)

-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
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>