Re: [Ntp] AD Evaluation: draft-ietf-ntp-using-nts-for-ntp-21

[Marcus Dansarie <[e-mail]>]

Suresh,

Thank you for your thorough review of the NTS draft. Changes that
address the issues found have been incorporated in version 22 of the
draft, which was just submitted. Our replies to your individual comments
follow inline below. The comments and changes represent a consensus
among the authors, except for Daniel Franke whom we haven't been able to
reach. In the interest of time, we have decided to submit a new draft
despite this.

Kind regards,
Marcus Dansarie


> Major:
> =====
> 
> * Section 4.2. and 5.1.
> 
> These sections seem to be mandating the use of RFC5705 for extracting
> key material while also putting in a SHOULD level requirement for TLS
> 1.3. In my view these are incompatible.
> 
> As I was reading through the draft that became TLS 1.3 spec (RFC8446)
> one of the things it changed was the way key exporters work by changing
> from PRF to HKDF. It appears to me that this would make the RFC5705 key
> extraction mechanisms incompatible with TLS1.3.
> 
> If you agree that this is an issue, can you put in some disambiguating
> text in these sections to mention that RFC5705 has to be used with
> earlier TLS versions, and Section 7.5 of RFC8446 is to be used with TLS
> 1.3. If this is not an issue, can you please explain why?

We agree. The draft has been updated accordingly.

> Minor:
> =====
> 
> Section 2:
> 
> "The Network Time Protocol includes many different operating modes to
>    support various network topologies”
> 
> I think a pointer to Section 3 of RFC5905 could be useful here.

We agree. The draft has been updated accordingly.

> Section 5.7:
> 
> I think it would be preferable to remove the following text
> 
> " and is in practice also safe for avoiding IPv4 fragmentation"
> 
> from the sentence beginning with “1280 octets…” as IPv4 hosts are only
> required to accept packets up to 576 bytes long as per RFC1122.

You are correct in that RFC 1122 allows packets as short as 576 bytes.
What we are saying in Section 5.7 is, however, that a maximum length of
1280 bytes will avoid fragmentation in the vast majority of real-world
cases. The wording in question is not normative and merely serves as a
design justification.

> Section 6:
> 
> Given that this section is non-normative consider this only as a
> suggestion from me (and feel free to ignore). RFC5077 has been obsoleted
> by the session resumption specified in Section 2.2 of RFC8446. Given
> that, is there something here you would like to change?

We have decided to leave the current wording as it is.

> Section 9 (Security Considerations):
> 
> I think it might be worth repeating here that NTS only protects the
> client-server mode of NTP. I am happy with the text in Section 1.2 and
> would not mind if it is summarized here.

We agree and have added a new subsection to the Security Considerations
incorporating your comments and referencing RFC 8573 as the best current
practice for authentication of NTP modes other than 3 and 4.