Re: [TLS] OPTLS: Signature-less TLS 1.3

[Watson Ladd <[e-mail]>]

On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <[e-mail]> wrote:
>
> On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
> <[e-mail]> wrote:
>>
>> > > PROTOCOL OPTLS:
>> > >
>> > > ClientHello
>> > > ClientKeyShare
>> > > ClientData* [K0]       -------->
>> > >                                            ServerHello
>> > >                                            ServerKeyShare
>> > >                                            ServerCertificate* [K1]
>> > >                                            ServerFinished [K2]
>> > >                        <--------           ServerData* [K2]
>> > > ClientFinished* [K2]   -------->
>> > >
>> > >
>> > >             Protected Application Data [K3]
>> > >                        <------->
>> > > 1-RTT CASE:
>> > >
>> > > The basic 1-RTT case omits the ClientData* field. It includes a
>> > > ClientKeyShare
>> > > g^x and a ServerKeyShare g^y and an optional (encrypted) server
>> > > certificate.
>> > > If the certificate is sent (it can be omitted if the client has
>> > > indicated
>> > > that
>> > > it knows the server key as in the case in the 0-RTT scenario) and is
>> > > encrypted,
>> > > the encryption key K1 is derived from g^{xy}.
>> > >
>> > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
>> > > used
>> > > to
>> > > authenticate-encrypt the ServerFinished and ClientFinished messages
>> > > (which
>> > > include a hash of the previous traffic) and to encrypt data from the
>> > > server
>> > > if
>> > > such data is piggybacked to the second message.
>> >
>> > How does the client get the DH (or ECDH) group parameters used by the
>> > server?
>>
>> Presumably from ServerHello (with CKS being optimistic).
>>
>> But the case where client misses all its guesses needs to be handled.
>
>
> Unless I'm missing something, this can be handled the way that we
> currently handle missed guesses, I.e., by having a HelloRetryRequest
> followed by a new ClientHello/ClientKeyShare. Though of course
> the server does need to either keep their RSA private key online
> or periodically generate new signed DH shares for every group.
>
>
>>
>> However, this poses some challenges with respect to revocation. From what
>> I
>> understand, the parameters are intended to have limited lifetime (much
>> shorter than EE certificates).
>>
>> The reason this is problematic is that one can't really rely on clocks:
>> - Even if you happen to have sub-second accurate clock, a lot of computers
>> don't.
>> - The time protocols often aren't secured, allowing attacker to play
>> tricks
>>   with endpoint time.
>
>
> We're already starting to have that problem because of a desire to move to
> OCSP
> stapling, which, with staple, effectively gives the server a credential
> which is
> valid only within a fairly narrow window. However, I think you're right that
> this
> probably limits the range of lifetimes you can use with these signed DH
> keys.

That's not the problem Illari was talking about: It's not that g^s has
limited lifetime, but that there is no way to know that the lifetime
is expired, so it has long lifetime. NTP is not secure, so we have to
deal with bad clocks. In the case of certificates, this is usually not
so bad as the lifetimes are long. It might not be a problem for this,
as we can occasionally resign, keep s in memory and not be worse off
than today, or say that TLS clients need trusted clocks to avoid
compromise when s is revealed.

I don't think this is worse than today, where short lived certificates
can be wound back by similar means. However, the fact that this
requires changes to the handling of secrets may prove a barrier to
adoption of TLS 1.3. I hope people who are involved with more complex
things than tiny herds of beefy boxes will comment on how this
proposal does or doesn't work for them, and that these issues don't
turn out to be a dealbreaker.

Long term we need secure NTP if we want to limit things by time: there
is a proposal in the NTP WG, but it is overly complex and will likely
never be implemented due to gratuitous use of CMS. This time issue may
very well need to go into Security Considerations as unresolveable.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> 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