Re: [TLS] Server-side missing_extension MUSTs

Dave Garrett <> Wed, 13 July 2016 03:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9156512D8B2 for <>; Tue, 12 Jul 2016 20:10:22 -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 3684xe8JID1p for <>; Tue, 12 Jul 2016 20:10:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF89212D7BC for <>; Tue, 12 Jul 2016 20:10:20 -0700 (PDT)
Received: by with SMTP id l125so31781828ywb.2 for <>; Tue, 12 Jul 2016 20:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:cc :mime-version:content-transfer-encoding:message-id; bh=rS1eoe/54WQ9yhqqLMCLBdpUpF8GMedFAJU7L46RyHM=; b=D+3LC72Osnbv878F7049afZY0vo3bDFGU2UwSRP8vQ1clyzvKPyP4e7/rsm4AInmQh +SJwydcWNqW1hGDJf9xHYoAbHo2If8tT0zpXaeayyOILnFRXCYNuhx7rKZRYdpPmSMYa pDQy/5o55ffO9G20XpFiCXNFlP63xuRidLbFJ5mcLxl+eT6DGKfzwCKClT9JOYc98bhu SI0LGH+1paLjzCcbOFCedYkNq1nWadHqyzGLlHBYqopXMU0futyh4abUyygNmHN0gwDr XKZ8EEhjuMwIDyQnBWBIh2lWserlzNNyYOZQIVsihCb0ymHcWe2TwGj+KIys8uy9A6CH a/ng==
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:references :in-reply-to:cc:mime-version:content-transfer-encoding:message-id; bh=rS1eoe/54WQ9yhqqLMCLBdpUpF8GMedFAJU7L46RyHM=; b=C5w2fzSFLGlDK3GPqjY1LrBtzWPCJ03JIXb9XVv8s8hTHPNfH7ofhLgCuzRJ6JKrmQ ymngqMV5AmRaeNTIUbAHvcH+elcHyNNTU0zB+Z31Q+8nufbl8nd04dAcUKosVKtuH7Cf asN+WYorw6AtXHp+niFJCF3cUulYH+IDQaJRghBE7IIVcGevwU1TKNW64M+s/MH2x3+2 XbY8iUksuZEJBooGViqgDN0rPy91EWMHEG9GuShZkQ8YZ6BxsN0X1Cn83owjPFM20Kv/ Md//Lv81RkgHj0YVMK34DtA/cSZEgfCFEAe4peyDYIsliUoAtmcHDSnZ7LB0DS7NzBRT O3CQ==
X-Gm-Message-State: ALyK8tLRsCcvYALln+ezDru+KqG68VvuiKODpovYO4buYfTX4MS/QYpm4VKClXqGmQZmqA==
X-Received: by with SMTP id s186mr4365572ywf.267.1468379420057; Tue, 12 Jul 2016 20:10:20 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w185sm793055ywe.45.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jul 2016 20:10:19 -0700 (PDT)
From: Dave Garrett <>
To: David Benjamin <>
Date: Tue, 12 Jul 2016 23:10:17 -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: <>
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 03:10:22 -0000

On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote:
> I would like to remove the missing_extension MUSTs on the server side. Full
> justification in the PR.
> On the client, it is perfectly feasible to mandate a particular alert
> value. The check is very straight-forward. On the server, however, this is
> a mistake. Servers do not necessarily have full information if not all
> advertised ciphers are known, and a natural implementation of the
> negotiation algorithm will not output this case. Even without this clause,
> the handshake is already required to fail, so there is no risk of invalid
> clients being deployed.
> Adding more complexity to an already hairy negotiation algorithm (the
> pseudocode I mentioned is incomplete) just to diagnose what is an invalid
> ClientHello anyway is not worth it. It buys too little for the complexity
> cost.

Reporting errors sufficiently is not an inconsequential issue. TLS has many interop issues with servers which just stare blankly back when something goes wrong, or fail in ways which do not indicate why. This general topic has come up as a problem in discussions here before. We need to specify how to fail appropriately such that when it happens, it can actually be diagnosed and fixed easily. The alternative is people sticking with the status quo forever. The only way this adds complexity is if you assume you're only writing the client and server for themselves, not expecting to interop with unknown peers.

First of all, as to not having "full information", I don't think anyone expects a server to be expected to pick the exact error alert if it can't even parse the cipher suites in question. When a server just skips over an unknown suite, if a missing_extension was technically correct for a server which could've understood it, then it doesn't really matter; the lack of that extension isn't what's causing the failure, as it never gets to that point.

To respond to your pseudocode in the PR, I'd say that explaining the expectation is simpler with a try/catch model: just assume that the required extensions are present, do whatever you do, and throw a missing_extension exception to trigger said fatal alert if at any point that fails to be true. (if you're using a language that does not have exceptions, you can of course do the same thing, just differently; this model just makes stating things simple)

The current wording in the draft has "and no alternative cipher suite is available" added in there, as selecting another suite that doesn't care about such a fault was agreed to be passable because requiring further validation after an acceptable suite+variables was already found was agreed to be excessive. However, we do not mean to imply that you should go _looking_ for an alternative if you're evaluating a suite and the required extension for it is missing. I would generally advise against adding workarounds for implementation flaws you've yet to actually encounter, as all you do is make it harder to detect and fix them when first created.