Re: [Ntp] BCP 195

kristof.teichel@ptb.de Wed, 29 August 2018 06:09 UTC

Return-Path: <kristof.teichel@ptb.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEBD130DC6 for <ntp@ietfa.amsl.com>; Tue, 28 Aug 2018 23:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NlUrvjnl3lF for <ntp@ietfa.amsl.com>; Tue, 28 Aug 2018 23:09:19 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA47126F72 for <ntp@ietf.org>; Tue, 28 Aug 2018 23:09:19 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id w7T68Fpx029499-w7T68Fq1029499 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2018 08:08:15 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id BB0986C29BC; Wed, 29 Aug 2018 08:08:15 +0200 (CEST)
In-Reply-To: <e4861a64-c6e4-be78-f6fc-2281f035360c@dansarie.se>
References: <CAJm83bBsmKB14-dXGFXRMHXMOtwfogqDe8Vz54dJKOAL1N24NA@mail.gmail.com> <CAJm83bAS2_m=wLsCw1kss9+Dck7fXtZZE15wAhy_88D2w-HxGA@mail.gmail.com> <e4861a64-c6e4-be78-f6fc-2281f035360c@dansarie.se>
To: Marcus Dansarie <marcus@dansarie.se>
Cc: ntp@ietf.org
MIME-Version: 1.0
Message-ID: <OF308DFBAB.666C23BB-ONC12582F8.0020FA1A-C12582F8.0021B68B@ptb.de>
From: kristof.teichel@ptb.de
Date: Wed, 29 Aug 2018 08:08:14 +0200
Content-Type: multipart/alternative; boundary="=_alternative 0021B68BC12582F8_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/etqfF1ZcRWfllXMS7uD3jG4nJyA>
Subject: Re: [Ntp] BCP 195
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 06:09:23 -0000

"ntp" <ntp-bounces@ietf.org> schrieb am 28.08.2018 22:14:31:

> Von: "Marcus Dansarie" <marcus@dansarie.se>
> An: ntp@ietf.org
> Datum: 28.08.2018 22:15
> Betreff: Re: [Ntp] BCP 195
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> 
> 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.

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.
 
> Kind regards,
> Marcus Dansarie
> 
> On 2018-08-28 20:06, Daniel Franke wrote:
> > 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>

I like it.

> > 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
> > 
> 
> [Anhang "signature.asc" gelöscht von Kristof Teichel/PTB] 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp