Re: [TLS] Allow NamedGroups from the server?
Eric Rescorla <ekr@rtfm.com> Thu, 22 October 2015 13:30 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 C2C7C1A898F for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 06:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
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 XGBw1P785WG1 for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 06:30:02 -0700 (PDT)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 769501A8A59 for <tls@ietf.org>; Thu, 22 Oct 2015 06:30:02 -0700 (PDT)
Received: by ykaz22 with SMTP id z22so82458021yka.2 for <tls@ietf.org>; Thu, 22 Oct 2015 06:30:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vZegLwJbUthZGbhl1BpS3U2uC1aFUjd+kdmLT3V0gB0=; b=oZr9gf4uOLNXzoEjOxGyd+n3nqNm29FDoSBczjYyUFmcYs1sBXA/+uxFvqgwpz8Zzy N3i8n7VGX9Qzo+oqKbouXpXKK8TSWjARGnlkEuv1wvlt/G/Tja/SHDCTNq0M6hv2/AN3 q4CbQQPnAYErH1EeRXi8UgFMq6E0DTq6dU0vdaGNaF15KCsiuXDewIoQi0OGNzqJ7qPL Zq6J6TBCw+tctxtM+tP7hra/9AvyNEHP+y3RrqUaQsyfTvTbBCTsXapKDZ5N8pG1VUr+ GxTwdj3G8gVh1IZnT94O5bgCf9YaaXvls35mSZr8Pp4MBkN+sG7Wt9bVANHCnr3cNpud oZcg==
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=vZegLwJbUthZGbhl1BpS3U2uC1aFUjd+kdmLT3V0gB0=; b=MFq7/SvoYXGMIqz2YvGVIxgZ+5wPvjhACgS2Q+X2sNzCru7U6UF+Wj+2ycbPeD8P0K xUmQx0LS4J2uvbo07QVVvAGtftHmVcLp7lKSpvAmKXMhb1VyYrBCFHCjOcaXmx1ehH9d pNexvmiwsaCvh2Vrkg9NeRtX83pAwa/DHJTX7eBoOQ8lN4X3C3RHsktxGz+pv/f+6RN0 imewl0ebOSEhbHfHnzoWWBJ6shFY+yceE8Y21nwtBWPxWktlR8KpPJqczqRkTWUiMgyx FS0KHATA1efZq/ZfHagWuOyPZaBHz8xwpE6IOIW+3AuVXMEfpZlt05Fo5QHPAeL9pRGb 2gYg==
X-Gm-Message-State: ALoCoQnemxySt0FBERozXzWlgA0i/KhThrPOdNd4nxiGiP/kdM69RtQyjWpPrpFosF40xO9/Rx0h
X-Received: by 10.129.130.6 with SMTP id s6mr11027748ywf.155.1445520601807; Thu, 22 Oct 2015 06:30:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Thu, 22 Oct 2015 06:29:22 -0700 (PDT)
In-Reply-To: <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>
References: <CABcZeBP-xz0UAyizac9ScxFjEbBkRYZ0CnY8xabEdtFONJf_sg@mail.gmail.com> <20151022125557.9B1651A31C@ld9781.wdf.sap.corp>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 22 Oct 2015 06:29:22 -0700
Message-ID: <CABcZeBNikLAxO45+zryRjXD1f3jbKKjqbwtYWsVLqOjKAC9kHA@mail.gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary="94eb2c07c35efcaffd0522b17d9d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YcXmIsf339KwXpoLihtMmaGY8Nw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Allow NamedGroups from the server?
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, 22 Oct 2015 13:30:09 -0000
On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex <mrex@sap.com> wrote: > Eric Rescorla wrote: > > Dave Garrett <davemgarrett@gmail.com> wrote: > > > >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: > >>> https://github.com/tlswg/tls13-spec/issues/292 > >>> > >>> Presently, RFC 4492 only specifies the EC points it can support in > >>> ServerHello, but does not let the server indicate which EC curves it > >>> supports. Unless I'm missing something, this means that there's > >>> no way for the server to indicate what groups it would support. > >>> > >>> That seems less than ideal. There seem like three options here: > >>> > >>> 1. Put it in CertificateRequest > >>> 2. Send it in ServerHello > >>> 3. Do nothing. > >> > >> I prefer #2. I don't think encryption is necessarily required for this, > >> but EncryptedExtensions is fine too (Martin's 2b). > >> > >> I'm generally against putting it in CertificateRequest, as we're reusing > >> an existing hello extension so keeping it in a hello message (or it's > >> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients, > >> though) > > > > > > This would need to be limited to 1.3 in any case because in all the other > > cases it would be illegal. > > > Why do you believe that it would be "illegal" for a TLSv1.[012] server > to return a "Supported Elliptic Curves" TLS extension in ServerHello > in response to the presence of such a TLS extension in ClientHello? > > rfc4492 does not define semantics for the presence of "Supported Elliptic > Curves" TLS extension in ServerHello, but on a quick read, it also does > not prohibit including/sending it. > > https://tools.ietf.org/html/rfc4492#section-5.2 Well, the draft says that it is defining two ClientHello extensions (supported elliptic curves and supported point formats) and that it is defining one ServerHello extension, so if the server is sending supported elliptic curves it's doing something undefined. I don't think you need to have an explicit prohibition to suggest that doing something undefined isn't great. >From an implementation perspective, I wouldn't be surprised if client implementations choked on the server sending this. I had to check to see if NSS would do so. It doesn't, but given the way the code is written, it wouldn't have surprised me if it checked that all extensions were handled and choked otherwise. -Ekr > > -Martin >
- [TLS] Allow NamedGroups from the server? Eric Rescorla
- Re: [TLS] Allow NamedGroups from the server? Martin Thomson
- Re: [TLS] Allow NamedGroups from the server? Andrei Popov
- Re: [TLS] Allow NamedGroups from the server? Dave Garrett
- Re: [TLS] Allow NamedGroups from the server? Eric Rescorla
- Re: [TLS] Allow NamedGroups from the server? Martin Rex
- Re: [TLS] Allow NamedGroups from the server? Eric Rescorla
- Re: [TLS] Allow NamedGroups from the server? Andrei Popov
- Re: [TLS] Allow NamedGroups from the server? Eric Rescorla
- Re: [TLS] Allow NamedGroups from the server? Andrei Popov
- Re: [TLS] Allow NamedGroups from the server? Martin Thomson
- Re: [TLS] Allow NamedGroups from the server? Martin Rex
- Re: [TLS] Allow NamedGroups from the server? Eric Rescorla
- Re: [TLS] Allow NamedGroups from the server? Andrei Popov
- Re: [TLS] Allow NamedGroups from the server? Dave Garrett
- Re: [TLS] Allow NamedGroups from the server? Robert Relyea