[Ntp] Antw: [EXT] Re: Post NTS, Is shared key authentication interesting?

[Ulrich Windl <[e-mail]>]

>>> Hal Murray <[e-mail]> schrieb am 26.05.2020 um 20:37 in
Nachricht
<15818_1590518253_5ECD61ED_15818_1499_1_20200526183714.6514740605C@ip-64-139-1-6
.sjc.megapath.net>:

[...]
> 
> Are crypto NACs interesting?  Is the added complexity worth the benefit?
> 
> If all you get is "NAC", what do you do next when trying to debug things?  
> What's different from what you would do if you didn't get any reaponse?

Just assume on any error that can happen for a https connection you don't get
a response...
I fyou are in control of client AND server, you may not need crypto NACs. If
you are in control of the server, you also may not need crypto nacs, but if you
only have access to the client and the responses, crypto nacs seem valuable
IMHO.

> 
> Should we have a separate extension type for Crypto NAC, possibly with a 
> text 
> payload.  How many sub‑types are there?  Will that leak information?  ...

I think it will not leak more information than before. An optional textual
description seems like a good idea. Maybe the server could be restricted to
provide such, or not. A model like SMTP's extended status codes sounds like a
good idea to me (codes for computers, messages for humans (and maybe computers,
too).

> 
> ‑‑‑‑‑‑‑‑‑‑‑
> 
> How important is it to hide the algorithm? Is padding good enough?  Is a min

> 
> length that we pick now going to cause problems tomorrow?

Security by obscurity is not the better security IMHO. At least not when
regarding the algorithm being used.

> 
> ‑‑‑‑‑‑‑‑‑‑‑
> 
> Note that "MAC" is slightly ambiguous in this context.  At the low level, it

> 
> is just some bits you get from a crypto routine.  At the NTP level (this 
> discussion), it is the combination of a key‑ID (4 bytes) and the low level 
> MAC.

Maybe call this "signature" in the future? Or X-MAC (eXtended MAC)?

Regards,
Ulrich