Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

David Benjamin <davidben@google.com> Wed, 21 August 2019 21:44 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 02F52120098 for <tls@ietfa.amsl.com>; Wed, 21 Aug 2019 14:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 8jCQJWemn95R for <tls@ietfa.amsl.com>; Wed, 21 Aug 2019 14:44:39 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 6E309120091 for <tls@ietf.org>; Wed, 21 Aug 2019 14:44:39 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id 196so2316459pfz.8 for <tls@ietf.org>; Wed, 21 Aug 2019 14:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s3DzIaG5yn1/1CgtHSJ8fuYut6oe/+M36oT5YVx4LJw=; b=EKXouLbdnmchoRKkzR9VQpsWDB8wp/zaU8nLDVuOAclDiHt/7tgWgmYThg3xwaSEvq L9qwZMVVDQxyteT7FzYTQUe3MZXi57rgTbxG4txBtS1uMpVGOuddgt/p12e6Zo+apvVu +RnqK+ch4lv4/xQL4Hj6A5kwPD/Lgp+mYOX9zd3PYISwNxIpNh8s+kXkCJUWblxztCnj fJpLzXirVOrXCoRAcj4qeESKFiCmU5heG7MisgFHvsmBmbl/cNzvqEuyCbm8GHHrH6Ju 6hGLT/6ugO01nS1QXxu0TC1dZRl7WzduznHzWQiDVh+jrNm4KIEtZHRS2IfyqHRFzyOT ypTQ==
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=s3DzIaG5yn1/1CgtHSJ8fuYut6oe/+M36oT5YVx4LJw=; b=irlR3TdZCY2SKkaGB7Fkl7NA4vuEZf39CEKnyBdeXj1tHl8CT6amFWVX7Ola6c1kW7 ynAY3BOF2ZhRyzgixnDEbKsR/Fixdj7vrKXU/TeCM7JWCTBJoJGQH6Pnjzsa6ihd02Rl QX4jnSdMEzjnW5zF/yDuwLhlH+dIOyXjOjJB926ySk310ky38tadxR5K/sskZFho3zKf PAntKWRluPGynWXhDiPkLFgZ+4UB8043mUPYyNv/nswQUTnNCZekrxNKdg3GoqfE+p4v J2Y9Z75WFAvgU/78rlwhSTvuCh20pmGdpn6SIc6dj0ZJzEL20QmRvdvXJwBq7fNmCusQ AFQA==
X-Gm-Message-State: APjAAAWVcNUyXLIh8PM95JGlXC1aIyOKWwbFJmTAiAaTPAqk7STyBePu jKHJQzRupGnMTt5ASXJaM4cbMPH+qhyUNMBUA0E+
X-Google-Smtp-Source: APXvYqxxXMajTppysLAE0Ntkg+GuFgXQ1Mo8qJsXUUtsugHtJjCfzF5bn8tKoeVs21PreAJMwc1bewBaKJ8BwCj5eyY=
X-Received: by 2002:a17:90a:19c4:: with SMTP id 4mr2126875pjj.20.1566423878666; Wed, 21 Aug 2019 14:44:38 -0700 (PDT)
MIME-Version: 1.0
References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com>
In-Reply-To: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com>
From: David Benjamin <davidben@google.com>
Date: Wed, 21 Aug 2019 17:44:22 -0400
Message-ID: <CAF8qwaDRD1=X=R=e1QRkO81SdXmqfQYKihMo1z5hccsDtAqFYw@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-grease@ietf.org, Sean Turner <sean@sn3rd.com>, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000db8d250590a77a52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mYf9IMKimifHhwOj79_HGnVfw0w>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-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: Wed, 21 Aug 2019 21:44:42 -0000

On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker <
noreply@ietf.org>; wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) Per the following:
>
> Section 3.1 says “Note that this requires no special processing on the
> client.
> Clients are already required to reject unknown values  selected by the
> server.”
>
> Section 4.1 says “Note that this requires no special processing on the
> server.
> Server are already required to reject unknown values selected by the
> client.”
>
> These statement don’t seem precisely right.  Per Section 3.1, if a client
> understands GREASE enough to put it into a message to the server, and the
> server for some reason tries to negotiate this value, isn’t there ‘special
> processing' required in the client to the degree that it knows it shouldn’t
> accept the value it requested in the negotiation?
>

I suppose it depends on how one implements it. We implemented it by just
making our ClientHello, etc., serializer put add extra junk in there, so
the logic for deciding what extensions are acceptable does not see it at
all. I suppose, sure, if you implemented it by actually registering a fake
curve, that would be a lot more complexity and probably a bad plan.

How's this rephrasing?

     Note that this can be implemented without special processing on the
client. The client
     is already required to reject unknown server-selected values, so it
     may leave GREASE values as unknown and reuse the existing logic.

(And analogously for the server section.)


> (2) Section 7.  Per “GREASE values may not be negotiated …”, is there a
> reason
> this isn’t “must not be negotiated”?
>

 That clause was meant to be descriptive of the other bits of the document.
"[Such-and-such] may not be [such-and-such]ed, so [some consequence of
this]". Using "must not" reads odd to me: "GREASE values must not be
negotiated, so they do not directly impact the security of TLS connections."

David