Re: [TLS] MUST <x> or what?
Eric Rescorla <ekr@rtfm.com> Thu, 27 August 2015 20:06 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 DF6F71B3954 for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 13:06:54 -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 qJIZcyVGS70L for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 13:06:53 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 AF4981B382B for <tls@ietf.org>; Thu, 27 Aug 2015 13:06:52 -0700 (PDT)
Received: by wicgk12 with SMTP id gk12so2543185wic.1 for <tls@ietf.org>; Thu, 27 Aug 2015 13:06:51 -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=BP/4nNm6HWDD3u2FausXwgtvzcoz7YzdgEyGTc5pf5o=; b=Dlnd+tGU1zl+w1vOs9zD0ZtSZEvLhfE08PNHg7l0zzwr5s6I0Ke0cMNadNA+p79qd/ 6dQ6603lQMbXBUuZ8WIgMibyfxp4hWj1NIuwtOJTP1zeSZg/fqkmM2FJxYpoSVW7NhrT hbOXqkM2VBuY3Vy0rrg2uCtaIGc1WvdFKzQ4eQ/aD+bsY/TSVwPwNi/5Y9GwzxXFXDUK WtC0KhZhZlz3HG9CxZjBx835sQ/lbszRNfkySv00stGBvErUxFS9kpMlRVJayBz6Zn46 dyMomF/Y6gGkNfJgUG2rq/oBxux28/ur5I1Ep0YEO6X69EpEGGn5G1OxBG1wWScJ3BBi yPPw==
X-Gm-Message-State: ALoCoQnMerpeVos4q15Ji5MyQ9GRLK5JYIXgZYQ5FwuE3otiqV2S238+L722zd2Ykqa8Ev2/X9n3
X-Received: by 10.180.75.78 with SMTP id a14mr402047wiw.68.1440706011267; Thu, 27 Aug 2015 13:06:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 13:06:11 -0700 (PDT)
In-Reply-To: <CABkgnnWxZ_oMiBjnzyju3Loei5U5QvMFMQHUfcr+JAbWc89AHQ@mail.gmail.com>
References: <CABkgnnXFyuf_3pPs8ByJpbOGgPDb2XMfVOZAUA42bmJEB_Vynw@mail.gmail.com> <201508271519.49848.davemgarrett@gmail.com> <CABcZeBM5SiO1dh2YxkLcmgspYm-Ug3p_mWs_OypKiHcK-iqD_w@mail.gmail.com> <CABkgnnWxZ_oMiBjnzyju3Loei5U5QvMFMQHUfcr+JAbWc89AHQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Aug 2015 13:06:11 -0700
Message-ID: <CABcZeBOYUo0KTT8rtah_+ZDqdSrqJ5=kfTRGO84HqWgdywyPdg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0438eb9d071b62051e50829d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rjrSyr2KHIi17yDK-DDhbGeFYaU>
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 20:06:55 -0000
On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > The opposite in fact. NSS checks extensions first. That is how we filter > out ECC cipher suites if the named_groups extension doesn't list anything > we support. > Well, yes and no. We don't for instance check for the *absence* of the extension. -Ekr > On Aug 27, 2015 12:26 PM, "Eric Rescorla" <ekr@rtfm.com> wrote: > >> >> >> 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 >> >>
- [TLS] MUST <x> or what? Martin Thomson
- Re: [TLS] MUST <x> or what? Eric Rescorla
- Re: [TLS] MUST <x> or what? Dave Garrett
- Re: [TLS] MUST <x> or what? Eric Rescorla
- Re: [TLS] MUST <x> or what? Dave Garrett
- Re: [TLS] MUST <x> or what? Martin Thomson
- Re: [TLS] MUST <x> or what? Viktor Dukhovni
- Re: [TLS] MUST <x> or what? Martin Thomson
- Re: [TLS] MUST <x> or what? Eric Rescorla
- Re: [TLS] MUST <x> or what? Eric Rescorla
- Re: [TLS] MUST <x> or what? Salz, Rich
- Re: [TLS] MUST <x> or what? Dave Garrett
- Re: [TLS] MUST <x> or what? Peter Gutmann
- Re: [TLS] MUST <x> or what? Peter Gutmann