Re: [Ntp] Antw: Re: BCP 195

"ntp" <ntp-bounces@ietf.org> schrieb am 29.08.2018 08:32:58:

> Von: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> An: "Daniel Franke" <dfoxfranke@gmail.com>, "ntp@ietf.org" 
<ntp@ietf.org>
> Datum: 29.08.2018 08:33
> Betreff: [Ntp] Antw: Re:  BCP 195
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> 
> >>> Daniel Franke <dfoxfranke@gmail.com> schrieb am 28.08.2018 um 20:06 
in
> Nachricht
> <CAJm83bAS2_m=wLsCw1kss9+Dck7fXtZZE15wAhy_88D2w-HxGA@mail.gmail.com>:
> > 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.
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
> >         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 <dfoxfranke@gmail.com> 
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
> > ntp@ietf.org 
> > https://www.ietf.org/mailman/listinfo/ntp 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp