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

Christer Weinigel <christer@weinigel.se> Mon, 17 February 2020 10:08 UTC

Return-Path: <christer@weinigel.se>
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 7F3A512081A; Mon, 17 Feb 2020 02:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.482
X-Spam-Level:
X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ETI5O5JBS4Xa; Mon, 17 Feb 2020 02:08:03 -0800 (PST)
Received: from mail.weinigel.se (37-46-169-123.customers.ownit.se [37.46.169.123]) by ietfa.amsl.com (Postfix) with ESMTP id 82E111207FF; Mon, 17 Feb 2020 02:08:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zoo.weinigel.se (Postfix) with ESMTP id 78C3C1E0300; Mon, 17 Feb 2020 11:08:00 +0100 (CET)
Received: from mail.weinigel.se ([127.0.0.1]) by localhost (mail.weinigel.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceiN1EwYhZPH; Mon, 17 Feb 2020 11:07:58 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by zoo.weinigel.se (Postfix) with ESMTP id 4436D1E0146; Mon, 17 Feb 2020 11:07:58 +0100 (CET)
To: Marcus Dansarie <marcus@dansarie.se>, Suresh@kaloom.com
Cc: draft-ietf-ntp-using-nts-for-ntp.authors@ietf.org, "ntp@ietf.org" <ntp@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>
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>
From: Christer Weinigel <christer@weinigel.se>
Message-ID: <4012d870-f760-8ead-2aec-d84c8c7e9181@weinigel.se>
Date: Mon, 17 Feb 2020 11:07:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <cf868779-a4ed-36aa-4487-24da20e8298c@dansarie.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/gydibXKbL-YgzPXSLlWK-vddhvQ>
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:08:04 -0000

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