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

David Benjamin <davidben@chromium.org> Wed, 06 June 2018 19:08 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 40D3212F295 for <tls@ietfa.amsl.com>; Wed, 6 Jun 2018 12:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.951
X-Spam-Level:
X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 5S2wnGw9GE67 for <tls@ietfa.amsl.com>; Wed, 6 Jun 2018 12:08:42 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 17BA0129619 for <tls@ietf.org>; Wed, 6 Jun 2018 12:08:42 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id w23-v6so4682476qkb.8 for <tls@ietf.org>; Wed, 06 Jun 2018 12:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5xObDPTJbs0zoUfW1GLQxTMt0RgbxuAFOt8S7n+dlok=; b=SvsdrLkRIp7Uqv4SXfxdvu0TJugxrQheKR/nBaYM+clQypiJq7zaL0L9MYXbsqTGvu hoapKUbRBJtPkPVoDvYEuwHJxuhNMK2RYR2qikDyczQ+mPlGfkvB8wdDZpe10ZOxdZNS J2+Z9cJ256WKKBNL0MnmWxc3cV9xzBXvCZOJk=
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; bh=5xObDPTJbs0zoUfW1GLQxTMt0RgbxuAFOt8S7n+dlok=; b=IpfpdinuxqS8xKkVJviMbSfmHYQaIIVEd+UqEFC17M+qsSVE1EMcGsqzJ1nNr4uckc cEGpWq0xAEwLAfeU86MvsB+X+KJvopMbxUASBi0wnVM6vF1Bs8XybXZYVuCFy9q/2RqE OdN5MIZf03CIsNJScr+1AfzQAzxir28eFdwMcj//DTbx+pjhWS//vieVzdxq66tfsZ59 Z88U0gnz7Pe0YLQw6LXQVZpqXAp134wupNdMs89Q6jOCLLmxwyGvYzAsMxZfbh10BJg1 czZOfgcGoxDQhJsAc3epjY1RMSTa+HfE9Jm0Pyoxt7qMZgNEBPyRWOZFxQqv97+UuaFq ClFg==
X-Gm-Message-State: APt69E34fgeOCRcAgogtoB8LYVcQ+iUaVsxXl8i9+HYMpEJGeT2BhpoD eFZaKYlFSkHFpn/N/vQs+YxhZ2xJXzE/K2JZ8AEVHwA=
X-Google-Smtp-Source: ADUXVKJVuLsAQFvZEsVQMb8w22CrC7rDRW/7r6uYI5Kswdb6+JNAdY9A1ZzBupwIhTgvw+1ZZ4at2iOtdsPVHMnKDW0=
X-Received: by 2002:ae9:dc81:: with SMTP id q123-v6mr3831439qkf.318.1528312120638; Wed, 06 Jun 2018 12:08:40 -0700 (PDT)
MIME-Version: 1.0
References: <152830634989.6264.3566629916218895862@ietfa.amsl.com>
In-Reply-To: <152830634989.6264.3566629916218895862@ietfa.amsl.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 6 Jun 2018 15:08:28 -0400
Message-ID: <CAF8qwaC+NpLo1c=7KTD02-Wjo5Akp+5GtCF9ZBs8iF=Jtun1Vg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000f5e34056dfde566"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZZvAqk46z7fJMx1tS4MtLmJSmFQ>
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: Wed, 06 Jun 2018 19:08:46 -0000

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.

David

On Wed, Jun 6, 2018 at 1:32 PM <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
>         Title           : Applying GREASE to TLS Extensibility
>         Author          : David Benjamin
>         Filename        : draft-ietf-tls-grease-01.txt
>         Pages           : 10
>         Date            : 2018-06-06
>
> Abstract:
>    This document describes GREASE (Generate Random Extensions And
>    Sustain Extensibility), a mechanism to prevent extensibility failures
>    in the TLS ecosystem.  It reserves a set of TLS protocol values that
>    may be advertised to ensure peers correctly handle unknown values.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-grease-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>