[TLS] MUST <x> or what?

Martin Thomson <martin.thomson@gmail.com> Thu, 27 August 2015 18:48 UTC

Return-Path: <martin.thomson@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 40C561A1BDF for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 11:48:17 -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 sCHkFthwt-gW for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 11:48:16 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 0F3331B2E6C for <tls@ietf.org>; Thu, 27 Aug 2015 11:48:16 -0700 (PDT)
Received: by ykbi184 with SMTP id i184so29972975ykb.2 for <tls@ietf.org>; Thu, 27 Aug 2015 11:48:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fwVGps26P1BE87NBFFia7MVfRPlZLIGEx2jwf0ENCx8=; b=SOLbneCjh5igVlHi4fqhupgxCxyN0++g72H6ywkDMQATxajPjcWjUadWHpNndKXc9J YlJj6yUWbHXmXeh+zgWH2pEiwLcsXp5PR66q4G7VlAT4ZFbgEpmy04qlLvAjX3TRYo0S nDW4Ssye/yDMaO67k9jsHxIRUMS52/E5Zx2TaGnVy+yo/T5TURK/YHwRNaWyB17zGsMW Ax3N2mgoGZRIIURl20FF/7k7IDNmQhSMLlaQF2w29tx0cL5skx9YDO7YKSiMSkGeb7e+ /+SceOKbXVy++ZY0gPRFmoQO6MRjxN6WGLvLFML8P7FT5ugc/ghysuVLesU20MaiL7A/ q/Fw==
MIME-Version: 1.0
X-Received: by 10.170.57.202 with SMTP id 193mr4734934ykz.118.1440701295300; Thu, 27 Aug 2015 11:48:15 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 11:48:15 -0700 (PDT)
Date: Thu, 27 Aug 2015 11:48:15 -0700
Message-ID: <CABkgnnXFyuf_3pPs8ByJpbOGgPDb2XMfVOZAUA42bmJEB_Vynw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/n-C3qkxm6XHVEhpssStv49_mpFU>
Subject: [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 18:48:17 -0000

I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless.  To pick on a recent changeset:

> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).

> All implementations MUST use the "signature_algorithms" extension when
offering and negotiating certificate authenticated cipher suites.

> All implementations MUST use the "supported_groups" extension when
offering and negotiating DHE or ECDHE cipher suites.

This isn't good.  "MUST" language MUST have consequences or you are
left with all sorts of variations.  If you don't stipulate
consequences, then people violate the MUST and you get interop issues.

I propose that we don't do this in future without due consideration.
In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.

The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons.  For TLS 1.3, I think
that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello.  I think only the ClientHello.