Subject: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-using-nts-for-ntp-23: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 07:00:15 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-ntp-using-nts-for-ntp-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It is easy to read (and this is
important) and it has multiple implementations. Section 9.4 "Initial
Verification of Server Certificates" is indeed a real chicken and egg issue and
quite classical. I am also trusting the security AD and SECDIR for the security
aspects of the protocol.

Please find below some non-blocking COMMENTs and NITs. An answer will be
appreciated though ;-)

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --
Authentication is of course a desirable property but I would have assumed that
the time accuracy is even more important. A shift in time -- even minor -- by
one compromised party would even be more important.

-- Section 1.2 --
Does NTP have a "a broadcast mode" or "a multicast mode" ? Notably as the
former does not exist for IPv6 ;-)

Is it really true that "it is harmless for stateless servers to process
replayed packets" as it will have an impact on the server CPU even if
stateless. Obviously, a DoS on a stateless server is less effective but writing
"harmless" is too strong IMHO.

In Figure 1, should there be a comma between "Shared cookie" and "encryption
parameters" between NTS-KE & NTP servers ?

-- Section 3 --
I really wonder why TLS 1.3 is not a MUST (e.g., AFAIK TLS 1.3 is supported by
openssl) but I will trust the security AD on this topic.

-- Section 4 --
What was the reasoning behind the decision of not using a simple REST API here?
This exchange is executed once, so, the overhead is not really important.

-- Section 4.1 --
Is there a specific order for the record? (except for the 'end of message') ?

-- Section 4.1.1. --
What is the expected behavior of the NTS-KE client/server when this record is
not the last one or is missing?

-- Section 4.1.3 & 4.1.4 --
Should there be a IANA registry for those error / warning codes? Esp if the
record type can be extended via IANA registry so new error / warning case will
be required ?

-- Section 4.1.7 --
While I am a little surprised to see IPv4/IPv6 addresses transmitted as ASCII
strings, please also refer to RFC 5952 for the canonical representation of an
IPv6 address.

The sentence "If a label contains at least one non-ASCII character, ..."
probably applies to the FQDN but it would be clearer to say so.

Should the FQDN be terminated by a final dot ?

What is the expected behavior of the client when the FQDN has several IPv4 and
several IPv6 addresses ?

Is it expected that the FQDN of the NTP servers can resolve to several IP
addresses based on availability, load balancing, or client mobility ? If so,
how are cookies synchronized? Else, let's be specific in the document.

== NITS ==

-- Section 7.6 --
The table will gain clarity by adding an empty line between entries.

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 13 Mar 2020 04:12:41 +0100

Hello Éric,

Thanks for your review and your useful comments!

> On 10 Mar 2020, at 15:00, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

Indeed!

I have now suggested this addition (in a GitHub “issue”):
"Time accuracy: The encryption and authentication used when actually
transferring time can be relatively lightweight, for performance,
and predictable, for time accuracy."

> former does not exist for IPv6 ;-)

Yes, and you are right, “broadcast mode” will not work with IPv6.

> "harmless" is too strong IMHO.

(There is a separate thread about this.)

> parameters" between NTS-KE & NTP servers ?

It should, thanks! (GitHub “issue” opened.)

> openssl) but I will trust the security AD on this topic.

(There is a separate thread about this.)

> This exchange is executed once, so, the overhead is not really important.

The protocol is modelled as other NTP extensions.

As a side note:
With some luck, there will normally be little load on the KE server.
After e.g. an outage, or during the attack, the KE server may have problems keeping up, mainly due to asymmetric crypto rather than the exact data packaging format though.

> Is there a specific order for the record? (except for the 'end of message') ?

No, there isn’t.

> not the last one or is missing?

The server MUST time out of there is none (4.1.3).
The client should probably do the same, but without sending an error as the server MUST.
We have considered this to be more implementation related.

If it is in the wrong place, the recipient will likely only see the records before the End of Message record.

> record type can be extended via IANA registry so new error / warning case will

Yes, see 7.8.

> strings, please also refer to RFC 5952 for the canonical representation of an

Thanks! (GitHub “issue” opened.)

> probably applies to the FQDN but it would be clearer to say so.

Thanks! (GitHub “issue” opened.)

> Should the FQDN be terminated by a final dot ?

Probably! (GitHub “issue” opened.)

> What is the expected behavior of the client when the FQDN has several IPv4 and

The traditional NTP behaviour is to pick any of them (probably the first, and let DNS handle the round robin).

> how are cookies synchronized? Else, let's be specific in the document.

We consider everything about the synchronisation of whatever is needed to generate and interpret cookies, likely some encryption keys but could be something else, to be an implementation specific detail.

> The table will gain clarity by adding an empty line between entries.

Thanks! (GitHub “issue” opened.)

Best regards,

Ragnar

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 13 Mar 2020 08:10:14 +0000

Ragnar,

Thank you for the time taken to answer my questions.

Happy to see the quality of the document being improved

Regards

-éric

-----Original Message-----
From: Ragnar Sundblad <[email-masked]>
Date: Friday, 13 March 2020 at 04:12
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Karen O'Donoghue <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-using-nts-for-ntp-23: (with COMMENT)

    Hello Éric,

    
    Indeed!

    

    

    

    
    As a side note:

    No, there isn’t.

    

    Yes, see 7.8.

    

    

    

    
    
    Best regards,
    
    Ragnar

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 18 Mar 2020 14:19:59 -0400

> On Mar 12, 2020, at 11:12 PM, Ragnar Sundblad <[email-masked]> wrote:
> 
>> 

Really?  I think the shared cookie is communicated by the NTS-KE server to the client and by the client to the NTP server, it is not OOB betw NTS-KE server and NTP server.  I thought this meant the encryption parameters on which the shared cookie is based.  Like the encryption keys, of course.  So something like “shared cookie’s encryption parameters”.

> We consider everything about the synchronisation of whatever is needed to generate and interpret cookies, likely some encryption keys but could be something else, to be an implementation specific d…

One of my comments was that there seemed to be several things the NTS-KE server needed to know about the NTP server(s) and that IMHO it would be good to list them so the implementers knew what was going to need negotiation/synchronization betw NTS-KE server and NTP server.

—Sandy

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 19 Mar 2020 06:52:32 -0400

I forgot to add - the response to Eric's comment is that it is implementation dependent.  I disagree.  HOW the synchronization occurs could be implementation dependent, but what needs to be synchronized is not.  Unless you believe that there might be an implementation of NTS-KE that does not need to agree with its NTP servers on anything, i.e., not crypto algs or encryption keys.

—Sandy

> On Mar 18, 2020, at 2:19 PM, Sandra Murphy <[email-masked]> wrote:
> 
>> 
>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Mar 2020 11:03:47 +0000

Thank you Sandy for getting straight to my point __

-----Original Message-----
From: Sandra Murphy <[email-masked]>
Date: Thursday, 19 March 2020 at 11:52
To: Sandra Murphy <[email-masked]>
Cc: Ragnar Sundblad <[email-masked]>, Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Karen O'Donoghue <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ntp]  Éric Vyncke's No Objection on draft-ietf-ntp-using-nts-for-ntp-23: (with COMMENT)

    —Sandy

---

From: Hal Murray <[email-masked]>
Date: Thu, 19 Mar 2020 04:50:22 -0700

[email-masked] said:
> One of my comments was that there seemed to be several things the NTS-KE
> server needed to know about the NTP server(s) and that IMHO it would be good
> to list them so the implementers knew what was going to need negotiation/
> synchronization betw NTS-KE server and NTP server.

You can figure out what the NTS-KE server needs to know by scanning the list 
of record types used to send information back to the NTS-KE client.  From the 
Table of Contents:

4.1. NTS-KE Record Types . . . . . . . . . . . . . . . . . . .
  4.1.1. End of Message . . . . . . . . . . . . . . . . . . .
  4.1.2. NTS Next Protocol Negotiation . . . . . . . . . . . .
  4.1.3. Error . . . . . . . . . . . . . . . . . . . . . . . .
  4.1.4. Warning . . . . . . . . . . . . . . . . . . . . . . .
  4.1.5. AEAD Algorithm Negotiation . . . . . . . . . . . . .
  4.1.6. New Cookie for NTPv4 . . . . . . . . . . . . . . . .
  4.1.7. NTPv4 Server Negotiation . . . . . . . . . . . . . .
  4.1.8. NTPv4 Port Negotiation . .

The first 4 are do not involve the NTP server.

So the list is:
  IP Address and port
  AEAD algorithim to be used on the wire between NTP client and server
  Cookies

The NTS-KE server doesn't need to know anything about the contents of the cookies.  It could open a (secure) back door connection to the NTP server and ask for some.  That's pretty simple if the NTS-KE server is co-located with the NTP server.

-- 
These are my opinions.  I hate spam.

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 19 Mar 2020 19:14:04 +0100

Hi Éric!

Thank you for your work in reviewing the draft. Ragnar has previously
replied to some of your points. This reply should address the remaining
comments.

Kind regards,
Marcus Dansarie

> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Section 1.1. of the draft has been updated in response to this comment.

> parameters" between NTS-KE & NTP servers ?

The text refers to the fact that the NTS-KE server and NTP servers share
the parameters required for cookie encryption and decryption, NOT that
they share a cookie (which they don't).

> strings, please also refer to RFC 5952 for the canonical representation of an

We are concerned that changing this could cause problems for
implementations in embedded devices and other "small" systems.

> probably applies to the FQDN but it would be clearer to say so.

Section 4.1.7. has been updated in response to your comment.

> Should the FQDN be terminated by a final dot ?

Section 4.1.7. has been updated in response to your comment.

> The table will gain clarity by adding an empty line between entries.

This will likely be resolved when the RFC Editor updates the table with
the correct values.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Mar 2020 22:51:43 +0000

Thank you Marcus for your reply

About section 4.1.7, using RFC 5952 to use the common format for IPv6 address would be a real and easy improvement.

Regards

-éric

-----Original Message-----
From: iesg <[email-masked]> on behalf of Marcus Dansarie <[email-masked]>
Date: Thursday, 19 March 2020 at 19:14
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, Karen O'Donoghue <[email-masked]>, <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-using-nts-for-ntp-23: (with COMMENT)

    Hi Éric!

    Kind regards,
    Marcus Dansarie

---

From: Ragnar Sundblad <[email-masked]>
Date: Fri, 20 Mar 2020 00:37:19 +0100

Hello Éric,

(Please note that these are only my questions/comments, the other authors have not be asked or informed.)

Regarding RFC 5952, it makes it addresses easier for humans to read, but may also be a thing that does not exist on e.g. embedded systems, and so would have to be implemented on those just to get NTS going.

Since these addresses are not meant to be read by humans we see no gain in requiring it, but it would mean extra work for some implementors, which would not help the adoption of the protocol.

Best regards,

Ragnar

On 19 Mar 2020, at 23:51, Eric Vyncke (evyncke) <evyncke=[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp