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

Roman Danyliw <rdd@cert.org> Thu, 22 August 2019 03:31 UTC

Return-Path: <rdd@cert.org>
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 6E390120018; Wed, 21 Aug 2019 20:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 7QZVSD3nSevz; Wed, 21 Aug 2019 20:31:38 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7A01200B2; Wed, 21 Aug 2019 20:31:38 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3VaG2000497; Wed, 21 Aug 2019 23:31:36 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x7M3VaG2000497
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1566444697; bh=wGFuHmdQogXcsb62fGcri+MewS94zVsolh1KJs8qGoM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=raNg24bxfN6at/p43/2uo5JsxWTAs/NXrsd3B5YbkjsHx3ZknmOPvY3qq+LpFwApB EoxQMD4FVti5zx0lGIneUw1zvWVwc/pD0KZE+oCLU3+1MDC7KyOSvO426/bZANeMwe lkIaEeB4UFNzylIbne2e0Mzpeh6qh7By6eaCakcw=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3VTkm016402; Wed, 21 Aug 2019 23:31:29 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Wed, 21 Aug 2019 23:31:28 -0400
From: Roman Danyliw <rdd@cert.org>
To: David Benjamin <davidben=40google.com@dmarc.ietf.org>
CC: "draft-ietf-tls-grease@ietf.org" <draft-ietf-tls-grease@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, The IESG <iesg@ietf.org>, Sean Turner <sean@sn3rd.com>, tls-chairs <tls-chairs@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)
Thread-Index: AQHVV348PAvhpEvIREShTBbFYftYbqcGZ0EAgAAbK7A=
Date: Thu, 22 Aug 2019 03:31:27 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3439C82@marathon>
References: <156632275485.502.9271987365148891210.idtracker@ietfa.amsl.com> <CAF8qwaDRD1=X=R=e1QRkO81SdXmqfQYKihMo1z5hccsDtAqFYw@mail.gmail.com>
In-Reply-To: <CAF8qwaDRD1=X=R=e1QRkO81SdXmqfQYKihMo1z5hccsDtAqFYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B3439C82marathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xoIOsjR4uvG9IYkBMSqmoglo-RI>
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: Thu, 22 Aug 2019 03:31:40 -0000

Hi David!

From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of David Benjamin
Sent: Wednesday, August 21, 2019 5:44 PM
To: Roman Danyliw <rdd@cert.org>;
Cc: draft-ietf-tls-grease@ietf.org; <tls@ietf.org>; <tls@ietf.org>;; The IESG <iesg@ietf.org>;; Sean Turner <sean@sn3rd.com>;; tls-chairs <tls-chairs@ietf.org>;
Subject: Re: Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker <noreply@ietf.org<mailto: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.)

[Roman] This text works for me.  Thank you.

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

[Roman] Understood.  Under separate cover, Martin suggested “cannot”.  I’m flexible on the edit (i.e., consider what I said a suggestion) given the clarity of your explanation (and this is only a comment).  Thank you.