Re: [TLS] Keeping TLS extension points working

David Benjamin <davidben@chromium.org> Mon, 25 July 2016 23:32 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 AA1B912D8E1 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 16:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 dWnIdPyN-XPZ for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 16:32:53 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 E51CF12D94E for <tls@ietf.org>; Mon, 25 Jul 2016 16:32:52 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id l69so138713997lfg.1 for <tls@ietf.org>; Mon, 25 Jul 2016 16:32:52 -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=RrAfIjjZtxAVlg20FCcohbgaqytYMmkgzIZoqJepLIY=; b=SuGXN1Vw0s3jz+VByHeSR7u0Mapz/sFjsH9c8CIkZO75k5d5+KFvlKjqaHOAVGnwVV RZ2CfrE8/0cpgCtdYwIoK2yxvLZCFeo5REyKtmLxBBh6T/jaI58+cUohAou/8kJUriwl XTgwvuNC86pl7s/9dMAhTRKK3G/pOsPthECGk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RrAfIjjZtxAVlg20FCcohbgaqytYMmkgzIZoqJepLIY=; b=NhCuVAyoNC5neV2/k32v3MbHfmsfpBKa1BNgpWFXklqx94LU0QVC/n6GA5aMa8Dna6 XFKFBGhpBWcEZv3G47Rk37aaYoSK0fq6WAjU10dr2ngK/oFtppgw2wGJXzQm3R1GM44e sZhP98I5cCZJNWklpmQslxsjjp9nVvLb6ScozqxpZpFzwhMwTuHr9ERZ+A90G4OCmxn/ oU4avWi/jJsL2rMWwDDRFMoRaQcK1VNELKNINV4wxvlOBpyivVBSh+sBomTkNMO79ScB Esw2Wa4AoMcyLvgNlr7GggFPdCJElUvKkx6BpxOZ2nsjRlXkIb9+OUEzPPGkOTQj3dPu v1aw==
X-Gm-Message-State: AEkoous8NjiLaTBuwCsXXpQ0rOe2BObGjRhuVBwxDTSMsWMWihMeaPaAofkPw//ugwhAG+nylYjKqZMHbAIZsDUi
X-Received: by 10.25.168.212 with SMTP id r203mr9442546lfe.85.1469489570909; Mon, 25 Jul 2016 16:32:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <20160725232307.GJ4670@mournblade.imrryr.org>
In-Reply-To: <20160725232307.GJ4670@mournblade.imrryr.org>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 25 Jul 2016 23:32:41 +0000
Message-ID: <CAF8qwaAOHox+dKMmKZYV2c35MWLyDn7W-_F6SOJ0WsChXCF_Yg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a114032a2e068fb05387e33a8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0l0v4-qjIxeIIkX-sK4ALT9bKlo>
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 25 Jul 2016 23:32:58 -0000

On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:
>
> > I'm not sure how this process usually works, but I would like to reserve
> a
> > bunch of values in the TLS registries to as part of an idea to keep our
> > extension points working. Here's an I-D:
> >
> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
>
> To really make this work, it would be necessary to expand the
> reserved pool gradually, rather than all at once, so that servers
> can't hard-code just the initially reserved pool, and still fail
> with new "real" extensions later.


My hope is that, especially with the values allocated sparsely, after
getting interop failure once or twice from unknown values, the servers will
quickly figure it out. I'm assuming the implementations simply made
mistakes or weren't paying enough attention to the specification rather
than being actively malicious.

But, you are right, one failure mode here is implementations may
"accidentally" hard-code the reserved pool... somehow.


> Add a new code point every year
> for 5-10 years, and eventually servers will have extension tolerance.
>

To clarify, this is about making sure new implementations don't ossify the
whatever set of named groups (etc.) they observe, not flushing intolerance
out of existing ones. For existing ones, it'd be equally difficult to
deploy, say, GREASE for named groups as it'd be to deploy a new named group
to begin with. (Fortunately, we successfully deployed a new named group
just this year, so this is the perfect time to do that.)

David