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

Eric Rescorla <ekr@rtfm.com> Thu, 27 August 2015 19:26 UTC

Return-Path: <ekr@rtfm.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 E6A8C1B3D12 for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 12:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 XJLrUVkd--iK for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 12:26:45 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 BEAF01B3D11 for <tls@ietf.org>; Thu, 27 Aug 2015 12:26:44 -0700 (PDT)
Received: by wicge2 with SMTP id ge2so2632755wic.0 for <tls@ietf.org>; Thu, 27 Aug 2015 12:26:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t4yDEN3SE3XBoy3HDzkS9BDI7b2FhOCtXZaA2cIAtrE=; b=jgnBXPlWuvd9Zvz4Tv55XAxE98+YaXu/LSBTw/fqsWLecrmjOlXFWRJudJ84eTCvpS 3iM2pJZR5oSScraOOYFGR8huMm07kn6RLkGuhJKos7J4zAFiB86c5aqiGB5Xxk6NKjoQ OKLq3ru1rGm0BRePHFLLlIArOtg2VXvaFDXFFIX0eNrPRei7KaCv+AyOLvZ0JjEe9WAg CF56B7Mey5tXPSrUBAHsfPFGPB+wGSFpvH9Y6XMC07ws9deWXibF907z7SoAc7aXLYeW cTWGViTLTl/q0byn6gIxxNYDUrXF4Xk+XHJzB524sjRpuMau3vvUYrw45/lN8gUP5NY6 F72g==
X-Gm-Message-State: ALoCoQmnrDsezJdqwCD6DJC4VkCYZ3aUpfx0ktHWiqf5bFIywH43OxutoFFEH9MCN77xGPzLSX54
X-Received: by 10.180.73.244 with SMTP id o20mr225406wiv.31.1440703603422; Thu, 27 Aug 2015 12:26:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 12:26:03 -0700 (PDT)
In-Reply-To: <201508271519.49848.davemgarrett@gmail.com>
References: <CABkgnnXFyuf_3pPs8ByJpbOGgPDb2XMfVOZAUA42bmJEB_Vynw@mail.gmail.com> <201508271519.49848.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Aug 2015 12:26:03 -0700
Message-ID: <CABcZeBM5SiO1dh2YxkLcmgspYm-Ug3p_mWs_OypKiHcK-iqD_w@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0435c06a824e12051e4ff2fe"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NaXUtkbu56aKsTp14JSX-u6r9CE>
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:26:47 -0000

On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> > 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}}).
>
> Some changes to this are now in this PR:
> https://github.com/tlswg/tls13-spec/pull/231/files
> (language based on list discussion)
>
> > > All implementations MUST use the "signature_algorithms" extension when
> > offering and negotiating certificate authenticated cipher suites.
>
> Actually, I did get a strict requirement in there for that one:
>
>
> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms
> > All clients MUST send a valid "signature_algorithms" extension in their
> ClientHello when offering certificate authenticated cipher suites. Servers
> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher
> suites without this extension MUST send a "missing_extension" alert message
> and close the connection.
>
> I think it warrants repeating in the MTI section as well.
>
> > > All implementations MUST use the "supported_groups" extension when
> > offering and negotiating DHE or ECDHE cipher suites.
>
> My initial draft had similar language, however ekr says the WG doesn't
> have consensus to be more strict. I would like to consider all of these
> extensions as mandatory to send, and malformed if not present when
> offering/negotiating any applicable cipher suites:
> signature_algorithms, supported_groups, client_key_share, pre_shared_key,
> server_name (though, I'm fine with a SHOULD error on lack of SNI when
> applicable


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.

-Ekr