Re: [TLS] Server-side missing_extension MUSTs

Dave Garrett <> Wed, 13 July 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7111612B03C for <>; Wed, 13 Jul 2016 10:28:23 -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 7m7lzdHqfipb for <>; Wed, 13 Jul 2016 10:28:22 -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 DAAD512B02C for <>; Wed, 13 Jul 2016 10:28:21 -0700 (PDT)
Received: by with SMTP id j17so50295331ywg.0 for <>; Wed, 13 Jul 2016 10:28:21 -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=oNjCAB6bmyzRz9m/qbGQCGza3BddMoNhy/C3rSfNQFk=; b=WWUS8y+eZzfAUCj7oD9XtSkEjaKJQ5g3lNfW0nkjAK3+b7ad5EO1HWhNla7ipT3J3j 9xoiy2nNKTu+QBaEr6lcjqEjyJjoA/z+Krdb0i3rWauQ/JxmDU2EjB0sRVREysIu+6wX O73A7nVy2pVFmw69Fr0Kc1SwwJp6P7s7zFvc5EHpQWe2sNoqsnG7iySjo5IbCUxU7R1D g8VgZAxZJ2Oz8qfna982RnrvqoPmMNh+SVSpBxYnmuJUP5UgW9AZgjCyCBD6ezqfDjIt ck/VIn3Bvrgpja4bdiNltuK8b8WIp8FNg0CcXZi6sap7wsgzLQIZ0hFDXKLsiEWeGeFY qKkQ==
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=oNjCAB6bmyzRz9m/qbGQCGza3BddMoNhy/C3rSfNQFk=; b=UNbSVZf92srIt1mow34Ot4UeMOZy1PSixEoFDgEG/ubfqkCeJ6qccRFs2ht1jNUoN6 pPTvzXuQQFiTK4gA8Kz1uHxn9lSojqZ3bis+Jc2O6G6bvRKh+jduKiE7qlB8jOGTav1y g066HGD23ZpPyXa4pLtbOnmjOEyPBSRrx604aMQzMJlk4tQtSM3sHa72MuEdBp4BAJ18 Lmf+KWjpcmgbxLf5VRcfhFg5C2pX0CMazqrpvnxefwUYaX8+wfPrWAKQMh/D7+yAB5CZ oYXgWOoyCT/ujiOV2GYM4/YdxNEpPQE2tFCZjYVr9OWn9/g9VC2G15laOou/GbYKyGCp eAZg==
X-Gm-Message-State: ALyK8tJ9YOQqkfTFwbm2iQ1GMyamJdXnxZtBmynUIlGH03974nk1Nbwdb83Bgqi4kTf5ZQ==
X-Received: by with SMTP id a131mr6756466ybb.1.1468430901189; Wed, 13 Jul 2016 10:28:21 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id u187sm2180347ywu.27.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jul 2016 10:28:20 -0700 (PDT)
From: Dave Garrett <>
Date: Wed, 13 Jul 2016 13:28:18 -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 17:28:23 -0000

On Wednesday, July 13, 2016 01:01:13 pm Eric Rescorla wrote:
> It's natural to pick the cipher suite first and then look for the key_share
> extension, so if, for instance, you pick a PSK-only cipher suite, then you
> wouldn't look for the key_share.

Agreed. That's why I'm ok with the current "no alternative cipher suite is available" qualification. If the extension never comes up, then not giving a specific error for it is allowed.

On Wednesday, July 13, 2016 10:43:58 am David Benjamin wrote:
> To be clear, I am not at all opposed to useful errors or strict policing of
> what the peer sends. 
> Complexity is the currency we pay for adding things.

I very much agree. Our debate hinges on risk assessment, which gets admittedly hard when talking about unknown future implementations. ;)

Essentially, the design philosophy I and Hubert are advocating involves mandatory validation of inputs by all implementations such that we focus on avoiding divergence from what we all agree to in the spec, rather than always try and use our imagination to enumerate each individual screw up that could be made.