The key-manahement argument

[James Browning]

On Sat, Jan 19, 2019, 4:30 PM Hal Murray via devel <devel at ntpsec.org wrote:

>
> > The NTS-KE servers would have to share NTS master keys (and cookie
> formats!)
> > with volunteer NTP servers.
>
> If you are interested in security, sharing a master key with many servers
> seems like a bad idea - too many opportunities for a leak.  With something
> like the pool where anybody can join (and thus get the key), security is
> no
> longer possible.
>
> There are actually two parts to TLS security.  One is the technical side.
> Can
> the crypto be broken?  Has the secret key leaked?  The other is trust.  Do
> you
> trust the name you are using?  The name you used could be a malicious
> clone of
> a legitimate name: F00 vs FOO.  Or the correct company could be
> untrustworthy.
>
> The pool might be a good way to test NTS code.  I don't see how to get a
> serious level of trust with volunteer effort.
>

"K" could be stored in another field in the database as it has no causal
relation to the TLS keys or c2s/s2c. It would require updating such a field
periodically either from a local process or a remote injection.

I could try to fabricate  a mockup if that would be clearer and/or more
useful.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190119/d3f93075/attachment.html>