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

David Benjamin <> Mon, 08 July 2019 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A2F6120355 for <>; Mon, 8 Jul 2019 15:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.956
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VyEpzpu6jFgd for <>; Mon, 8 Jul 2019 15:23:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0774F1201D0 for <>; Mon, 8 Jul 2019 15:23:48 -0700 (PDT)
Received: by with SMTP id k10so12058611qtq.1 for <>; Mon, 08 Jul 2019 15:23:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 8 Jul 2019 18:23:30 -0400
Message-ID: <>
To: Benjamin Kaduk <>
Cc:, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000ce9cc1058d32e58e"
Archived-At: <>
Subject: Re: [TLS] AD review of draft-ietf-tls-grease-02
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 22:23:59 -0000

Thanks for the comments! I've addressed them in

On Wed, Jul 3, 2019 at 1:11 PM Benjamin Kaduk <> 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"?


> 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

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

>    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...


> 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

>    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.


>    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.