Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Russ Housley <housley@vigilsec.com> Fri, 21 February 2020 19:29 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4912006E for <tls@ietfa.amsl.com>; Fri, 21 Feb 2020 11:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 KlDXUuy_rrKr for <tls@ietfa.amsl.com>; Fri, 21 Feb 2020 11:29:04 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB6812006B for <tls@ietf.org>; Fri, 21 Feb 2020 11:29:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 529A5300B3C for <tls@ietf.org>; Fri, 21 Feb 2020 14:02:22 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H55n75Z114qH for <tls@ietf.org>; Fri, 21 Feb 2020 14:02:20 -0500 (EST)
Received: from [192.168.1.161] (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 89DB1300595; Fri, 21 Feb 2020 14:02:20 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <b91df74c-cec7-44a3-9224-6240553af223@www.fastmail.com>
Date: Fri, 21 Feb 2020 14:29:01 -0500
Cc: Carrick Bartle <cbartle891@icloud.com>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ADAE043-22A5-4926-B09E-B167D189B660@vigilsec.com>
References: <CAFBh+SRAJAbviyrcQM2PjztumAH565i4-ui28OQ-pCJE9nePJg@mail.gmail.com> <284685f0-8b19-4870-aef6-573809827091@www.fastmail.com> <D4DBD81C-6555-4EBD-AA77-49905CB88B22@icloud.com> <b91df74c-cec7-44a3-9224-6240553af223@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eaR0p98W9EPlDrjiv4oLjdrRjlw>
Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 19:29:07 -0000


> On Feb 12, 2020, at 6:22 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
>> I'm brand new to the IETF, so please forgive me if I'm totally off base 
>> here, but my understanding is that Informational RFCs are explicitly 
>> not recommendations (let alone mandates)?
> 
> This would of course be information, but my comment was about phrasing.  This document comes off as being quite prescriptive, where it doesn't really need to be.  Absent actual algorithms, it's just a set of guidelines.  That's reflected in its Informational status, but it would be better if the verbiage also reflected that more clearly.
> 
> To address Stephen's comment at the same time: I think that we can publish an RFC on this before the competition completes if it is just a framework.  That might in fact make standardizing the one true composite scheme easier.

I do not agree.  I do not think the WG should adopt this draft.

The CFRG has stated a position that the IETF should wait for the NIST standardization process to be complete.  There are at least two approaches to mixing symmetric keying material into the TLS 1.3 key schedule for information that needs to be protected for the next few decades.  (The two that I know about are draft-ietf-tls-tls13-cert-with-extern-psk and draft-vanrein-tls-kdh.) These approaches make existing key establishment techniques secure even if a quantum computer gets developed as long as the symmetric key is not disclosed.  In my opinion, those techniques will hold us until the NIST standardization process finishes.

I do not understand the goal of mixing (EC)DH with one of candidate algorithms.  We do not know enough about the candidate algorithms in the NIST process.  If the goal is to add quantum resistance, we do not have enough information to pick well.  If the goal is to learn about mixing in general, then I question the project altogether.  Once the NIST standardization process is complete, we can simply use the selected algorithm without mixing.

Russ