Re: [TLS] Server-side missing_extension MUSTs

Dave Garrett <> Wed, 13 July 2016 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6060112B019 for <>; Wed, 13 Jul 2016 00:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4s1tFk5bp52T for <>; Wed, 13 Jul 2016 00:31:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2A7012B007 for <>; Wed, 13 Jul 2016 00:31:55 -0700 (PDT)
Received: by with SMTP id i12so35361227ywa.1 for <>; Wed, 13 Jul 2016 00:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=GcNXv9YoHG8rt7Iv3JQJakFxGMb0kxAdo+JhEZH4TjU=; b=TfHuTAqrCFp3EzsZ2xEgBis7Vxe6g5jhWqleolUi3I5/1u8W0gCLU0bFLDCpO0pR7A Lx4SQGLGrZ4k3VjPCDoUaxAMIQCzqFd/g4/dOEu5gZbVD7ARuvI1MZYpendidrN8ApoV 9ty7eN+7icHMBwMNlQRfR3u7WbdKmjWBBqNYQ86tMTdAUziZ/8pP75WtmRUJGVjgA8Lj IH8LglP27suPXxqJglKTAY4mYz4emF8otZrWUUrhjGpjxXIAYTfRWSF3btsuhdrXrxqY 6raoA28dJW+guiyoPRspFX2qTCHuXZelUUdvrhtrnPF5QWU5B1rD29PG7gWDwdoa00wL 0XTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=GcNXv9YoHG8rt7Iv3JQJakFxGMb0kxAdo+JhEZH4TjU=; b=P89DT387HD3ZeOClqYXXrfYjQtQkxk55yHrmuCuIGIS+i27Y9sK7+Q5BF3NNn1UxX4 wy7mbmSqY5NivccEcpJ7yp2stHMsZvXhj1nJ+5jrz2oNyeie3esHZ/jZkESc0nurlvex 61CknJCOHzNJWftmRHK8BQdSmFsZ15lkX/sHCTT5UCVAVcb37R64X/2820LHiCdv+Kdl UbV3qmfRKVWYXBAfOLcTlwygr8KIzfmzprxBAIpESt6TnYVlugJrQYBQK0brml1V4YA3 nbsdgy7inZNiBDZsX0OPvMRhG/AzaASIF9JUNIP/Id03ygvwthqHAKoPBtgvRxItjqHZ W8iQ==
X-Gm-Message-State: ALyK8tJqAea3eHpaR5XrPVhAQjxSQvLDTWAq543fzcG03aCUnNbzdotHQuEhjuzQd2c1/A==
X-Received: by with SMTP id q62mr4824369ywd.25.1468395114866; Wed, 13 Jul 2016 00:31:54 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id z185sm1290688ywe.33.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 00:31:54 -0700 (PDT)
From: Dave Garrett <>
To: David Benjamin <>
Date: Wed, 13 Jul 2016 03:31:52 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
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 07:31:57 -0000

On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote:
> 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've triaged TLS-related bugs in Firefox (to be fair, not as much as of late), which largely made me come to the conclusion that stricter and more precise error handling is sorely needed. I make no claim that this particular error in this particular case is the focal point on which anything practical I can come up with at the moment hinges, however I have seen too much nonsense to not advocate for rigorous preventive action. When we leave holes and generic responses in specs, the incomprehensible litany of implementations inevitably results in interactions that we are not capable of predicting.

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

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

We have to assume that some small minority of implementors are not acting in good faith to maintain ideal security, but rather are creating something just functional enough for their specific purpose (possibly a larger minority with IoT). If someone kludges an ad hoc client/server pair that skips the groups extension to go straight to key share, they could get it to work fine. (they're only separate because we are, ourselves, kludging in new features into an old extension, whilst maintaining backwards compatibility) If someone else then has to get this to work with a normal server, they're going to have to let this slide. It is a hell of a lot easier (from a psychological & political perspective) to just kludge in a special case instead of being forced to explicitly cancel out error checks/reporting that come directly from the spec. The more this stuff is left unspecified, the more risk we get of kludge-related breakage/exploits.

As a rule, I never assume something is impossible; you can always be surprised by the interactions of several kludges and a few lazy, sloppy, stupid, or malicious people. This is a 20 year old mess; paranoia is required.

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

I agree we should simplify negotiation, wholeheartedly. That is most certainly a better way to do things. I preferred we just require groups and key share for all TLS 1.3+ hellos, always, without exception. Much simpler, but pure-PSK (which I'd prefer was not in the spec) is the special case that complicates things here, and merging the two systems into one simpler one was rejected. (one always mandatory dh/psk key specification extension that is always used requires far less thought to sanity check) Just because a better system isn't used, doesn't mean I won't advocate for stop-loss on what we do go with, however.

To restate what I said in my other reply, downgrading the relevant MUSTs to SHOULDs would be something I'd be ok with. Servers MUST give an appropriate error when aborting, and SHOULD give the most relevant one they can provide at that time.

I do not claim that this here specifically is of top-tier importance, but I will generally resist all attempts to water-down constraints we had previously maintained consensus for.