[ntp:hackers] A stop-gap authenticated time service

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Nov 9 11:35:46 UTC 2015


--------
In message <20151109105102.GM11550 at localhost>, Miroslav Lichvar writes:

>> If anybody else wants to implement this in other NTP programs I
>> kindly ask that you get in touch with me:  We may eventually need
>> to issue an RFC about this, and we should not make that harder
>> for anybody than it needs to.
>
>As mentioned earlier, openntpd already does something like that, maybe
>except the trick working around the one-second resolution in the
>retrieved date.

This is IMO the crucial bit that makes the uncertainty windows usable.

>But I'm not sure this approach scales well. Consider how expensive TLS
>is and how many clients a single server could handle when compared to
>the plain NTP or NTP+NTS. To me it looks like a band-aid that will
>need to be ripped off when NTS or something else is readily available
>in NTP.

It is by no means ideal, but it is possible now, and it would give
people a way to mitigate and likely neuter the naked NTP attacks.

The load is smaller than people generally think, one million clients
doing one HTTPS check every hour is way below the capacity of vanilla
server hardware HW.

It is not obvious to me that the manual crypto overhead of NTS
will be able to compete with the growth of the HTTPS ecosystem.
Certainly the product development for HTTPS proceeds much faster
than it would ever do in NTS.

If we consider this just a bandaid until NTS, we don't need to do much
more, but if we decide this is a bona-fide time synchronisation method,
we should push an RFC out there which explains how this interacts with
HTTPS servers, and what they can do to make it even better.

For instance we could standardize a "X-Time" header returned for
"HEAD /" requests, which contains beneficial information:

  * fractional second

  * leap second status

  * RX timestamp

If we do that, we can deliver pretty much anything NTS can deliver,
without creating a new cryptographic key-management domain.

That may count for a lot in user-adoption.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the hackers mailing list