Re: [TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Mon, 16 December 2019 21:07 UTC

Return-Path: <barryleiba@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 F255C120927; Mon, 16 Dec 2019 13:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 cBxZhMgtAMTH; Mon, 16 Dec 2019 13:07:52 -0800 (PST)
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BBB12008D; Mon, 16 Dec 2019 13:07:52 -0800 (PST)
Received: by mail-io1-f43.google.com with SMTP id c16so6647530ioh.6; Mon, 16 Dec 2019 13:07:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JiAJDk8aVeaiIwGyVBCNyQ4axDdhvxaez6d35hiwKoY=; b=hxtWZtfJeeC56xwYotmY/0BIBUik1aCjH+NYF8LZwIgcYKWZb/BRfUYinJuuQcszte Tm4OAy/yS0UuJ5oopiu8pF+haFPyAaSTvoKiBkq6jufHv7uDuvDWsJGOsvo02/phjEku GzPkUpoyZFdhuDSwZ7CRKu9YY9NzoBpj0qQ2B8hWwerG3+w7Rgkjy5qCoIHb9zQD6aGM lTOnSBnI5Spq4WIl1VWIqf6cDeUeeE0J6bZegCousbBff2ESKDV2grddo70yspv9iW/h 4xYROJ4yuWp4FDNDVp00azfTgqT6eGyLPSqcCH728GltPEem1QctOtAL9uZoc7SIzcIc bBfw==
X-Gm-Message-State: APjAAAV5DdeMAAnqXnWun23e80pcDZlTuBWyaHb+DXgXdxota4/a1x8T GGC7y2OcB+ILy5YCxGb/4AzFUYr0tXVojeMyYRkLu/T8
X-Google-Smtp-Source: APXvYqwjhTh6D3k4EHHip9IJsF00rT04l43EVYSNTAInCtaEvoRzKr7AWb69+cTjEho2+KJYcQ+w/W/VPQbGCr1HrZ0=
X-Received: by 2002:a02:4e46:: with SMTP id r67mr3455991jaa.118.1576530471432; Mon, 16 Dec 2019 13:07:51 -0800 (PST)
MIME-Version: 1.0
References: <157648614028.21609.11590282747489219348.idtracker@ietfa.amsl.com> <343163EC-6CFE-439A-AD90-8CBAA0A7CED0@vigilsec.com>
In-Reply-To: <343163EC-6CFE-439A-AD90-8CBAA0A7CED0@vigilsec.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 16 Dec 2019 16:07:40 -0500
Message-ID: <CALaySJ+4hVZF=8bAMGFMKvcZFgp7a1zjgHsGMUuAByTPWT6_DQ@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IESG <iesg@ietf.org>, tls-chairs <tls-chairs@ietf.org>, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cV_1zWL7dkMGe2hzPP-w-j-rR0c>
Subject: Re: [TLS] Barry Leiba's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
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: Mon, 16 Dec 2019 21:07:54 -0000

Thanks, Russ.  And, yes, my comment about knowing when the experiment
is over and what the results are... was something of a rant, and I
agree that I can't think of anything useful to say.  Sigh.

Anyway, thanks for addressing my comments.

Barry

On Mon, Dec 16, 2019 at 1:11 PM Russ Housley <housley@vigilsec.com> wrote:
>
> Barry:
>
> You do not call for a response, but I want you to know that your comments are being addressed.
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >> From the shepherd writeup:
> >
> >   There was concern raised that no one has reported implementation
> >   of this draft. The document has experimental status and that helped
> >   gain working group consensus to move it forward.
> >
> > ...and...
> >
> >   The document has been reviewed and is supported by a few
> >   working group members.  Not everyone in the group agrees
> >   that it is needed,
> >
> > This seems to imply that making it Experimental was a tactic to get it through
> > the working group, and that concerns me a bit, though not enough to get to
> > DISCUSS.  I would be happier if there were some discussion in the document
> > about how we would determine that it is, indeed, needed and useful, and when we
> > might know that we should move it to Standards Track or else abandon it.
> >
> > Unfortunately, I suspect the answer to that is that we won’t know until we have
> > quantum computers to mount attacks with, and that won’t be until certain places
> > freeze over.  I realize that preparing for maybe someday having quantum
> > computers and what they might someday do is an exercise that not everyone will
> > want to spend time working on and implementing.
>
> I do not think we can add anything to the document.  As was said on the email thread on the TLS mail list, there is a plan to use it by the US government.  Others have not said one way or the other.
>
> > Some editorial comments, for which no reply is necessary:
> >
> > — Section 4 —
> >
> >   Since the
> >   "tls_cert_with_extern_psk" extension is intended to be used only with
> >   initial handshakes, it MUST NOT be sent alongside the "early_data"
> >   extension.
> >
> > What happens if it is?  Should this say that if they appear together the server
> > aborts the handshake with an "illegal_parameter" alert?
>
> I added a paragraph:
>
>    If the client includes both the "tls_cert_with_extern_psk" extension
>    and the "early_data" extension, then the server MUST terminate the
>    connection with an "illegal_parameter" alert.
>
> >   The hash algorithm MUST
> >   be set when the PSK is established, with a default of SHA-256.
> >
> > If it MUST be set, how is there a default?
>
> This is stated in RFC 8446 in Section 4.2.11.
>
> > — Section 5 —
> >
> >   If the server responds with a HelloRetryRequest
> >   message, then the client sends another ClientHello message as
> >   described in Section 4.1.2 of [RFC8446], including the same
> >   "tls_cert_with_extern_psk" extension as the original ClientHello
> >   message or abort the handshake.
> >
> > “, or aborts” (the comma closes the comma before “including”, and “aborts” is
> > parallel to “sends”).
>
> Fixed.
>
> > — Section 5.1 —
> >
> >   Most of those extension are
> >   not impacted in any way.  This section discusses the impacts on the
> >   other extensions.
> >
> > Make it “those extensions”.  And I would rephrase the second sentence as, “This
> > section discusses the impacts on the extensions that are affected.”
>
> I suggest:
>
>    Section 4 lists the extensions that are required to accompany the
>    "tls_cert_with_extern_psk" extension.  Most of those extension are
>    used in the usual manner.  This section discusses the impacts on the
>    extensions that are affected the presence of the
>    "tls_cert_with_extern_psk" extension.
>
> >   The "psk_key_exchange_modes" extension restricts both the
> >   use of PSKs offered in this ClientHello and those which the server
> >   might supply via a subsequent NewSessionTicket.
> >
> > “Use of” needs to be factored out of the “both” clause:
> > NEW
> > ...restricts the use of both the PSKs offered in this ClientHello
> > and those that the server might supply...
> > END
>
> I accepted you better wording.
>
> > — Section 7 —
> >
> >   the external PSKs and searching the resulting small set of
> >   possibilities, rather than brute force searching the whole key space.
> >
> > “and search”, and “brute-force”
>
> I accepted you better wording.
>
> >   The reasoning is explained in [K2016] (see
> >   Section 4.2).
> >
> > I suggest “The reasoning is explained in Section 4.2 of [K2016].”  Otherwise it
> > sounds like you should see 4.2 of this doc (and I think the html links will be
> > generated better this way).
>
> I accepted you better wording.
>
> >   This specification does not require that external PSK is known only
> >
> > “that the external PSK”
>
> I added the missing article.
>
> Russ
>
>