[Ntp] Antw: Re: Antw: Re: BCP 195

["Ulrich Windl" <[e-mail]>]

>>> <[e-mail]> schrieb am 29.08.2018 um 09:25 in Nachricht
<[e-mail]>:
> "ntp" <ntp‑[e-mail]> schrieb am 29.08.2018 08:32:58:
> 
>> Von: "Ulrich Windl" <[e-mail]‑regensburg.de>
>> An: "Daniel Franke" <[e-mail]>, "[e-mail]" 
> <[e-mail]>
>> Datum: 29.08.2018 08:33
>> Betreff: [Ntp] Antw: Re:  BCP 195
>> Gesendet von: "ntp" <ntp‑[e-mail]>
>> 
>> >>> Daniel Franke <[e-mail]> schrieb am 28.08.2018 um 20:06 
> in
>> Nachricht
>> <CAJm83bAS2_m=wLsCw1kss9+Dck7fXtZZE15wAhy_88D2w‑[e-mail]>:
>> > 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.
>> 
>> 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.
> 
> I believe it is the right amount of words, specifically for the question 
> of TLS 1.2 vs 1.3.

(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 
> premature.

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).

> 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?

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

> What I mean is: does it describe 
>   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.

> 
> 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).

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

> Also, neither participant (alone) can really ensure this result, which 
> 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?)

> 
> 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".

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).

> 
> 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'd be generic, not describing a specific protocol version, but the security
requirements (integrity, confidentiality, non-repudiation, etc.) of it
instead.

> 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.

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...

> What do you think?

Regards,
Ulrich

> 
>> Regards,
>> Ulrich
>> 
>> >       </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>
>> > On Tue, Aug 28, 2018 at 1:46 PM Daniel Franke <[e-mail]> 
> wrote:
>> >>
>> >> 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.
>> > 
>> > _______________________________________________
>> > ntp mailing list
>> > [e-mail] 
>> > https://www.ietf.org/mailman/listinfo/ntp 
>> 
>> 
>> 
>> _______________________________________________
>> ntp mailing list
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ntp