Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Martin Thomson <mt@lowentropy.net> Thu, 28 April 2022 00:56 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 C6D52C15E6EC for <tls@ietfa.amsl.com>; Wed, 27 Apr 2022 17:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=dWaZDz5O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eF7woULn
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9oVbHwq6xqG for <tls@ietfa.amsl.com>; Wed, 27 Apr 2022 17:56:50 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEB6C15E6EB for <tls@ietf.org>; Wed, 27 Apr 2022 17:56:50 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E8FE45C00AF for <tls@ietf.org>; Wed, 27 Apr 2022 20:56:49 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Wed, 27 Apr 2022 20:56:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1651107409; x=1651193809; bh=XYaH8WMMuM 5L1z3/jiZaLh1TcDB/p/3670VAUa29fJ4=; b=dWaZDz5OLyLSfwTSrbGOczQHQ9 w28VgPdl9ABd5pxCIcUZhnh2D+APd20pUhAMusrFHig72VQOzTVEXn/5NeIlWJir BeZ6fOlMTxLbIrPBs/OVD/aAf3yL3VOtx0WK5Eq9wwJXbZYX/8ZW1AXHharZhHUg hdG+d//L639oPyxO3UZ4h2Mi7KyCY9Y7duw+iSLMQVjsbShIObaGN49Psy8l0vVl Emu6XI1YveO7Zh7pVC4E8H7ZTK79G34YkWJHhAZA9fzZTuhvLviquBIDIQ5myv2t oPcnm/Xbqgjclzuo2YhQxkSuDSq8EAqHJzTRZUmta+EVg3ZsS9McdEc/SkcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1651107409; x= 1651193809; bh=XYaH8WMMuM5L1z3/jiZaLh1TcDB/p/3670VAUa29fJ4=; b=e F7woULnyCR53oAymHkkeQzdYF6ntQcts5ipUVxot5tSdpj+4aH8LxLrW9F2BF49N hBVOzVsbxQKqrY/FpY/GNokvcZqjkDrHpvghSe3IpXkItPnrq0uGIrcMVUFZewC5 rY5WnYUNwwc2+rv8iUeB2Kv4N90hbPELVAtpEZyDdxsbvJNfFoBFV5WLdP6ettZj vC2nOjll1xPx+mRjq2LOqx7+Y+RdbqchCsG7gpbTMtkIAp/b1bukijUZmZ48l/Pl L8WrdOYz+AeJ6YzHCHaaLYP4nXOvlwBO6Q2a+VKll16hw+EyBALfAqDpqo9cys3v AhOeshjhtoIl41h9+Dh3A==
X-ME-Sender: <xms:UeZpYh52fTq9VnXNPJ7XKETbDEUMy_n8SfnnQ23OkgEzowaMJnOgpQ> <xme:UeZpYu5aKM8aKf4n2XSzeDURT-2lyMS3Zd98MIAkzrDUuVp9m_TSGmZRCQ454Yk1H MnPNHX3sh8U0ef2ruk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeigdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffelveevfeehhfeuveeute ekhedvveektdegvdegteetveekjedvvdejleelheevnecuffhomhgrihhnpehivghtfhdr ohhrghdpihgrnhgrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:UeZpYofjqKS4hCJOYTT1OHZcP9n3xMcIcy349O0G-mdWXtKQmZNGAQ> <xmx:UeZpYqKWq-99zsheVjscuQz0Dmn3PsLbcZlYDPhnA4Y4jlioMsvf8g> <xmx:UeZpYlJzAMvejb4mUBT2PlFkRCre-jTkZtnHcdGAvBSWmqVWWlY_Nw> <xmx:UeZpYqVGL7fcjxRxTVIY_Pb855A83SZX0NWoLYZaArp2dRq03LcJ6A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 997603C0FAD; Wed, 27 Apr 2022 20:56:49 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-569-g7622ad95cc-fm-20220421.002-g7622ad95
Mime-Version: 1.0
Message-Id: <96daf32f-dbdb-4e56-8617-d27f53abdff0@beta.fastmail.com>
In-Reply-To: <27E9945C-6A0A-46DD-89F0-22BE59188216@heapingbits.net>
References: <27E9945C-6A0A-46DD-89F0-22BE59188216@heapingbits.net>
Date: Thu, 28 Apr 2022 10:56:28 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TVKJWxkNiWxOSA8l0zTpHsvNkxs>
Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.34
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: Thu, 28 Apr 2022 00:56:55 -0000

I found the introduction of KeyGen, Encaps, and Decaps to be underutilized.  It would require a little work, but I think that it would be better to describe a method whereby you produce each of these functions by taking an ordered collection of these functions (KeyGen[i], Encaps[i], and Decaps[i]) and constants (Npk[i], Nek[i], etc...).

With something like this, I'd like to see the implication that the TLS key schedule is changed by this draft can be removed (in Section 3.3 specifically).

In essence, you are describing a known-good process for composing key exchange methods.  (Not existing TLS 1.3 key exchange methods, as implied by this:

> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. 

I think that this text is a mistake as it implies that the component key exchange algorithm has a defined key_exchange format.  What you want is a definition in the form above, or as HPKE has it.

I'd prefer to see this work done before publication, but as I'm not able to volunteer to do it, I can't really insist on it.  This is useful work and the document, despite these niggles, is pretty clear and well-reasoned.

On Thu, Apr 28, 2022, at 01:27, Christopher Wood wrote:
> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, 
> located here:
>
>    https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> We do not intend to allocate any code points at this time and will park 
> the document after the call is complete. Once CFRG produces suitable 
> algorithms for consideration, we will then add them to the NamedGroup 
> registry through the normal process [1] and move the document forward.
>
> Please review the draft and send your comments to the list. This WGLC 
> will conclude on May 13.
>
> Best,
> Chris, for the chairs
>
> [1] 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls