Subject: [Ntp] BCP 195

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Aug 2018 13:46:50 -0400

I just learned (by reading draft-moriarty-tls-oldversions-diediedie)
that BCP 195 exists, which gives best current practices for secure use
of TLS. I'm going to rewrite the "TLS Profile for Network Time
Security" as primarily a mandate to comply with that BCP. It'll go on
to turn a couple of its SHOULDs into MUSTs where the BCP makes more
allowances for legacy compatibility than we need to.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 28 Aug 2018 14:06:05 -0400

How's this?

    <section title="TLS profile for Network Time Security" anchor="tls-profile">
      <t>
        Network Time Security makes use of TLS for NTS key establishment.
      </t>
      <t>
        Since securing time protocols is (as of 2018) a novel
        application of TLS, no backward-compatibility concerns exist
        to justify using obsolete, insecure, or otherwise broken TLS
        features or versions. Implementations MUST conform with <xref
        target="RFC7525"/> or with a later revision of BCP
        195. Furthermore:
      </t>
      <t>
        Implementations MUST NOT negotiate TLS versions earlier than
        1.2, SHOULD negotiate TLS 1.3 <xref target="RFC8446"/> or
        later when possible, and MAY refuse to negotiate any TLS
        version which has been superseded by a later supported
        version.
      </t>
      <t>
        Use of the <xref target="RFC7301">Application-Layer Protocol
        Negotiation Extension</xref> is integral to NTS and support for
        it is REQUIRED for interoperability.
      </t>
    </section>

---

From: [email-masked]
Date: Tue, 28 Aug 2018 20:28:11 +0200

This is fine with me.

-----"ntp" <[email-masked]> wrote: -----

>To: [email-masked]
>From: "Daniel Franke" 
>Sent by: "ntp" 
>Date: 08/28/2018 20:06
>Subject: Re: [Ntp] BCP 195
>
>How's this?
>
>> I just learned (by reading
>draft-moriarty-tls-oldversions-diediedie)
>_______________________________________________
>ntp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 28 Aug 2018 22:14:31 +0200

Good observation on BCP 195! I'm in favor of this.

The second paragraph is particularly diplomatic in view of the slightly
differing views on whether we should require TLS 1.2 or 1.3. My only
objection is that "when possible" is redundant in view of the RFC 2119
definition of SHOULD.

Kind regards,
Marcus Dansarie

---

From: [email-masked]
Date: Wed, 29 Aug 2018 08:08:14 +0200

"ntp" <[email-masked]> schrieb am 28.08.2018 22:14:31:

> Von: "Marcus Dansarie" <[email-masked]>
> An: [email-masked]
> Datum: 28.08.2018 22:15
> Betreff: Re: [Ntp] BCP 195
> Gesendet von: "ntp" <[email-masked]>
> 

I disagree with your objection. 
The language in RFC 2119 to me seems to explicitly leave room for a 
deliberate decision (weighing implications), not just (im)possibility due 
to cirmustance.
 
> >         it is REQUIRED for interoperability.

I like it.

> [Anhang "signature.asc" gelöscht von Kristof Teichel/PTB]

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 Aug 2018 08:32:58 +0200

>>> Daniel Franke <[email-masked]> schrieb am 28.08.2018 um 20:06 in
Nachricht
<CAJm83bAS2_m=[email-masked]>:
> How's this?
> 
>     <section title="TLS profile for Network Time Security" 
> anchor="tls‑profile">
>       <t>
>         application of TLS, no backward‑compatibility concerns exist

Isn't that too much words? "MUST negotiate TLS 1.3 or later" should say all of
the above. Specifically the "MAY refuse" is redundant, because the protocol is
"negotiated" already.
Making specificatiions about future protocols is not really helpful IMHO.

Regards,
Ulrich

>       </t>
>       <t>
>         Use of the <xref target="RFC7301">Application‑Layer Protocol
>> I just learned (by reading draft‑moriarty‑tls‑oldversions‑diediedie)

---

From: [email-masked]
Date: Wed, 29 Aug 2018 09:25:36 +0200

"ntp" <[email-masked]> schrieb am 29.08.2018 08:32:58:

> Von: "Ulrich Windl" <[email-masked]>
> An: "Daniel Franke" <[email-masked]>, "[email-masked]" 
<[email-masked]>
> Datum: 29.08.2018 08:33
> Betreff: [Ntp] Antw: Re:  BCP 195
> > anchor="tls?profile">
> >         application of TLS, no backward?compatibility concerns exist

I believe it is the right amount of words, specifically for the question 
of TLS 1.2 vs 1.3.
The given suggestion completely excludes TLS 1.2, which I think is a bit 
premature.
On the other hand, the "MAY refuse" clause seems to me like it's not so 
much about future protocols, but about the option to refuse 1.2 in case 
1.3 is supported (which I think is a great way to handle these versions).

As an aside: does anyone here know the exact way in which "negotiate" is 
supposed to be used?
What I mean is: does it describe 
  1) what one given device offers, or 
  2) what two (or more) devices agree on after some negotiation phase?

I bring this up because in Ulrich's suggestion, the words "MUST 
negotiate..." rubbed me the wrong way.
I read them as excluding the option for negotiations to fail (which should 
definitely be an option).
Also, neither participant (alone) can really ensure this result, which 
makes it seem like one should not try to mandate it.

In BCP 195, I see "negotiate" only used in language that supports 
interpretation 2) and is consistent with only mandating things that one 
single participant can actually influence:
  - "MUST NOT negotiate x" (either participant can ensure this by not 
offering/supporting x)
  - "SHOULD NOT negotiate x" (as above)
  - "MUST support x" (local to each participant)
  - "MUST prefer to negotiate x" (again, local to each participant)
Never is it "MUST negotiate x" or even "SHOULD negotiate x".

This makes me wonder if, in Daniel's suggestion, the words "SHOULD 
negotiate TLS 1.3" should be changed to "SHOULD prefer to negotiate TLS 
1.3".
I don't believe it is as important in a "SHOULD" clause.
Still: mandates (even weak ones) should probably only be made on things 
that each participant on its own can actually influence.
What do you think?

> Regards,
> Ulrich
> 
> >       </t>
> >       <t>
> >         Use of the <xref target="RFC7301">Application?Layer Protocol
draft?moriarty?tls?oldversions?diediedie)

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 29 Aug 2018 09:52:06 +0200

>>> <[email-masked]> schrieb am 29.08.2018 um 09:25 in Nachricht
<[email-masked]>:
> "ntp" <ntp‑[email-masked]> schrieb am 29.08.2018 08:32:58:
> 
>> Von: "Ulrich Windl" <[email-masked]‑regensburg.de>
>> Gesendet von: "ntp" <ntp‑[email-masked]>
>> 
>> <CAJm83bAS2_m=wLsCw1kss9+Dck7fXtZZE15wAhy_88D2w‑[email-masked]>:
>> > How's this?
>> > 

(Actually I had read Peter Gutmann's parody of an RFC (Grand Unified PKI
Protocol (GUPP), secion 3.1.1.1.1.1 "GUPP Signature" in particular) yesterday,
and that made me aware of the fact that too many words make the meaning less
clear that fwer words in many cases)

> The given suggestion completely excludes TLS 1.2, which I think is a bit 

It's a valid question whether one RFC should judge over the security of
another protocol, other than recommending to prefer the most secure one
(whatever that means).

> As an aside: does anyone here know the exact way in which "negotiate" is 

For me "negotiate" means both parties are seeking a common protocol.

>   1) what one given device offers, or 

Usually "offering" is a part of negotiation protocols.

>   2) what two (or more) devices agree on after some negotiation phase?

"negotiate" is the act of "negotiating" (work in progress), while
"negotiation" is the (successful) result of it. It's rather clear in my view of
things.

> definitely be an option).

If a negotiation fails, there is no common protocol to use, so no
communication (unless stated otherwise).

> makes it seem like one should not try to mandate it.

One party can ensure the result only in the way "either one of my offerings,
or nothing at all). Naturally, the wider the offering, the most likely a
negotiation succeeds, and the overall security suffers (DES & RC4 anyone?)

>   ‑ "MUST NOT negotiate x" (either participant can ensure this by not 
> offering/supporting x)
>   ‑ "SHOULD NOT negotiate x" (as above)
>   ‑ "MUST support x" (local to each participant)
>   ‑ "MUST prefer to negotiate x" (again, local to each participant)

If both parties have the option to select between multiple possibilities, it's
part of the specific protocol's negotiation mechanism if such a "prefer"
mechanism exists, and how it works. Again, I'd try to avoid specifying too much
how another protocol should work (preferences for TLS should be in the TLS
specification, nowhere else IMHO).

> negotiate TLS 1.3" should be changed to "SHOULD prefer to negotiate TLS 

I'd be generic, not describing a specific protocol version, but the security
requirements (integrity, confidentiality, non-repudiation, etc.) of it
instead.

> that each participant on its own can actually influence.

Do not forget that any party could implement TLS 1.3 in such a bad way that
it's less secure than TLS 1.2...

Regards,
Ulrich