NTS

[Hal Murray]

I assume that it should be our top priority.

I'd be a lot happier if I had a good feel for the big picture.  How will NTP 
be used?  What does a client have to do to use it?  What does a server have to 
do to support it?

[I may not be asking the right questions.  I hope somebody can read between 
the lines and answer what I should have asked.]

Are we going to use the same certificates/chains that web browsers use?  I 
think so, but I don't have a good feel for this area.  Are there any other 
uses for the "web" certificates?

I think what's going on is that trust is a two step process.  If I decide I 
want to trust NIST for time or Amazon for commerce, I have to translate NIST 
or Amazon to nist.gov or amazon.com, then the software can establish that 
nist.gov or amazon.com is trusted.  Translating an organization name to domain 
name is an out-of-bounds operation.   I think that second step doesn't care 
why a domain is being checked so we should be able to use the existing 
certificates.

>From an operational standpoint, I think that means we want separate 
certificates for www.example.com and ntp.example.com so the private parts can 
be put on separate machines.  Do we need a BCP?

--------

There is a startup problem.  Does the library that checks certificates have an 
option to bypass the time checks?  If not, do we need something like a 
separate startup phase?

-------

> Blocker: To move on this, we need a detailed interface contract from Daniel
> describing how NTPsec needs to talk to his NTS symbiont.

I'm assuming there will be a pipe or socket.  (or thread)

How big is the "NTS symbiont"?  Is it mostly library?  Should it be a separate 
program, or part of ntpd with a library doing most of the work?  Is the code 
c, phthon, go, ...?

What sort of tools already exist for debugging certificates?  What will we 
need for debugging NTS?

I think the authentication area in ntpd is reasonably clean.  There is a 
struct with everything in it.  It gets setup by the code that reads keys and 
passed around by everything else.  It should be simple enough to extend that 
as needed.

We can test/debug things by letting the calls to NTS block.


Currently, ntpd needs keyId, key-type, and key.  Currently, the keyIds are 
assigned by hand.  The client side needs a keyId-IPAddress binding.

I'll have to study the draft again to start thinking about an API.

Will we need more than one certificate check in progress at a time?  (more 
than one thread)



-- 
These are my opinions.  I hate spam.