Re: [TLS] MUST <x> or what?

Dave Garrett <davemgarrett@gmail.com> Thu, 27 August 2015 19:51 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5271B3BF1 for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 12:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWQAd5hI4s-v for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 12:51:48 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5E91B3BD4 for <tls@ietf.org>; Thu, 27 Aug 2015 12:51:48 -0700 (PDT)
Received: by qkda128 with SMTP id a128so16839936qkd.3 for <tls@ietf.org>; Thu, 27 Aug 2015 12:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=6rzzzs9wvDzwW9VmxtON+/79EKXokVq/0YjRCxlewa4=; b=Q9Io7uxW6rKreAU/vSnDN/74kVtdJM/ppANEU0wry/0WBIcoZlU+twdG4JxmaUjJcP QTwer3eM6Kir/kqEBiV7p/6NUnPEojORuaip574I29Illrjgg7jX+aHqcGy88oM/ZKZx ef3d785dZMfeGJEwUDaOYE+MAZfPZR7wpTbKqK+TeYS9uccgWVQws7A9jpgrQ5mAoZsl r52wnugCkczwiQv4miyN5fI2xzQ3NCy6eRmbrrskadRNta636DnuyGmQodqamBu6hN7Q sCpvjt71ZJgFKa6g81J5qJ4zZeMwoiVn+acBx3eD61lrZ9X5UPJpKzQ1LxZ2oLivl4yP gJsQ==
X-Received: by 10.55.214.217 with SMTP id p86mr9770574qkl.75.1440705107874; Thu, 27 Aug 2015 12:51:47 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 44sm1851897qgg.37.2015.08.27.12.51.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Aug 2015 12:51:47 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 27 Aug 2015 15:51:42 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CABkgnnXFyuf_3pPs8ByJpbOGgPDb2XMfVOZAUA42bmJEB_Vynw@mail.gmail.com> <201508271519.49848.davemgarrett@gmail.com> <CABcZeBM5SiO1dh2YxkLcmgspYm-Ug3p_mWs_OypKiHcK-iqD_w@mail.gmail.com>
In-Reply-To: <CABcZeBM5SiO1dh2YxkLcmgspYm-Ug3p_mWs_OypKiHcK-iqD_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201508271551.42561.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/aRkwzyZFPAiiEN4vtWtiV1vB6A4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] MUST <x> or what?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 19:51:50 -0000

On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The way that
> many stacks work (for instance NSS) is that they negotiate the cipher suite
> *first* and then they check for the presence or absence of the relevant extensions.
> It's not clear to me that it's an improvement to require them to check for error
> conditions that are not otherwise relevant.

I'm not fundamentally opposed to having a hard requirement of an error check on negotiation, and basically a soft expectation on mere offering (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That said, categorizing the cipher suites and just doing a quick check for which categories are there and what extensions came with it is not a very complicated requirement. I'm philosophically in the "do it right or explode so it can be found and fixed immediately" camp when it comes to very clear requirements like this, but I'm aware that this is sadly not always the dominant thought process. :|


Dave