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

From: Marcus Dansarie <[email-masked]>
Date: Thu, 13 Feb 2020 20:01:09 +0100

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.

---

From: Christer Weinigel <[email-masked]>
Date: Mon, 17 Feb 2020 11:07:58 +0100

> We agree. The draft has been updated accordingly.

I took a quick look at what some of the existing implementations do.

nts-poc-python and NTPsec both use OpenSSL and the function 
SSL_export_keying_material for extracting key material.  This function 
has two implementations, one for TLS1.3 which uses HKDF and another one 
for older versions of TLS which use PRF and OpenSSL will use the 
appropriate one automatically.

Chrony uses gnutls and the function gnutls_prf_rfc5705 for extracting 
key material.  Despite the name this function will use HKDF as defined 
in RFC8446 for TLS1.3 and PRF for older versions of TLS.

So all those implementations actually did the right thing already since 
the library they use did the right thing.

And since both the Netnod Go implementation and Cloudflare's Rust 
implementation can interoperate with the other implementations I guess 
they do the right thing too.

I.e. all implementations seem to do the right thing already.  Updating 
the documentation to match reality is a good thing to do. :)

   /Christer

---

From: [email-masked]
Date: Mon, 17 Feb 2020 11:14:18 +0100

Hey Christer,

thank you for following up on this issue, this is great confirmation to 
get.

Best regards,
Kristof

"ntp" <[email-masked]> schrieb am 17.02.2020 11:07:58:

> Von: "Christer Weinigel" <[email-masked]>
> An: "Marcus Dansarie" <[email-masked]>, [email-masked]
> Kopie: [email-masked], 
> "[email-masked]" <[email-masked]>, "Karen O'Donoghue" <[email-masked]>
> Datum: 17.02.2020 11:08
> Betreff: Re: [Ntp] AD Evaluation: draft-ietf-ntp-using-nts-for-ntp-21
> Gesendet von: "ntp" <[email-masked]>
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp