Re: [TLS] AD review of draft-ietf-tls-grease-02

David Benjamin <davidben@chromium.org> Mon, 08 July 2019 22:23 UTC

Return-Path: <davidben@google.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 6A2F6120355 for <tls@ietfa.amsl.com>; Mon, 8 Jul 2019 15:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.956
X-Spam-Level:
X-Spam-Status: No, score=-7.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 VyEpzpu6jFgd for <tls@ietfa.amsl.com>; Mon, 8 Jul 2019 15:23:48 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 0774F1201D0 for <tls@ietf.org>; Mon, 8 Jul 2019 15:23:48 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id k10so12058611qtq.1 for <tls@ietf.org>; Mon, 08 Jul 2019 15:23:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XJ7S82p5jErSPYX4MUbNsZskWdtoKfADvqbS652IZy8=; b=DZsjkq0xBiEygh6t2Ngkzjj9i2W1CoJswIF3n6UDIlheku/1ZyG1oRxDeJnz6mKmjP cK65MQhBVX4fLREstBxLuu44e2sG6qfon4GNWEjonXbcBhSuaIyfNVrlOMI28Kq8g101 rAFUm/9pM181Bo3uJFw5/sG6dhrYqKvmXavVw=
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; bh=XJ7S82p5jErSPYX4MUbNsZskWdtoKfADvqbS652IZy8=; b=TTHvo8j/7lvrAVevVEEYn0JE65VUwHmUp2BU96oDYcJ9dJMZkFVcdasF2wsjfR/6v3 LSd31wVgcOOKlUChg9HROwO8cyH8Lj0gilKj9Ni7E2TD7eKJoHyRTcJSrVxqOK0WoagY HJcisfFjLiZLtgBfuIv2SU3G3bBS91Xfc9BNXA86ZNA5cMkE5kIR2uFq3Yzps5EnlVXF jVPbKW2UryoA4zuNmg/U3SuqmywHAfX0DVQy2U1Pt0aMsC+ah9ePHLFG9mYWdENodZRM be1f/1XqGxmRa9T5Lp59678n2DdM5SL4vJEm1oUxOejTbO8dYMkbwYLaswj8P3ct9A+0 ykWA==
X-Gm-Message-State: APjAAAUaWE41Iqhc/x5U2tmsraprSV1c07TgtHc6KgjPqlHYSansxWzh QHOiMKRudY5ITQJ8gMKTgRHAHzm3+oTRCKoCiYS9
X-Google-Smtp-Source: APXvYqwLQxiHx5EOy/7eHJa23tQkqbDQl0uEGGgpl+hmJwkhYxYMSJyBrnXPa3je+c8FP7E/7M7WYuePYH3fGcSaqF4=
X-Received: by 2002:aed:34a6:: with SMTP id x35mr13582841qtd.187.1562624626918; Mon, 08 Jul 2019 15:23:46 -0700 (PDT)
MIME-Version: 1.0
References: <20190703171111.GK13810@kduck.mit.edu>
In-Reply-To: <20190703171111.GK13810@kduck.mit.edu>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 8 Jul 2019 18:23:30 -0400
Message-ID: <CAF8qwaDWCywCJmwBbr7QeEgNRyZodt1mK8xxJBYVfuGzyNVSVA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-grease.all@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce9cc1058d32e58e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Psiz4mmGhSuo_02LVT0yyMAIRig>
Subject: Re: [TLS] AD review of draft-ietf-tls-grease-02
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, 08 Jul 2019 22:23:59 -0000

Thanks for the comments! I've addressed them in
https://github.com/tlswg/draft-ietf-tls-grease/pull/10.

On Wed, Jul 3, 2019 at 1:11 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Section 1
>
>    The TLS protocol [RFC8446] includes several points of extensibility,
>    including the list of cipher suites and the list of extensions.  The
>    values in these lists identify implementation capabilities.  TLS
>
> We could probably make this text a little more precise (for one, there's
> not a single list of extensions since many messages can carry
> extensions).  So, maybe "the list of cipher suites and several lists of
> extensions" and "The values transmitted in these lists"?
>

Done.


> Section 2
>
> Can we add an editorial note that values prefaced with "{TBD}" are
> suggested values but subject to change prior to final allocation by
> IANA?
>

Done. Also made the other such notes match the style used in the TLS 1.3
draft.


>    Future versions of TLS or DTLS [RFC6347] MUST NOT use any of the
>    above values as versions.
>
> Process-wise, this feels like an attempt to Update: the (D)TLS core
> specs, which we can't do in an Informational document.  So it would
> probably be better to say something "The values thusly allocated are no
> longer available for use as version numbers by (D)TLS implemnetations".
> Things are made somewhat awkward by there not being a registry of
> protocol versions, sadly...
>

Done.


> Section 3.1
>
> Are there any of these for which we want to say "the client MUST NOT
> advertise a list consisting solely of GREASE values"?  It would probably
> be fine to do this for, say, key_share, but not for, say, cipher_suites.
> But perhaps the reader will be smart enough to figure out what works
> without prodding from us...
>

I dunno, I feel like that's a bit overkill, but I can include something in
that vein if others disagree. A cipher suite list full of GREASE is
functionally equivalent to a list containing some weird cipher no one
implements.


>    Clients MUST reject GREASE values when negotiated by the server.
>    Specifically, the client MUST fail the connection if a GREASE value
>    appears any in the following:
>
> I did not attempt to audit the (omitted) list for completeness; the
> first sentence should cover any situations that are not specifically
> listed, right?
>

It should. I replaced "Specifically" with "In particular" so that's clearer.


> Section 3.2
>
>    When processing a ClientHello, servers MUST NOT treat GREASE values
>    differently from any unknown value.  Servers MUST NOT negotiate any
>    GREASE value when offered in a ClientHello.  Servers MUST correctly
>    ignore unknown values in a ClientHello and attempt to negotiate with
>    one of the remaining parameters.
>
> Similarly to the above, we might consider adding a parenthetical noting
> that there may not be any remaining valid parameters, and that's not
> necessarily fatal.
>

Done.


>    Note that these requirements are restatements or corollaries of
>    existing server requirements in TLS.
>
> (side note) Some future reviewers might complain about using normative
> language to duplicate exisiting requirements from other documents; in
> this case, I don't mind, myself.
>
> Section 4.1
>
>    o  A server MAY select one or more GREASE extension values and
>       advertise corresponding extensions with varying length and
>       contents.
>
> nit: I don't think "corresponding" is quite the right word; maybe
> "advertise those extensions"?
>

Rephrased this and elsewhere.


>    o  A server MAY select one or more GREASE signature algorithm values
>       and advertise them in the "signature_algorithms" extension.
>
> I'm not necessarily expecting any action based on this comment, but I
> note that status_request, signed_certificate_timestamp,
> certificate_authorities, oid_filters, and signature_algorithms_cert are
> also currently defined for CertificateRequest but we do not call out any
> extension-specific greasing for them.  Of that list, only
> signature_algorithms_cert seems like it might be calling out for special
> handling, to me...
>

Added signature_algorithms_cert.


> Section 4.2
>
>    When processing a CertificateRequest or NewSessionTicket, clients
>    MUST NOT treat GREASE values differently from any unknown value.
>    Clients MUST NOT negotiate any GREASE value when offered by the
>    server.  Clients MUST correctly ignore unknown values offered by the
>    server and attempt to negotiate with one of the remaining parameters.
>
> (following the theme) I don't remember any cases where the client can
> succeed if the list becomes empty after pruning unknown values ... if we
> are deciding that we want to say anything on this topic at all.
>

Added a similar parenthetical.


> Section 5
>
>    Implementations advertising GREASE values SHOULD select them at
>    random.  This is intended to encourage implementations to ignore all
>    unknown values rather than any individual value.  Implementations
>    MUST honor protocol specifications when sending GREASE values.  For
>    instance, implementations sending multiple GREASE values as
>    extensions MUST NOT send the same GREASE value twice.
>
> Feel free to tell me that I'm being internally inconsistent, but in this
> case "MUST NOT send the same GREASE value twice" does not seem like a
> good place to use normative language to restate an existing requirement.
> So I'd rather see lowercase "must not" and possibly a section reference
> to 8446 ยง 4.2 ("[t]here MUST NOT be more than one extension of the same
> type in a given extension block.").
>

Rephrased this.


> Section 6
>    [[TODO: Update IANA considerations for TLS 1.3 and rebase over draft-
>    ietf-tls-iana-registry-updates.]]
>
> Can the shepherd please work with the author to make the needed changes?
>
> IIRC the main change for TLS 1.3 is the "TLS 1.3" column for
> extensiontype values.
>
> Since this document is Informational, we have to be Recommended "N" for
> everything.
>

Oh oops, I must have missed this when rebasing over TLS 1.3. Added the
relevant columns.


> Thanks for the note about the specific values listed being just
> suggestions.
>
>