On Sat, Jan 19, 2019, 4:30 PM Hal Murray via devel
> > 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
> So enforcing key rollover isn't a concern. The recommended server key
> rotation is primarily about forward secrecy then, I presume.
Draft says:
Erasing old keys provides for forward
secrecy, limiting the scope of what old information can be stolen if
a master
On Sat, Jan 19, 2019, 5:35 PM Hal Murray via devel
> > My thought about how to enable NTS for the pool would involve requiring
> a SRV
> > record lookup for NTS-KE
>
> That SRV lookup could return multiple names. Each would point to a
> separate
> NTS-KE server.
>
> An alternative approach would
> My thought about how to enable NTS for the pool would involve requiring a SRV
> record lookup for NTS-KE
That SRV lookup could return multiple names. Each would point to a separate
NTS-KE server.
An alternative approach would be to extend the NTS-KE protocol to support
multiple answers.
> Imagine a server that uses the suggested cookie approach and simply never
> rolls over K. As long as the client daemon is running, its cookies will be
> valid and keep getting renewed. C2S and S2C will never get rolled over.
> Should the client track an expiration limit in memory, and when
> 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
On 1/19/19 5:42 PM, Hal Murray via devel wrote:
>
> I asked on the IETF NTP list.
>
> dfoxfra...@gmail.com said:
>> On Sat, Jan 19, 2019 at 6:23 AM Hal Murray wrote:
>>> Is that number so large for the algorithms we will use that we don't have to
>>> consider it? Assume the client is sending 1
On 1/19/19 5:28 PM, James Browning via devel wrote:
> On Sat, Jan 19, 2019, 2:50 PM Richard Laager via devel wrote:
>>
>> neither is set:
>>
>> For a pool, behave as "nonts" (because the common pool case is a public
>> pool with volunteer servers that will not be able to present a valid
>>
On Sat, Jan 19, 2019, 2:50 PM Richard Laager via devel
> neither is set:
>
> For a pool, behave as "nonts" (because the common pool case is a public
> pool with volunteer servers that will not be able to present a valid
> certificate for the pool).
Actually, I think I came up with a way to NTS
On 1/19/19 5:10 AM, Hal Murray wrote:
>> * Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an
>> expiration time to its cookie format) or leave expiration to clients?
> Maybe, but not initially. We need a crypto geek to tell us how much we can
> safely encrypt and/or authenticate
Richard Laager said:
> * Is NTPsec going to use the suggested cookie format?
Sure, but it isn't a detailed spec.
>* Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an
> expiration time to its cookie format) or leave expiration to clients?
Maybe, but not initially. We need a
On 1/19/19 12:05 AM, Eric S. Raymond via devel wrote:
> I think we can fix this by adding a glossary to adoc pinning down the
> terms of the discussion. There probably are too many senses of "key"
> floating around.
The whole discussion is about the definitions, so I can't magically
solve this
12 matches
Mail list logo
