Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

Benjamin Kaduk <> Thu, 07 June 2018 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CEB8130F58 for <>; Thu, 7 Jun 2018 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0m-POVfZZcrj for <>; Thu, 7 Jun 2018 14:00:46 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3D5F130F49 for <>; Thu, 7 Jun 2018 14:00:45 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w57Kw2Iw011222; Thu, 7 Jun 2018 22:00:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=92Av1cQzxtFuuvYRdXgRhuowsZsZyGnKEByN09Sdn/0=; b=axYfsjckv6i7Le6FLwKxWE8MVRAGgRLFhJZ8OqcsKustT0Z4PuIT4F8OMzCUf8Nx5vJS fp3FTtxonmcuVRLpTDz/RViOoL0qODNkOzJo9deJpYCkj+jvGdrlqWwpsarpvmZ1v8+d Pk6QNit/JmYA3RFtgoXORjhJZUUXwC+akPZBX25fTFx614JxvzP1AzvSpC0uz0nPUUJW xtKguXShcuYNfGFtuUfSXeSHeikuuFQiHLuZw5ABGdR1RRP1DMZvep5G4oS+X+4Cv9Zp 260anYIUknZzGI0uoNPKHcgowQQOdk4CD6NyDqU6Pi+MBAMp1XRRHUE9tm19tY9JT+RJ Yg==
Received: from prod-mail-ppoint3 ( [] (may be forged)) by with ESMTP id 2jf7331a57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jun 2018 22:00:43 +0100
Received: from pps.filterd ( []) by ( with SMTP id w57Kp28b011572; Thu, 7 Jun 2018 17:00:42 -0400
Received: from ([]) by with ESMTP id 2jbpjwrxgw-1; Thu, 07 Jun 2018 17:00:42 -0400
Received: from ( []) by (Postfix) with ESMTP id 11C832006F; Thu, 7 Jun 2018 21:00:42 +0000 (GMT)
Received: from bkaduk by with local (Exim 4.86_2) (envelope-from <>) id 1fR21R-0004ib-46; Thu, 07 Jun 2018 16:00:41 -0500
Date: Thu, 7 Jun 2018 16:00:40 -0500
From: Benjamin Kaduk <>
To: David Benjamin <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070221
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070222
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 21:00:50 -0000

On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> Hi all,
> Apologies for the probably record time delay in actually updating this
> thing. I like the graph... apparently -00 was expired for nearly twice as
> long as it was valid? Oops!
> Per the discussion from a really really long while ago, I've rebased the
> document atop TLS 1.3 and added values for the many more bits added in TLS
> 1.3.
> Since TLS 1.3 has server-offered extensions, this needed a bit of
> reorganization. For the one-bit PSK KE values, I borrowed the pattern from
> draft-bishop-httpbis-grease-00.
> Let me know if folks have any comments. Additionally, I'm curious what
> folks thoughts are on the following (not incorporated into the document):
> 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
> parse out the "ignore/" string. Instead, what do folks think about just
> using two byte strings. Perhaps the same two byte pattern we're currently
> doing?
> 2) This is somewhat of a "how much badly I abuse the registries" thing. :-)
> I have observed one TLS implementation which just transcribed the registry
> directly into their source code. This was done all the way down to mapping
> "Reserved for Private Use" to some dedicated symbol. They successfully
> ignored the private use value, but the actual unallocated values for each
> of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
> treated as syntax errors!
> This was just a single implementation, but it suggests GREASE works better
> when it's not so obviously allocated in the registry. Of course, not
> recording the values at all is unreasonable as we must avoid allocating the
> values for real. What do folks think about leaving them out of the table
> but instead adding a note in the registry like:
> "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
> 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used
> by [[this document]] for testing implementation correctness. They should be
> left permanently unassigned."
> An implementor infinitely bad at reading may well still special-case the
> and defeat all these measures, but that was always the case. Rather, the
> goal is to find inexpensive ways to lower the failure probability. It seems
> inexpensive to me, but I don't know how much trouble it would cause for

Unfortunately, (my understanding is that) IANA is moving towards a proper database
for codepoints, and prefer to actually have all values matched up with their
corresponding metadata; I expect that they would not be happy to do something
like this.  But, of course, we should actually ask instead of guessing...