Re: [Ntp] AD Evaluation: draft-ietf-ntp-using-nts-for-ntp-21

kristof.teichel@ptb.de Mon, 17 February 2020 10:13 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 DAEB412081C; Mon, 17 Feb 2020 02:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 7tBBVdxqWX0Y; Mon, 17 Feb 2020 02:13:47 -0800 (PST)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A29712081A; Mon, 17 Feb 2020 02:13:46 -0800 (PST)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 01HADfqW012503-01HADfqY012503 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 17 Feb 2020 11:13:41 +0100
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id 2574E8F7B62; Mon, 17 Feb 2020 11:13:41 +0100 (CET)
In-Reply-To: <4012d870-f760-8ead-2aec-d84c8c7e9181@weinigel.se>
References: <AF4879A2-9F09-4A34-B4E5-3970B293A806@kaloom.com> <DM5PR06MB301806532F0CDAA81BB8D363C2180@DM5PR06MB3018.namprd06.prod.outlook.com> <DM5PR06MB301877557F3323309F8B8FFBC2180@DM5PR06MB3018.namprd06.prod.outlook.com> <cf868779-a4ed-36aa-4487-24da20e8298c@dansarie.se> <4012d870-f760-8ead-2aec-d84c8c7e9181@weinigel.se>
To: "Christer Weinigel" <christer@weinigel.se>
Cc: draft-ietf-ntp-using-nts-for-ntp.authors@ietf.org, "Marcus Dansarie" <marcus@dansarie.se>, "ntp@ietf.org" <ntp@ietf.org>, "ntp" <ntp-bounces@ietf.org>, "Karen O'Donoghue" <odonoghue@isoc.org>, Suresh@kaloom.com
MIME-Version: 1.0
Message-ID: <OF375E1883.C736A066-ONC1258511.0037F624-C1258511.00382F29@ptb.de>
From: kristof.teichel@ptb.de
Date: Mon, 17 Feb 2020 11:14:18 +0100
Content-Type: multipart/alternative; boundary="=_alternative 00382F28C1258511_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/A5FVASUQT6EyFFAvKQ4T2Hyg34g>
Subject: Re: [Ntp] AD Evaluation: draft-ietf-ntp-using-nts-for-ntp-21
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 Feb 2020 10:13:50 -0000

Hey Christer,

thank you for following up on this issue, this is great confirmation to 
get.


Best regards,
Kristof

"ntp" <ntp-bounces@ietf.org> schrieb am 17.02.2020 11:07:58:

> Von: "Christer Weinigel" <christer@weinigel.se>
> An: "Marcus Dansarie" <marcus@dansarie.se>se>, Suresh@kaloom.com
> Kopie: draft-ietf-ntp-using-nts-for-ntp.authors@ietf.org, 
> "ntp@ietf.org" <ntp@ietf.org>rg>, "Karen O'Donoghue" <odonoghue@isoc.org>
> Datum: 17.02.2020 11:08
> Betreff: Re: [Ntp] AD Evaluation: draft-ietf-ntp-using-nts-for-ntp-21
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> 
> On 2/13/20 8:01 PM, Marcus Dansarie wrote:
> 
> >> * Section 4.2. and 5.1.
> >>
> >> These sections seem to be mandating the use of RFC5705 for extracting
> >> key material while also putting in a SHOULD level requirement for TLS
> >> 1.3. In my view these are incompatible.
> >>
> >> As I was reading through the draft that became TLS 1.3 spec (RFC8446)
> >> one of the things it changed was the way key exporters work by 
changing
> >> from PRF to HKDF. It appears to me that this would make the RFC5705 
key
> >> extraction mechanisms incompatible with TLS1.3.
> >>
> >> If you agree that this is an issue, can you put in some 
disambiguating
> >> text in these sections to mention that RFC5705 has to be used with
> >> earlier TLS versions, and Section 7.5 of RFC8446 is to be used with 
TLS
> >> 1.3. If this is not an issue, can you please explain why?
> > 
> > We agree. The draft has been updated accordingly.
> 
> I took a quick look at what some of the existing implementations do.
> 
> nts-poc-python and NTPsec both use OpenSSL and the function 
> SSL_export_keying_material for extracting key material.  This function 
> has two implementations, one for TLS1.3 which uses HKDF and another one 
> for older versions of TLS which use PRF and OpenSSL will use the 
> appropriate one automatically.
> 
> Chrony uses gnutls and the function gnutls_prf_rfc5705 for extracting 
> key material.  Despite the name this function will use HKDF as defined 
> in RFC8446 for TLS1.3 and PRF for older versions of TLS.
> 
> So all those implementations actually did the right thing already since 
> the library they use did the right thing.
> 
> And since both the Netnod Go implementation and Cloudflare's Rust 
> implementation can interoperate with the other implementations I guess 
> they do the right thing too.
> 
> I.e. all implementations seem to do the right thing already.  Updating 
> the documentation to match reality is a good thing to do. :)
> 
>    /Christer
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp