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

["Dieter Sibold" <[e-mail]>]

Dear Miroslav,
sorry for the late reply. See my comments inline.

Dieter Sibold
[e-mail]

On 6 Dec 2018, at 13:16, Miroslav Lichvar wrote:

> On Tue, Nov 06, 2018 at 08:46:12PM +0000, Karen O'Donoghue wrote:
>> Folks,
>>
>> This message initiates a three plus week working group last call for:
>>
>> Network Time Security for the Network Time Protocol
>> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
>
> I support advancing this document. It's well written and it secures
> the most important mode of NTP - client-server.
>
> From an implementor's point of view, I'd prefer if TLS 1.3 was
> required, but I don't know much about TLS or crypto in general.

Martin also expressed preferences of TLS 1.3. See my reply to his email.

>
> I still think it would be good to specify the maximum length of the
> cookie. This would simplify the client implementation. From a previous
> discussion, it looks like 256 octets should be enough.

The cookie contained in the Cookie EF is implementation specific.
Therefore in my opinion the size should not be specified, although
it might simplify implementation.

>
> In 5.2 there is "Possibly, some additional extension fields which are
> neither encrypted nor authenticated.  These are discarded by the
> receiver." I'd suggest to change the last sentence to "These are
> normally discarded by the receiver". This is explained later in the
> document for both client and server sides.

I see. I would like to phrase it „In general, these are discarded by
the receiver.“ in order to emphasize the normal behavior.

>
> In 5.6 there are two instances "zero-padded to a word (four octets)
> boundary" and two instances of "bytes". The size of a word and byte is
> specific to the architecture, so just use "to a four-octet boundary"
> and "octets".

Thanks. I replaced the bytes by octets.
>
> In 5.7 there are typos in "but MUST be encrypted from sent from
> server to client." and "comply with RFC 5095, Section 7.4".

Thanks.
>
> In 5.7 there is "In that case, it MUST be able to detect and stop
> looping between the NTS-KE and NTP servers.". This could be explained
> in a more detail. The detection here means that the client should
> check if there were no good NTP packets received between NTS-KE
> exchanges?
>
> -- 
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp