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

Jonathan Hammell <jfhamme.cccs@gmail.com> Thu, 12 May 2022 17:16 UTC

Return-Path: <jfhamme.cccs@gmail.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 45821C159526 for <tls@ietfa.amsl.com>; Thu, 12 May 2022 10:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zpBGSN_jtdjS for <tls@ietfa.amsl.com>; Thu, 12 May 2022 10:16:00 -0700 (PDT)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B4BD9C14F74C for <TLS@ietf.org>; Thu, 12 May 2022 10:16:00 -0700 (PDT)
Received: by mail-vk1-xa32.google.com with SMTP id q136so2996103vke.10 for <TLS@ietf.org>; Thu, 12 May 2022 10:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rwXDH8+NCYkicZ0d6FcrN6H6ISKGwYVLNBzKdjDaML0=; b=gMTbhJfOaUyIZKJg1SJ6u8kocuoBqqxZriH6bD0kLADWYq6+Xf6QDE4tiBT1gpboO6 J2JzeFCi/W3ad7ZbsnKtip3RLAIBeHLrVav0s4ymv36fX8lx3r4vAEaPASHKIXgl5hHl 1PjP+rlGFadQ1D1IejxdRO9DGHkFWLk/fFKHWXGnXCxIqJU5hq/ewtKeZiZCZX0CRooh OEbkuDDOtQDy4fu+ELplacsHwDm53mxgidZ//3kEpjoRmfLQkGjI6l6sOGqQHATCbZdv 8s+qERv2dcvmAjAJHJ5Zhlk99WykEsIed+0HC3SRlpaoRRViid8nsOKPi5OZoAk0Hq8D 4GQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rwXDH8+NCYkicZ0d6FcrN6H6ISKGwYVLNBzKdjDaML0=; b=uk7faKEEkbknVwsqXPfUOH8yPJRImw3QjPS1umfAHlFDsn59u0GYUsXcctE+1KsZlL zywc4llHLx8K71ZTFdlxcBpBzSy6qZSKj/7fmEG2sXCjXLjyzAUO04Ox2alnM7xM7PGN fR0Mz+erC1R0PZS7npt4Ps16qS9yMVSxs7XMybqF/K7NQAvqo3RTivtqHR0SKSmokJMb ad26nuGi9HJWRLAxgb2mVnFZ95yg0KpfnLudIvif748I7+1Rv9t4adXvnHqC+v9FmOhq 7/aAu+n0n3BABKSe1Tl4EYeHYuCGNaBnsPHGMSGm/tOQ0ykFej7uIavx/7nmiO8TJQ6j AAmw==
X-Gm-Message-State: AOAM531prjzN2mLxUwehg7lUFv7dXYab54Ye2H19q+JU/+Z9fNju+YuK 7RD2/wEaxpS7NR87zJf/oGbj4DKSr6cNs9O5oed+2EOLelWxLA==
X-Google-Smtp-Source: ABdhPJz4Tv0/tvQqMM0rb891gSomaiPAkWveJTxtfOi3l/iq6+xZwtnYgnhJljWdyt84XfXK6sfiLoX/26Ota6pByCA=
X-Received: by 2002:a05:6122:178d:b0:355:d7f1:cf69 with SMTP id o13-20020a056122178d00b00355d7f1cf69mr740769vkf.18.1652375759401; Thu, 12 May 2022 10:15:59 -0700 (PDT)
MIME-Version: 1.0
References: <27E9945C-6A0A-46DD-89F0-22BE59188216@heapingbits.net>
In-Reply-To: <27E9945C-6A0A-46DD-89F0-22BE59188216@heapingbits.net>
From: Jonathan Hammell <jfhamme.cccs@gmail.com>
Date: Thu, 12 May 2022 13:15:47 -0400
Message-ID: <CALhKWgi2XfxBK-x_pxGHfuGxgYBt72M0epZYYvo92RPrVc7DnA@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EULFlk5mXZHvPbJdI9NO0ZYddcI>
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, 12 May 2022 17:16:04 -0000

I have reviewed the I-D and I agree with others that it is a simple
solution and that will benefit implementation.  I have only a few
minor comments on the text.

- Section 1.2, definition of "Hybrid" should clarify that the key
exchange algorithms are to be performed (negotiated and transmitted,
as it says in the Introduction) within the TLS 1.3 handshake.
Otherwise, hybrid could cover out-of-band mechanisms that contribute
key material (draft-ietf-tls-external-psk-importer).

- Section 1.2, paragraph beginning with "The primary motivation...":
It says that it is possible alternative public key constructions "will
be required... for example because of a cryptanalytic breakthrough".
I suggest changing "required" to "desired to mitigate risks".

- Section 1.3, motivation: There are many cases considered under
motivation, without clearly stating the combination of mechanisms that
might achieve the goals.  If this is meant to be left to the reader,
then I suggest adding a sentence to the final paragraph that says:
"Users should consider the confidence they have in each hybrid
component to assess that the hybrid system meets the desired
motivation."

- Section 1.3: s/due the threat of/due to the threat of

- Section 3.1: The term "codepoint" was not used in RFC 8446 (though
it does use "Code Points" in the comments of the IANA registry
tables).  In this instance in the text, I suggest replacing it with
"value" or "identifier" to align.

- Section 1.2 defines hybrid in this context to mean "two (or more)
key exchange algorithms".  However elsewhere, such as Section 3.1
("ordered pair of two algorithms") and Section 3.3 ("the two shared
secrets are concatenated"), the descriptions assume that only two
algorithms are used.  I see no technical reason to limit to two
algorithms.

Best regards,
Jonathan
Canadian Centre for Cyber Security

On Wed, Apr 27, 2022 at 11:28 AM Christopher Wood <caw@heapingbits.net> 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