Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp

[Marcus Dansarie <[e-mail]>]

Thank you! My replies follow inline.

Kind regards,
Marcus


On 2018-12-10 23:08, Dieter Sibold wrote:
> Hi Marcus,
> here are my comments for pull request #15
> 
> 
> 
> 077f0da6
> The current documents translates correctly without any errors.
> Therefore, I would imply that the additional section closing tag is one
> too much.

This appears to have been due to an error on my end. My apologies.

> ---------------------
> a7c4f563
> I don't get why you want to relax this requirement. Please explain.

There may be some (weird) cases where a user wishes to manually instruct
their NTP client to use the received cookies with a different NTP
server. I also believe SHALL should be reserved for cases where
non-compliance could cause security issues or cause the protocol to
break. This is not an important issue for me, however, and I'll be
perfectly happy even if this isn't included.

> ---------------------
> 2b436df8
> I agree in principal. I suggest following changes
> 
> ### original
>         <t>
>           Implementers must be aware of the possibility of "NTS stripping"
>           attacks, where an attacker tricks clients into reverting to plain
>           NTP. Naive client implementations might, for example, revert
>           automatically if the NTS-KE handshake fails. A man-in-the-middle
>           attacker can easily cause this to happen. Even clients that
> already
>           hold valid cookies can be vulnerable, since an attacker can
> force a
>           client to reperform the NTS-KE handshake by sending faked NTP
> mode 4
>           replies with the NTS NAK kiss code. Forcing a client to
> reperform the
>           NTS-KE handshake can also be the first step in more advanced
> attacks.
>         </t>
> 
> ### new
>         <t>
>           Implementers must be aware of the possibility of "NTS stripping"
>           attacks, where an attacker tricks clients into reverting to plain
>           NTP. Naive client implementations might, for example, revert
>           automatically to plain NTP if the NTS-KE handshake fails. A
> man-in-the-middle
>           attacker can easily cause this to happen. Even clients that
> already
>           hold valid cookies can be vulnerable, since an attacker can
> force a
>           client to repeat the NTS-KE handshake by sending faked NTP mode 4
>           replies with the NTS NAK kiss code. Forcing a client to repeat
> the
>           NTS-KE handshake can also be the first step in more advanced
> attacks.
>         </t>
> 

Ok.