Re: [Ntp] [EXT] Re: NTPv5 KISS code support

[Danny Mayer <[e-mail]>]

On 11/21/23 10:39 PM, Hal Murray wrote:
> Me:
>> In the Cryptographic failure case, it might be reasonable to send back a
>> non-authenticated message saying why the crypto didn't work.  The catch is
>> that the receiver would have to not take any action since it might be forged,
>> but it could be logged for debugging.
> Danny Mayer said:
>> Absolutely not. Providing any information at all gives an attacker insights
>> as to what they did wrong.
> Salz, Rich said:
>> In general, you want to avoid giving any details about what went wrong if the
>> cryptography fails, because that is information that an attacker can use.
> Miroslav Lichvar said:
>> Hm, I forgot about this one. I agree it's nice to be able to restart NTS-KE
>> quickly instead of waiting for 8 or how many missing responses when the
>> client's key is no longer valid.
> RFC 8915 says:
>> If the server is unable to validate the cookie or authenticate the request,
>> it SHOULD respond with a Kiss-o'-Death (KoD) packet (see Section 7.4 of RFC
>> 5905 [RFC5905]) with kiss code "NTSN", meaning "NTS NAK" (NTS
>> negative-acknowledgment). It MUST NOT include any NTS Cookie or NTS
>> Authenticator and Encrypted Extension Fields extension fields.
> This seems like an interesting topic.  I don't care what the answer is.
>
> Should we set a good example for security by not returning ANYTHING when the
> NTS crypto doesn't work?  This would require patching RFC 8915.  There is no
> mention of KoD in the security consideration section of 8915.  There is text
> in the body about checking the UID in unauthenticated packets.
RFC 5905 Section 9.2 defines a crypto-NAK in the case of a failure. Not 
sending anything has historically been shown to cause more traffic. The 
crypto-NAK does not send any useful information and that section 
instructs the client to discard the packet after inspection. The RFC 
says that the header data should be normal but in this case I would 
suggest it should actually return the same as KISS codes where the 
server receive and transmit timestamps are considered unreliable and 
should be discarded. In the Reference NTP those timestamps are the same 
as the transmit timestamp and have the interesting property of telling 
the client that their clock is off by half the round-trip delay which 
would push their clock off by that amount if they ignore the KISS code.
>
> Is there a tradeoff between helping the good guys and helping the bad guys?
No, you provide no information at all. Good guys will have access to the 
logs and be able to deal with issues.
>
> I'd be happy if we dropped KoD totally.  It will simplify documenation (and
> code) and avoid discussions like this one.  KoDs can be forged, so any
> discussion has to consider DoS-ing and that gets complicated.
KISS codes are useful and allows the server to tell the client to back 
off or go away.
>
> Does anybody have any data on KoDs?  Do they do any good?  I'd expect that
> most of the software that receives them won't know how to process them.
>
I suspect Judah might have some information on that.

Danny