Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

[Colm MacCárthaigh <[e-mail]>]

On Mon, Mar 28, 2016 at 1:31 PM, Karthikeyan Bhargavan <
[e-mail]> wrote:

> *Resumption and Forward Secrecy*
>
>
> PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes?
> This is already better than TLS 1.2 where we had no way to do
> forward-secret resumption.
> In that case, the concern is mainly for 0-RTT, which I agree is harder to
> get right.
>

Yes  ... and  I left that out in the interests of clarity for the argument
... but I mean this scheme for the 0RTT data (hence the tying it together).
I should have been more clear, thanks!


> *0RTT and Safety*
>
> I see at least three different challenges with 0RTT as defined. The first
> is a general and high level one: we seem to willing to accept a "lower"
> level of security for 0RTT data (e.g. no FS, even if the rest of the
> session has it). Why? What is it we think is special about this data that
> it is "less" worth protecting? surely there are very sensitive things in
> urls, surely there are potential oracles and other things in there too? It
> just seems super strange to me.
>
>
> I wonder if the QUIC folks have an answer to this question? It would be
> good to gather “typical” intended use cases of 0-RTT data.
> In any case, it is good to distinguish this forward secrecy concern from
> replay, because secrecy is in the control of the client, who can choose to
> send or not send sensitive data, but replay detection is in the hands of
> the server.
>

A lot falls out from replay. If there are side-channels in how the server
handles the 0RTT section (and we can be certain that there will be) then
the ability to replay the section greatly amplifies the attackers ability
to use those side-channels to determine things about the data. Where the
data is a url, which can contain things like passwords, session ids, and
other bearer tokens, that's a bad combo.


> Yes, detecting and preventing replays by default would be good.
> However, I wouldn’t tie this in with the session mechanism.
> Wouldn’t we want to prevent replay of DH 0-RTT requests?
>

I should be more clear: I mean to replace the DH 0-RTT part with 0-RTT
parts that are encrypted under separate single-use PSK states.

-- 
Colm