Re: [TLS] Advancing draft-ietf-tls-hybrid-design

Martin Thomson <mt@lowentropy.net> Wed, 07 July 2021 01:53 UTC

Return-Path: <mt@lowentropy.net>
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 903C13A15DE for <tls@ietfa.amsl.com>; Tue, 6 Jul 2021 18:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=HEyinHmQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iy3BAOBV
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 W6-rI2nqEFs0 for <tls@ietfa.amsl.com>; Tue, 6 Jul 2021 18:53:46 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EE13A15DD for <tls@ietf.org>; Tue, 6 Jul 2021 18:53:46 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E5EDB5C00D3 for <tls@ietf.org>; Tue, 6 Jul 2021 21:53:44 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 06 Jul 2021 21:53:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=2SUL741oRvMb7EDWUVczBNKymA8Z0mY mZR1OmmvmFJ0=; b=HEyinHmQDZBj06akCVZclrJXUIy+grqUZj9FeU03yTMvUkY WRwTUp7GMi0Qf6hqhrV0yKdvCp4HQh/IjeHDNeNCXtYa8ryvwC6V7iIjn3fnVSRk vyj7GyLVaoUWCxi1iaGNWERrQ/pmqReifLIvnCJE5bOg1bVIZZUCRFtUNhrX1Wm9 Z0aIgoY0QBbo7DAy9G43YMX6sZ1mUABeC6A5VeqaabhfEP+PfybvvdE4y8yQxRTc EklS/Ij64jYkAN8Lkh3jN/bcsnSxElKN+MN51SoJaANpeXo8yKpeVSGgMD9AnhP5 VqMyHz5ee7wUbEFbIHAFO2YopDAN4yUt1IsxFbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2SUL74 1oRvMb7EDWUVczBNKymA8Z0mYmZR1OmmvmFJ0=; b=Iy3BAOBV4LVzh8Y1iCOnok lt67bZX6O73T+94vUrpsQCcD8KpKBCzIXNUe2zO2BgpBPPrd85hAAsMfSzRec8iE BFPNoZ+Orzc27xN5QEqLLoK2y6kas+SF5Lm7dporbtkTXo696UbCFfK3bvoBkKm8 o/xS0HeyCiO7LwCBEeysWDcEoFAyuCdcqGXqx59HL5nIlOhK4O4xrs2GXRJXReTg evp9T7n1ghu0P2GFDMO5eHthN3Ykjt1mMJ+MZGVjR/ee7MuskmDv0CmtxS0NicTo YYvfAiHpq6VdWvE4PWjxMYIitvahr56CkwNq2/VtI6HJ/vc93S9KCiRcOSuQGZEA ==
X-ME-Sender: <xms:KAnlYNfiqihRKjTqpD0iycLHtJRua4WI_aaQZO24RaCP0z9tlzlqPA> <xme:KAnlYLPbubDU3TUjNATHpibOkLj3TnESE02ofk-ci6LRPL2t9XeM5t_JH7hk58eGl EGCKEH3gppiL4z9efo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddugdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfeitddtveeihfejjefgve efuedugffgkeevkeehueeggeelveekveektdfhueeinecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:KAnlYGi16fRZctyOmzeXPSR_EK0U2K5l-mwTAbZZ5ScyAiSV9mMT4A> <xmx:KAnlYG8ZQfFPQQiFlEZG49vm2s8L4GBev_fJwHgEL4igc0QSnaeW-w> <xmx:KAnlYJtSKSYYY2ZKxyUEXc_dsxHBgwpaV9r1gI1NhRdO4fYnA82CIg> <xmx:KAnlYH4xTj_D99vFQ3Z6P1qD44IMrzT4wpO7QptgIc64YiRPOXvpjw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 884423C003D; Tue, 6 Jul 2021 21:53:44 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-531-g1160beca77-fm-20210705.001-g1160beca
Mime-Version: 1.0
Message-Id: <8e134f86-0cb7-4d76-8090-37471364cece@www.fastmail.com>
In-Reply-To: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com>
References: <1DCCB8D8-F987-4A30-8084-06CE6FBCD507@gmail.com>
Date: Wed, 07 Jul 2021 11:53:25 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3JZoyniHrl0HbZHiJ10-0IWrm3A>
Subject: Re: [TLS] Advancing draft-ietf-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: Wed, 07 Jul 2021 01:53:52 -0000

I just took a look.  I didn't read the (large) appendices, though I appreciate that they have value.

The draft is largely in good shape.  I have a few minor concerns.

I don't think that you want to reserve the hybrid_private_use(0x2F00..0x2FFF) range of values.  There were specific reasons for an FFDHE range that I don't think apply if we constrain this design to TLS 1.3 and higher (as we should).  The same applies to the 0x02.. prefix you suggest for the use of hybrid codepoints.

I find the emphasis on the NIST process a little strong for what is a permanent artifact.  It is OK to note its existence as motivation for the work, but I would avoid over-emphasis.  For example:

OLD:
   Moreover, it is possible that even by the end of the NIST Post-
   Quantum Cryptography Standardization Project, and for a period of
   time thereafter, conservative users may not have full confidence in
   some algorithms.
NEW:
   Moreover, it is possible that after next-generation algorithms are defined, and for a period of
   time thereafter, conservative users may not have full confidence in those algorithms.

and 

OLD:
   In the context of the NIST Post-Quantum Cryptography Standardization
   Project, key exchange algorithms are formulated as key encapsulation
   mechanisms (KEMs), which consist of three algorithms:
NEW:
   This document models key agreement as key encapsulation
   mechanisms (KEMs), which consist of three algorithms:

Please avoid "defining" codepoints, even in examples:

OLD:
   For example, a future document could specify that hybrid value 0x2000 corresponds to
   secp256r1+ntruhrss701, and 0x2001 corresponds to x25519+ntruhrss701.
 NEW:
   For example, a future document could specify that one codepoint corresponds to
   secp256r1+ntruhrss701, and another corresponds to x25519+ntruhrss701.
  
Finally, the use of the word "hybrid" is awkward.  Maybe "composite" is a less-heavily overloaded term that accurately captures the intent; with an antonym of "unitary" or "discrete".

When you talk about concatenation, it might pay to cite the relevant appendix.  I would also note that the goal is that when the composed elements are not fixed-length, a length prefix might be used to ensure that both secrets contribute all of their entropy without being exposed to a weakness in the other.  (You might say that the composition is injective.)

Section 4 includes questions to which I think answers can be given now:

 *Larger public keys and/or ciphertexts.* => I think that the answer here has to be "too bad".  Just note that TLS cannot handle a KEM that includes values larger than 2^16 (minus a little bit).

*Duplication of key shares.* => Your existing text is sufficient to answer this one.

*Resumption.* => There isn't much existing language on this point, but I don't see it as needing anything special in this draft.  My view is that fresh entropy of any kind is an improvement, but generally we will see better than that because clients and servers will perform a fresh key exchange with an algorithm that they consider sufficient at the time.  That might result in a change in posture relative to the original session, but the result should still be as good as min(original, current), which is always better than just using the PSK.

*Failures.* => KEM failure is a problem, but I would do nothing more than note the potential and have the handshake fail.  I see that the finalists have low enough error rates that this doesn't seem likely to be an issue in practice.  Clients can always try again if they hit this specific problem.  Ours already retries in a bunch of different failure cases.  Some text on this point in the draft is probably sensible.

Nits:

OLD:
   However, the
   key_exchange values for each algorithm MUST be generated
   independently.
NEW:
   However, 
   key_exchange values for different algorithms MUST be generated
   independently.



On Wed, Jul 7, 2021, at 11:19, Douglas Stebila wrote:
> Dear TLS working group,
> 
> We wanted to see if there is any further feedback on our draft "Hybrid 
> key exchange in TLS 1.3" 
> (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/) and 
> what steps are required for it to advance further.  We have not 
> received any new feedback from the working group since we posted our 
> last non-trivial update in October 2020.
> 
> The draft as written does not actually specify any post-quantum 
> algorithms nor give identifiers for specific algorithm combinations, 
> only the formats for hybrid key exchange messages and key derivation.  
> We have received a suggestion that the draft be updated to include 
> identifiers for hybrid key exchange combining elliptic curve groups and 
> the KEMs currently in Round 3 of the NIST PQC standardization process, 
> so that implementations can begin testing interoperability using 
> numbers listed in the draft, rather than relying on ad hoc lists for 
> such purposes.  Is that something the working group would like to see, 
> or would you prefer to leave it as it currently stands, without any 
> specific algorithm identifiers?
> 
> Douglas, Scott, and Shay
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>