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

[Kurt Roeckx <[e-mail]>]

On Wed, May 27, 2020 at 11:55:36AM +0200, Kurt Roeckx wrote:
> On Wed, May 27, 2020 at 11:33:20AM +0200, Ulrich Windl wrote:
> > >>> 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).
> 
> I'm not sure I fully understand what you're talking about, but
> sending an error message that something with the crypto was bad
> it a bad idea. You should pretend that everything was ok. An
> attacker should not be able to see the difference between an ok
> and a not ok message. Look for instance at the TLS RFCs what they
> write about a Bleichenbacher attack.

Since we're talking about a shared (symatric) key, it's probably not
that important.


Kurt