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

[Watson Ladd <[e-mail]>]

On Nov 5, 2014 10:01 AM, "Nico Williams" <[e-mail]> wrote:
>
> On Wed, Nov 5, 2014 at 11:56 AM, Watson Ladd <[e-mail]> wrote:
> > On Nov 5, 2014 9:51 AM, "Nico Williams" <[e-mail]> wrote:
> >> Perhaps we should pin latest datetime advertised by the server for
> >> which other things are being pinned.  This would prevent time travel
> >> into the past.  Time travel into the far future is, presumably, not
> >> that big a deal, even with pinning, because server operators will
> >> strive to make sure that doesn't happen.
> >
> > Or kernels can set the flag that stops this from being possible. We should
> > note the issue, and, as with randomness, let the vendors solve it.
>
> User-land code can "correct" kernel time.  For example, most Kerberos
> libraries record time offset between the client and the KDC, and
> correct local time when making AP-REQs for any service subsequently.
> Clients trust KDCs, so that's OK.
>
> But if TLS clients also attempt to correct local clocks on the basis
> of time advertised by arbitrary servers...  Obviously, that's the
> problem: TLS clients should not use the TLS protocol to attempt to
> correct local clock skew.

??

No, the issue is that an attacker can fool NTP clients, and thus
change the time on a computer. All we need to do is note the need for
secure clocks, and let the implementor figure out how to get the right
time. If there is an issue with NTP security, and there is, that's for
the NTP WG to solve. That may be an OS issue: the same is true for the
generation of random numbers. We already depend on secure time for
OCSP stapling and certificate validity: I don't think Hugo's proposal
is worse in that regard. We need to document the dependency, but
whether water clock, sundial, atomic clock, pendulum clock, or RTC on
the motherboard, we don't care how that is satisfied. Martin Thompson
makes this same point upthread.

I think the OPTLS proposal makes it extremely easy to host servers
worldwide while keeping the certificate in a nice jurisdiction, or on
a slow HSM while enabling performance enhancements as computers get
faster. I think it resolves many longstanding security issues, and
doesn't introduce any obvious new ones. (Of course, the cross-protocol
attacks may be an issue: why data signed with the same key doesn't
have a type pre-appended to it in the form of a UUID or similar is
beyond me)

It provides most of the tricky requirements like 0-RTT and privacy of
certificates. It's genericly secure. It's a performance enhancement
for sites that have avoided PFS until now because of performance
issues. There's plenty of details to flesh out, and it may be that we
find showstoppers that make the entire approach not work. But it would
be a shame if we wasted another 6 months getting to this point by
patching a protocol that is extremely hard to think about: there isn't
a 0-RTT proposal on the table yet beyond this one.

We still need to decide some details if we move forward, and hammer
out the serialization and interaction with the TLS 1.2 negotiation
that ensues when a TLS 1.3 hello is sent to a TLS 1.2 server (do we
share group specifications? which extensions make sense and which
don't? are ciphersuites going to be shared across the Client Hello?
How do signature groups relate to the DH groups?) If I could start
with a clean slate, it would be with this proposal. Yes, it's a major
change. It doesn't solve all our problems. Some semantics,
particularly around client authentication, will likely change.
However, it has the great benefit of existing, and I hope we decide to
build on it or find flaws that doom it.

Sincerely,
Watson Ladd


>

> Nico
> --