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
>