Subject: [Ntp] NTS changelog since draft 9

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 13:02:48 -0400

I've pushed some changes to the NTS git repo addressing all (and only)
uncontroversial-looking feedback since last call. Summary of changes:

* Fix misuse of "ntp/4" as an NTS Next Protocol ID
* Fix remaining instances where DTLS-encapsulated NTPv4 was called
"NTS-encapsulated NTPv4"
* Rewrite the last two sentences regarding security considerations for
pool servers, eliminating an inaccurate statement about present lack
of monitoring.
* Add several clarifications suggested by Martin Langer
* Always refer to extension fields as such, not just "extensions"
* Reword "user error" as "configuration error"
* Fix the typo "symmetry" -> "symmetric"
* Update acknowledgements section (add Scott Fluhrer and fix a typo)

I'll post draft 10 on Friday morning, incorporating these changes
along with anything else uncontroversial that comes up before the end
of LC.

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 30 Aug 2017 17:09:58 +0000

Thank you Daniel. The summary is very helpful. 

And as a reminder to the rest of the working group, all the individual changes to the NTS spec are available publicly in the GitHub repository the authors are using for document development. 

https://github.com/dfoxfranke/nts

Regards,
Karen

> On Aug 30, 2017, at 1:02 PM, Daniel Franke <[email-masked]> wrote:
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 30 Aug 2017 17:09:58 +0000

Regards,
Karen

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Aug 2017 18:20:38 +0000

I have just finished reading this document.  I’ll try not to discuss things that have already been on the mailing list  But since it just came up while I was writing this email, I want to say I agree that all references to PTP should be removed (e.g. lines 65-69). I’ve avoided wordsmithing suggestions, and will make a PR for those if desired.

This is READY to be advanced and I strongly encourage it.  I have some questions and suggestions below, but if the answers are “no” that is okay with me.

We should not hold up this document for it, but QUIC is also using TLS-based key exchange. It’s likely to become extremely popular on the Internet, and a modified NTS-KE that “does what QUIC does” seem likely in a year or two.  If we can somehow call that out, in a reasonable way, that might be worth doing.

NTS-KE straddles NTP and TLS so the “artwork” could go either way.  I don’t know if the TLS presentation language was considered, or CBOR.  JSON protobufs and ASN1/DER should not be considered.

Everyone likes to write a framing protocol these days ☺  Can we reuse H2 or, again TLS?

Perhaps NTS NPN, like TLS NPN, should be renamed to be like ALPN.

Line 354; if you get an error and do not advance, what state are you in?  Perhaps a state/ladder diagram would be helpful.

Line 614, it doesn’t seem right to say that you must not attempt to interpret cookies and then intend to provide a recommended construction.  Delete the recommendation.

Did I miss a part where the cookie length is defined?  Without that, how does the Placeholder work?  And the length of the placeholder indirectly indicates the number of cookies the client wants?  What if the server wants to give fewer (or none).  OOHHH, the client repeats the extension for # of cookies it wants.  That should be made more clear. If the value of the extension is to be ignored, just require it to be all zero’s.

Line 682ff Is it useful to have a ref that describes what K A P N mean?

718 Missing word before MUST NOT

Change the recommended format for NTS cookies to be a non-normative appendix and call it possible format.

Given that many readers here not crypto experts, consider more descriptive language than “uniformly random” and such for nonce text.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Aug 2017 18:20:38 +0000

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 15:31:54 -0400

On 8/30/17, Salz, Rich <[email-masked]> wrote:
> We should not hold up this document for it, but QUIC is also using TLS-based
> key exchange. It’s likely to become extremely popular on the Internet, and a
> modified NTS-KE that “does what QUIC does” seem likely in a year or two.  If
> we can somehow call that out, in a reasonable way, that might be worth
> doing.

Put any sort of intelligent discussion of such a thing into the NTS
doc would call for citing QUIC RFCs, which aren't published yet and
would therefore hold up NTS. As far as the merits go, I'm not sure I
understand what you're proposing well enough to comment. Do you just
mean running NTS-KE over QUIC rather than over TLS/TCP?

> NTS-KE straddles NTP and TLS so the “artwork” could go either way.  I don’t
> know if the TLS presentation language was considered, or CBOR.  JSON
> protobufs and ASN1/DER should not be considered.
>

I tried taking the WG's temperature on this a year ago. The consensus
seemed to be: 1. Good riddance to ASN.1; 2. nobody was sufficiently
unhappy with my simple ad-hoc framing to propose a concrete
alternative. If you'd suggested something a month ago I'd welcome PRs,
but now that we're in LC I'm hesitant to make this sort of change
without a compelling reason.

> Perhaps NTS NPN, like TLS NPN, should be renamed to be like ALPN.

NTS-KE is already at the application layer, so that name seems
misleading in this case.

> Line 354; if you get an error and do not advance, what state are you in?
> Perhaps a state/ladder diagram would be helpful.

I can't figure out what document version/format this line number is in
reference to, but I think you're referring to something in section 4?
PR welcome.

> Line 614, it doesn’t seem right to say that you must not attempt to
> interpret cookies and then intend to provide a recommended construction.
> Delete the recommendation.
>

I think this section is pretty important for understanding how the
protocol is supposed to work, and don't want to relegate it to an
appendix. Would adding an explicit "This section is non-normative" be
sufficient?

> Did I miss a part where the cookie length is defined?  Without that, how
> does the Placeholder work?  And the length of the placeholder indirectly
> indicates the number of cookies the client wants?  What if the server wants
> to give fewer (or none).  OOHHH, the client repeats the extension for # of
> cookies it wants.  That should be made more clear. If the value of the
> extension is to be ignored, just require it to be all zero’s.

Can you send a PR for this?

> Line 682ff Is it useful to have a ref that describes what K A P N mean?

It's RFC 5116. I'll put an additional reference to it there for clarity.

> 718 Missing word before MUST NOT

I'm again having trouble resolving your line numbers. I can't figure
out what you're pointing at here.

> Given that many readers here not crypto experts, consider more descriptive
> language than “uniformly random” and such for nonce text.

Can you suggest a better phrase? ISTM that "random" will by itself be
properly understood by average readers, and adding "uniformly" should
satisfy mathematical pedants like me.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 15:31:54 -0400

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Aug 2017 19:56:22 +0000

Like I said, I am fine if the answer is “too late” or “no” to all the points.

    reference to

github master as of this morning ☺

I disagree.  It might be useful to understanding but it is just a recommendation and non-normative.  But see my opening comment.

  
Will do.

Github master as of this morning.

    
See figure one ☺

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 Aug 2017 19:56:22 +0000

Will do.

    

See figure one ☺

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 08:55:54 +1000

On 31/08/17 05:31, Daniel Franke wrote:
>> ...

Until I had spent some time with section 7 and RFC 5116, I found the
cookie management rather perplexing.  But now that I've read through it
a few times, I think the way cookies are formed and used is vital to how
NTS is expected to work in practice, and if anything I think it should
be more strongly mandated rather than less (i.e. SHOULD rather than
OPTIONAL).

Giving protocols a toolkit to do crypto in a standardised and abstracted
way is one of the primary goals of RFC 5116, and it seems to me that
making the cookie format optional is an opportunity for NTS to end up
with bad crypto implementations.

This leads me to some questions for Rich: Why do you think it's
important that the current cookie format be non-normative?  Do you have
in mind an alternate cookie formation process?  Or are you aware of some
circumstances where the current recommendation would be undesirable or
unworkable?  (Apologies if this should be obvious, but it's not obvious
to me at present.  I think documenting assumptions is valuable for those
of us without a long history in the standardisation process.)

>> extension is to be ignored, just require it to be all zero’s.

Saying that cookie placeholders SHOULD be all zero is a good idea.  It
looks Daniel has changed this in draft-dfranke-nts.xml in git master,
but not in draft-ietf-ntp-using-nts-for-ntp.xml.  (I'm not sure whether
this is intentional.)

However, I don't recall seeing any language specifying whether all
cookies sent by a server must be the same in length.  If, for example,
a server's software version were upgraded to support a new AEAD suite
between a client's polls, then conceivably the next cookie could be
slightly shorter or longer.  So perhaps the wording should be: "... the
body length of the NTS Cookie Placeholder extension MUST be the same as
the body length of [the] NTS Cookie [e]xtension [most recently] received
from the server."

(As an aside: in this scenario, if the new suite required a longer
cookie than the placeholder sent by the client, presumably a NAK and an
NTS-KE renegotiation would be required. For servers with large numbers
of clients, this might be problematic.)

Regards,
Paul

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 08:55:54 +1000

Regards,
Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:26:49 +0000

On 8/30/17, 8:15 PM, "Salz, Rich" <[email-masked]> wrote:

    The draft says “clients CANNOT” depend on the format.  That implies to me, pretty clearly, that the description is not normative.
    
    For a single shared-memory system, why can’t the cookie be a virtual memory address?  Why can’t it be a database key?
    
        However, I don't recall seeing any language specifying whether all
        cookies sent by a server must be the same in length. 
    
    Good catch!

    +1

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:26:49 +0000

Good catch!

    +1

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 11:32:20 +1000

>     The draft says “clients CANNOT” depend on the format.  That implies to me, pretty clearly, that the description is not normative.

The cookie format described in the draft clearly says that clients
aren't to depend on it, but it's absolutely vital that the server
understand it, because it contains the keys necessary to decrypt and
validate the client request.

>     For a single shared-memory system, why can’t the cookie be a virtual memory address?  Why can’t it be a database key?

Because that's storing state on the server - the point of the cookie is
to offload the session state storage (including all necessary keys) to
the client.

Regards,
Paul

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 11:32:20 +1000

Regards,
Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:39:06 +0000

➢ The cookie format described in the draft clearly says that clients
    aren't to depend on it, but it's absolutely vital that the server
    understand it, because it contains the keys necessary to decrypt and
    validate the client request.
    
Well yeah, of course ☺

➢     Because that's storing state on the server - the point of the cookie is
    to offload the session state storage (including all necessary keys) to
    the client.
    
If my server chose to do that, how would anyone know?  How could anyone care?

Describing one possible cookie format, in a cryptographically-strong way, is a good thing.  But the RFC really shouldn’t do anything other than say “here’s something you can use”  As an Appendix.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:39:06 +0000

Well yeah, of course ☺

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 11:54:15 +1000

> Delete the recommendation.

The draft doesn't say that "you" must not attempt to interpret cookies. 
It says clients must not.  And then section 7 provides a recommended way
for servers to interpret them.  This seems completely valid and
expected.  So I'm not seeing your point about why it should be deleted. 
Apologies if I'm being thick.

> If my server chose to do that, how would anyone know?  How could anyone care?

That's why it should be RECOMMENDED rather than REQUIRED.

> Describing one possible cookie format, in a cryptographically-strong way, is a good thing.  But the RFC really shouldn’t do anything other than say “here’s something you can use”  As an Appendix.

I think the same principle applies here which was discussed recently in
the thread about client data minimisation: each protocol standard should
do its part (however small) to ensure cryptographically strong behaviour
by default.  If there are good reasons for overriding this behaviour,
then implementations should be able to do so, but that's well within the
guidelines for RECOMMENDED and in my opinion doesn't warrant deleting
the recommendation or moving such a vital piece of the scalability story
for NTS to an appendix.

Paul

---

From: Paul Gear <[email-masked]>
Date: Thu, 31 Aug 2017 11:54:15 +1000

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:57:52 +0000

>> Delete the recommendation.

➢ The draft doesn't say that "you" must not attempt to interpret cookies.  It says clients must not.  And then section 7 provides a recommended way for servers to interpret them.  This seems completely valid and expected.  So I'm not seeing your point about why it should be deleted.  Apologies if I'm being thick.

Ah, I meant delete the word “recommended”  Downgrade it to “one possible”  It should be not normative, and it should offer a suggestion for a good way to do things.  I am sorry for the misleading comment. The text on one way to do cookies is good, and useful for those we might not have a good knowledge of crypto.  It should stay, just downgraded to an appendix.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 01:57:52 +0000

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 22:10:36 -0400

On Aug 30, 2017 9:58 PM, "Salz, Rich" <[email-masked]> wrote:

Ah, I meant delete the word “recommended”  Downgrade it to “one possible”
It should be not normative, and it should offer a suggestion for a good way
to do things.  I am sorry for the misleading comment. The text on one way
to do cookies is good, and useful for those we might not have a good
knowledge of crypto.  It should stay, just downgraded to an appendix.

See what you think of the current git head. I've removed all RFC 2119
language concerning cookie format and made an explicit "non-normative"
statement. Still keeping it where it is rather than move it to an appendix,
though.
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Daniel Franke <[email-masked]>
Date: Wed, 30 Aug 2017 22:10:36 -0400

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 03:00:17 +0000

Looks good, thanks!

From: Daniel Franke <[email-masked]>
Date: Wednesday, August 30, 2017 at 10:10 PM
To: Rich Salz <[email-masked]>
Cc: Paul Gear <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ntp] NTS changelog since draft 9

On Aug 30, 2017 9:58 PM, "Salz, Rich" <[email-masked]<mailto:[email-masked]>> wrote:

See what you think of the current git head. I've removed all RFC 2119 language concerning cookie format and made an explicit "non-normative" statement. Still keeping it where it is rather than move it to an appendix, though.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Aug 2017 03:00:17 +0000

Looks good, thanks!