Re: [TLS] 0-RTT security considerations (was OPTLS)

On Fri, Nov 21, 2014 at 10:51 AM, Nico Williams <nico@cryptonector.com> wrote:
> On Thu, Nov 20, 2014 at 09:06:21AM -0800, Eric Rescorla wrote:
>> On Wed, Nov 19, 2014 at 12:51 PM, Nico Williams <nico@cryptonector.com>
>> wrote:
>>
>> > Certainly in the resumption case.
>>
>> Also in the semi-static DHE cases.
>
> Yes, of course (it's like resumption in a way).
>
>> > However, in other cases, we'd have to
>> > have ensure that whatever oob method is used for establishing the
>> > server's public key also conveys this (e.g., we'd need an RR type for
>> > indicating this for DANE).
>>
>> I don't see that that's a problem. At present DANE doesn't contain enough
>> information for the client to generate a 0-RTT handshake at all, so as
>> a practical matter we would need to extend the record format, so that
>> would implicitly agree to 0-RTT (or explicitly if you prefer).
>
> My inclination is to think that adding a new RR type or extending TLSA
> for this is not worthwhile.  See below.
>
>> >   It's much easier to have the server hold the
>> > early data and have it bound into the client's next handshake msg.
>>
>> This is not generically possible, because the client may have used
>> a key that the server has forgotten, which requires the client to
>> retransmit.
>
> Yes, indeed.  Applications that can retransmit, could do that.  For
> other applications (which is to say: most) the result has to be failure,
> and then a reconnect.  Not good.  This is a good reason to want to
> minimize 0-RTT usage to cases where the client has good reason to think
> the server will be able to handle it: when a) the server said or
> advertised so earlier, b) not much time has passed since.

Why wouldn't the implementation of TLS automatically resend 0-RTT data
if the server didn't accept it? This seems like the right solution.

>
> 0-RTT is an optimization, but if it can lead to failures that
> applications must special-case, then that's problematic.  For HTTPS
> that's probably not a problem (it's just one reconnect).
>
> Will 1.3 support 0-RTT?

Isn't this a charter goal?

>
>> > Yes, of course.  With TLS 1.2 one can renego.  Unless I missed
>> > something, there's nothing in 1.3 for protecting the client's ID.
>>
>> In TLS 1.3, the client's second flight is sent encrypted. If it were sent
>> as part of the first flight, it would also be sent encrypted.
>
> So... is confidentiality protection of the client's cert/ID explicitly
> supported in 1.3?  That'd be great news.

Again, I thought this was a charter goal.

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin