Re: [Ntp] I-D Action: draft-ietf-ntp-roughtime-08.txt

[Hal Murray <[e-mail]>]

[e-mail] said:
> Thanks for taking a look. I agree there are two different things here, but we
> can split later as an editorial matter. When it was originally split the
> second bit was too ambitious and small, and got neglected by the editor (me).
> It also had some issues with getting the envisioned environment off the
> ground, hence the much sparser text here. 

Well, I'd encourage you to do the split now.  I think that would help each 
document focus on the issues that are important for it.  Move everything about 
proof to the second document.  Simplify the RoughTime as much as possible.

> I think we need both. Unless we're willing to completely trust a server to
> give us the time. 

NTP is already setup to use 3 servers and ignore a bad one.



> The webPKI makes design decisions that are incompatible with what you're
> suggesting. We would need to pin end entity certs, which is discouraged and
> they have 90 day or less lifetimes. Revocation information isn't published
> after expiry

Right.  I think the critical issue is lifetime.  I didn't say it, but I was 
assuming that we would setup self-signed certificates with a long lifetime.  
Are there any sanity checks in TLS software that reject certificates with 
super-long lifetimes?

The idea is not to pin one of the webPKI certificates but to use one of our 
own and distribute it outside of their setup the same way you are going to 
distribute your keys.  That lets us use the already deployed NTS/TLS software.


[How to find trusted servers and their keys]
> That's the sort of policy design we kick to vendors, akin to PKIX vs. WebPKI
> (CAB forum, dev-security-policy, etc). 

I think it's more complicated than that.  Where are the vendors going to get 
the data?

Somebody has to setup and run the servers and somebody (maybe more than one) 
has to vet the servers, keep track of the ones they like, and distribute a 
list of them and their keys.

--------

If you are using UDP, you need to make sure the request is as long as the 
response in order to avoid amplification on DDoS attacks.  That may require 
padding on the request.

-- 
These are my opinions.  I hate spam.