Re: [TLS] Server-side missing_extension MUSTs

David Benjamin <> Wed, 13 July 2016 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4CDB12D094 for <>; Tue, 12 Jul 2016 22:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vi0hqh4j1F-g for <>; Tue, 12 Jul 2016 22:24:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A6B412B01B for <>; Tue, 12 Jul 2016 22:24:05 -0700 (PDT)
Received: by with SMTP id m101so36615768ioi.2 for <>; Tue, 12 Jul 2016 22:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=byukqeAAnJI69lnSCY8iIKJXRuNQJmOTBOyJRYFOuK0=; b=TMnZOen++oekWsEogBZw3mEqvYUlNA7w3EJVlzZqvo2wCdoh/c5znQeLasHKckQ6Gv R9EmW5VXj8Pi8TPl3IJn33eJWdke/HGmuVhKimFk66uAVgIZ/2SMevqtOx40i1K9DYtz o/wMAzsNhFER/01PHUu1R6jLMV8eihCA411qwHVsRa0ctA1O1jeb3oYXXYBJi9fmIGX0 0572yIry96kxGB7meVkzs3FFiD63VlD8UYcvz17gwNtwr9lDA2t6Xmv37WqKQbQyXOCh dcwFQrVBHEAYEw0XszyvxFTn/XHoS+PJJMuI++5hWGAl5F5jc0RWM8pdfJ3vHK6Vn/1F 4zow==
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=byukqeAAnJI69lnSCY8iIKJXRuNQJmOTBOyJRYFOuK0=; b=Z/DOHs0vs+5uo153QE091itu9x+QyE52PHUCH12YptE7JtpHLwwNP1Ic2+mrBvzlOC A8QfbQQ6wOx3ZEy6+h4QPRs3wowBeHbisRmWpgIW/D0foMsXt1/U6unrjToDt74ahb33 Qg4AMclL+Ak13yircgt6s0bKlYand3tlnhaSVoNFbKH2KynTsJVNlX6c0N317/ghMIXD H6Uwb01bGzRSFTEYe6qM6otXgDp7k5gbw0ATghCGCRl5JW+kjWHjh/lSI1dX6UPkXnle 5YEVym24L5XbcHAxlT6VoDt/L1x6b1ebZd/Kxg2+/zMWYfh9bSXQZ8TxsRs605V/ycC3 lesA==
X-Gm-Message-State: ALyK8tI2e2YlxL0QScz0d9DTKjKZAlZodAGV0kiKz4nsiwJVlpbY63tbrDH9/yAgqCaH/dxKxhO2z7xYUS+PUFSu
X-Received: by with SMTP id b25mr7471117iod.110.1468387444262; Tue, 12 Jul 2016 22:24:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 13 Jul 2016 05:23:53 +0000
Message-ID: <>
To: Martin Thomson <>, Dave Garrett <>
Content-Type: multipart/alternative; boundary="001a113fb596025f0805377d9864"
Archived-At: <>
Cc: "" <>
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 05:24:06 -0000

I'm also curious what cases were you envisioning missing_extension to be
useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so
I'm certainly not blind to TLS handshake errors being difficult to
diagnose, especially on the client. But I don't believe such an alert would
ever have helped me. Perhaps I am missing something?

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. Such a client is completely failing to
implement the protocol, and in a way that nothing would work. Difficulties
usually arise not here, but with more complex cases. Where we have interop
against some peers, but not others. Where all protocol messages are legal
but, due to different configurations on either end, no set of parameters
could be found. Where the connection would have succeeded but for, say, a
recent RC4 removal.

If we wish to address the diagnosis problem, we should think about those,
and also how to simplify negotiation so the kinds of errors are less
complex and reporting them is simpler, rather than get distracted by


On Wed, Jul 13, 2016 at 12:18 AM Martin Thomson <>

> On 13 July 2016 at 13:22, Dave Garrett <> wrote:
> > I am aware that discussion ended up on accepting sloppy error reporting
> as acceptable. Changing the disputed missing_extension alerts to SHOULDs
> would be an acceptable compromise if that decision is still actually going
> through.
> "sloppy" is a bit of a mischaracterization.  There are good reasons
> for this decision.
> It allows implementations to be structured differently.  In
> particular, if there are two relevant error conditions, different
> implementations could discover them in different orders.
> MUST-strength requirements on alerting for one of those conditions
> means that you have to order your checking in a particular way;
> MUST-strength requirements on multiple concurrent conditions are
> basically impossible to meet.
> It also allows an implementation to decide that abrupt cessation of
> communications is preferable to generating a report.  That can be
> important for DoS mitigation.
> In the end, we concluded that you shouldn't lie about error
> conditions; if you determine that there is a missing extension and you
> decide to send an alert, then it has to be the missing_extension
> alert.
> David's PR goes to the core of the first of my reasons here.  The ways
> in which servers decide on the things like version and cipher suite
> when presented with a ClientHello is in practice hugely different
> between implementations.  That's healthy, but it does mean that we
> need flexibility.
> _______________________________________________
> TLS mailing list