Re: [TLS] Server-side missing_extension MUSTs

David Benjamin <> Wed, 13 July 2016 14:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3980512D748 for <>; Wed, 13 Jul 2016 07:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.986
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2p_EH7OnZRre for <>; Wed, 13 Jul 2016 07:03:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53C5E12D815 for <>; Wed, 13 Jul 2016 07:03:01 -0700 (PDT)
Received: by with SMTP id 38so47034270iol.0 for <>; Wed, 13 Jul 2016 07:03:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pDUQPhyxdJmgVvXOzvmibPvdJ3phnb7UwEcc56HKt6k=; b=YcxmOjXLav1ggftGnQ/cGkuZ8CYuuJ+X3N65YwDNB7hYijWoN2DxYhxyjU5D8962+d CJS7wIKytbz0PBsLrQ6oXsZgUT1gQyrSjzzMmVSLw8LU4ZB2Xqx3Pt0TjkL19nqo0IA+ w65hLITfZrMPNjZnjjy13CYAju5Vo7dg6uMhQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pDUQPhyxdJmgVvXOzvmibPvdJ3phnb7UwEcc56HKt6k=; b=KUYWI9dDs8YjglKTxEXcnQPhEL9Y1hNLd3eLi/ecR11MSggoXuLlmt5INuJRyX59Mn qkJBkZ5orIEhrE+eRDHirUl/XYZVV6Sqx2X+pBr/YMNfBRgljbXRplb+SHsgvT2Ku+GA 3/2JUgygbWMCJ+LqooyMm4plxub7HmIWem4odET0965KMfATVIsofUktgKXeI/7guXMe E+RFnZgWEZbLyWoIkai0zSPX8qNQHB9eBBOklodHR+T3M+b1ESWcphBW5c8F5Tzv971c kLEkSg6b57zydQxqDrgRGsu7ctUaLGxKqQ+tGr4XJwq+Hn6fW82TeiWKqLkt0yNc1h5a U0dQ==
X-Gm-Message-State: ALyK8tLtT+ERlcg2ZkecTwJRTx1/6hp+tpkLHr2160L1GDJK6FfKUB/vN+nvkRJXPhVmqi+rsSMmzMsA+5FDK/b6
X-Received: by with SMTP id 79mr9994467ion.97.1468418580366; Wed, 13 Jul 2016 07:03:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 13 Jul 2016 14:02:50 +0000
Message-ID: <>
To: Hubert Kario <>,
Content-Type: multipart/alternative; boundary="001a113fdb5eddbcb4053784d72c"
Archived-At: <>
Subject: Re: [TLS] Server-side missing_extension MUSTs
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jul 2016 14:03:12 -0000

On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett <> wrote:

> To be clear though, completely mandatory extensions, at least as we're
> doing them here, are a new thing. TLS 1.2 relied on separate messages for
> stuff, but we're front-loading everything into the ClientHello to get
> reliable 1RTT (with the exception of HRR).

On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario <> wrote:

> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> > I don't believe an implementation which fails to send supported_groups,
> > etc., in 1.3 would ever leave a developer's workstation. It would not
> > interoperate with anything.
> it would interoperate with itself, and for some deployments that's enough
> of a passing grade... (Even if you do interoperatbility testing you
> do not check all possible permutations of features and settings)
> I wholeheartedly agree with Dave here, error definitions should be strict
> (both on the when and what to do). One, because it allows to better
> diagnose (in general, maybe not in this specific situation) problems.
> Two, because you can write a strict negative test case that actually
> checks for it.
Also something I have plenty of experience with. We're obsessive about
adding this kind of test in BoringSSL[0]. :-)

One doesn't need this alert to write a test for curve negotiation. Just
test that the handshake hits the usual codepath for there not being a
common cipher.

This semi-mandatory extension isn't new in TLS 1.3, depending on your 1.2
behavior. BoringSSL will already refuse to select an ECDHE cipher if
supported_curves is missing. 1.2 does not require this, but we opted to do
it for simplicity[1].


[0] If anyone wants to try, I'm sure there is an implementation-agnostic
TLS protocol test suite one could extract out of that. It would take some
wrangling as we cheat and condition on BoringSSL error codes, but the nice
thing is I've already built up a large battery of tests here.

[1] Previously we always picking our most preferred curve if the extension
was missing, like OpenSSL. But now our most preferred curve is X25519, not
P-256. It did not seem worth kludging that when we could just decline the
cipher. No one's noticed, so I would say that worked.