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

Benjamin Kaduk <bkaduk@akamai.com> Thu, 07 June 2018 21:00 UTC

Return-Path: <bkaduk@akamai.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 7CEB8130F58 for <tls@ietfa.amsl.com>; Thu, 7 Jun 2018 14:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 0m-POVfZZcrj for <tls@ietfa.amsl.com>; Thu, 7 Jun 2018 14:00:46 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D3D5F130F49 for <tls@ietf.org>; Thu, 7 Jun 2018 14:00:45 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w57Kw2Iw011222; Thu, 7 Jun 2018 22:00:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; 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 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. 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 (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w57Kp28b011572; Thu, 7 Jun 2018 17:00:42 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jbpjwrxgw-1; Thu, 07 Jun 2018 17:00:42 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 11C832006F; Thu, 7 Jun 2018 21:00:42 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fR21R-0004ib-46; Thu, 07 Jun 2018 16:00:41 -0500
Date: Thu, 7 Jun 2018 16:00:40 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: David Benjamin <davidben@chromium.org>
Cc: tls@ietf.org
Message-ID: <20180607210040.GA13834@akamai.com>
References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <CAF8qwaC+NpLo1c=7KTD02-Wjo5Akp+5GtCF9ZBs8iF=Jtun1Vg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAF8qwaC+NpLo1c=7KTD02-Wjo5Akp+5GtCF9ZBs8iF=Jtun1Vg@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tls/ucj71nEnG0cv0HpWJOqakE4bfKk>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt
X-BeenThere: tls@ietf.org
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." <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, 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
> IANA.

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

-Ben