Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

Mirja Kuehlewind <> Fri, 16 August 2019 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56441120124; Fri, 16 Aug 2019 00:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NsZpZaK3NQA0; Fri, 16 Aug 2019 00:35:15 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F35E1120120; Fri, 16 Aug 2019 00:35:14 -0700 (PDT)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hyWlT-00081j-7b; Fri, 16 Aug 2019 09:35:11 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Fri, 16 Aug 2019 09:35:09 +0200
Cc: The IESG <>,,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1hyWlT-00081j-7b
Archived-At: <>
Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?=
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: Fri, 16 Aug 2019 07:35:18 -0000

Hi Ben,

Thanks for the explanation.

I would think this is actually a PS given it extents a protocol based on the extension point this protocol provides. Maybe it is not really adding a new function but it also kind of is: I would call probing for non-compliant implementations a protocol function. I mean if we would specify greasing for a new protocol, I think it would simply be part of the main spec.


> On 16. Aug 2019, at 05:39, Benjamin Kaduk <>; wrote:
> On Thu, Aug 15, 2019 at 08:57:43AM -0700, Mirja Kühlewind via Datatracker wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-tls-grease-03: No Objection
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> Sorry one more comment/question I forgot earlier: Why is this document
>> informational? Shouldn't it be at least experimental?
> I added a note to the shepherd writeup's "intended document status" entry:
> AD NOTE: Note that this has been successfully deployed for
> over a year; it's not really an "experiment" anymore but rather
> a useful thing that people do, both in TLS and elsewhere.  This
> is informational in the sense that "here is a thing you can do,
> and some information about why you might want to do it".  There's
> no real protocol -- you send some codepoints and expect the other
> endpoint to not change behavior as a result -- so it doesn't make sense
> as a proposed standard.  I suppose one could argue that it is a BCP
> since it is for the health of the ecosystem, but that does not really
> feel like a good match.  So to me, Informational is the right status.
> -Ben