Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
"Dang, Quynh" <quynh.dang@nist.gov> Thu, 07 November 2013 14:14 UTC
Return-Path: <quynh.dang@nist.gov>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBB611E8268 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 06:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n-yBGp60IaT for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 06:13:58 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5437711E824D for <tls@ietf.org>; Thu, 7 Nov 2013 06:13:58 -0800 (PST)
Received: from BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.815.6; Thu, 7 Nov 2013 14:13:50 +0000
Received: from BLUPR09MB039.namprd09.prod.outlook.com ([169.254.10.11]) by BLUPR09MB039.namprd09.prod.outlook.com ([169.254.10.209]) with mapi id 15.00.0815.000; Thu, 7 Nov 2013 14:13:50 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: TLS Mailing List <tls@ietf.org>
Thread-Topic: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
Thread-Index: AQHO25x776A78UevjE6My2wkqQqIg5oZzvXx
Date: Thu, 07 Nov 2013 14:13:49 +0000
Message-ID: <bc97bae5fe504945b73e83fe3db0713b@BLUPR09MB039.namprd09.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com>, <87d2mcy2s3.fsf@alice.fifthhorseman.net>
In-Reply-To: <87d2mcy2s3.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.6.222.57]
x-forefront-prvs: 00235A1EEF
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(377454003)(43544003)(24454002)(377424004)(65816001)(66066001)(80022001)(74662001)(80976001)(2656002)(74706001)(74316001)(81816001)(76482001)(85306002)(74876001)(33646001)(69226001)(81686001)(56776001)(54316002)(81342001)(59766001)(79102001)(81542001)(74366001)(53806001)(51856001)(46102001)(87266001)(19580395003)(77096001)(47446002)(50986001)(47736001)(74502001)(56816003)(63696002)(77982001)(54356001)(83072001)(19580405001)(47976001)(83322001)(4396001)(76786001)(31966008)(49866001)(561944002)(224303002)(76576001)(76796001)(87936001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB039.namprd09.prod.outlook.com; CLIP:129.6.222.57; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Subject: Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 07 Nov 2013 14:14:04 -0000
I discussed a little bit about DH key sizes issue in TLS before. I would support and review any draft trying to take care of this issue. Quynh. ________________________________________ From: tls-bounces@ietf.org <tls-bounces@ietf.org> on behalf of Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sent: Thursday, November 07, 2013 4:33 AM To: TLS Mailing List Subject: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations] On Sun 2013-09-22 00:46:52 -0400, Michael D'Errico wrote: > Yoav Nir wrote: >> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <code@funwithsoftware.org> wrote: >> >>> We *do* know how to move to 2048 bits without breaking anything: add >>> an extension to negotiate DH size, just like how ECC curves are >>> negotiated. Although yes, this will take a while to deploy >>> universally, it at least means early adopters can start using 2048 >>> now, without breaking the stragglers like Java. >> >> Perhaps it would be better to have the client suggest the actual >> group rather than bit length in that case. Perhaps we could reuse the >> IKE numbering of groups, or else have the client specify it similar >> to ServerDHParams struct. > > If the client chooses, then I'd prefer they choose from a list of > standardized groups similar to RFC 3526 rather than requiring the > server to (try to) verify that the parameters are usable. We could > also sneak in a 256-bit q parameter to speed up the computations. I'm happy to see the ongoing thinking about TLS 1.3, but i would like to be able to address the ability to negotiate DH group size with less-invasive patches to existing implementations too, so i want to try to flesh out what this DH group negotiation extension would look like. Here are sketches of three different proposals for consideration: The minmalist proposal: ----------------------- * compliant clients advertising a ciphersuite using EDH would include an extension indicating the smallest and largest EDH group sizes they are willing to accept. * compliant servers seeing this extension (and knowing what EDH group(s) they have been configured to use) will select or reject the EDH ciphersuite based on whether their group falls within the client's guidelines. * the rest of the key exchange continues as normal. If the client receives an EDH ciphersuite with a group outside its declared range, then it terminates the connection (this is being done today by many TLS client libraries when they encounter too-weak EDH parameters anyway) and decides whether to retry (a new connection) without offering any EDH ciphersuites. The standard-groups proposal: ----------------------------- * compliant clients advertising a ciphersuite using EDH would include an extension indicating which of the standard groups they prefer, via a series of bytes matching the identifiers of MODP groups listed in RFC 3526, listed in order of preference for the client. * compliant servers are configured to accept a subset of the well-known enumerated groups. A server seeing this extension and selecting an EDH ciphersuite would select and use the first DH group from the set offered that the server is configured to use. If there is no intersection, the server should not select an EDH ciphersuite. when an EDH ciphersuite is selected, either: (a) the Server Key Exchange record would contain that group's parameters explicitly, like in a standard handshake, or (b) the server would offer a modified Server Key Exchange record that only indicates the group ID (i see these as two variants of the standard-groups proposal, not as two options within the standard-groups proposal -- if we go with this, we should pick one) * the rest of the key exchange continues as normal. If the client gets a Server Key Exchange record that does not match one of the groups it specified, the client decides (as it does today) whether to accept the connection or to terminate the connection and/or to fall back to a reconnection without offering any EDH modes. The client-chooses proposal: ---------------------------- * compliant clients advertising a ciphersuite using EDH would include an extension indicating a single standard group they use, along with a freshly-picked ephemeral public key associated with that group. * compliant servers are configured to accept a subset of the well-known enumerated groups. A server seeing this extension and configured to accept the offered group responds with a customized Server Key Exchange record indicating acceptance of the group, and offering its own public key. A compliant server seeing this extension but not configured to accept the offered group should not select an EDH ciphersuite. * If a compliant client sees the customized Server Key Exchange record, it does not send a Client Key Exchange record. If a compliant client sees a normal Server Key Exchange record, then it assumes the server is ignorant of the extension, and decides (as it does today) whether to accept the group, or to terminate the connection and/or fall back to a reconnection without offering any EDH modes. (i've omitted a client-chooses proposal that does not involve standard groups due to Michael's point about wanting to avoid requiring tha tthe server validate the group) I can imagine mixing elements of the above three proposals to create a hybrid proposal, but i'll leave it at these three for now in hopes of commentary. What did i miss? Some observations: ------------------ A) the client-chooses extension is also likely to be much larger than the other two proposals. I'm not so worried about this. B) the client-chooses proposal alters the handshake flow and connection state logic much more radically than the other two proposals. This makes me much more nervous. C) the main gain of any of these proposals is that they allow/encourage an otherwise-conservative server implementation to use stronger DH groups without worrying about incurring a connection failure from non-compliant clients. A compliant server implementation would still need to decide what to do when it hears from a client that does not offer the extension. It would be great to be able to point to something like draft-sheffer-tls-bcp for guidance in this situation. D) settling on standard groups means a few things: * we'll have to either choose an existing registry or make up a new one. I've mentioned RFC 3526 above because it seems like a reasonable existing registry * implementations adopting the registry won't need to bother with primality testing or length testing when using groups from the registry. * choosing standard groups smells a lot like the choice of which ECC curves to use, but i don't think i ever heard quite as much of a brouhaha over the groups in RFC 3526 as i've heard over the suiteB curves. Does going with standard curves mean inviting this kind of struggle all over again in a different domain? What kinds of mathematical assurances do we have to ensure that the standard groups themselves aren't somehow deliberately weakened by their selector? Are there pre-computation or large-data attacks that a powerful adversary could use to target a widely-used group more effectively than an ever-changing sea of different DH groups? I don't know the math literature well enough to comment on any of this, but i would be curious to hear other people's thoughts. E) the client-side configuration options required for the minimalist proposal are a strict subset of the configuration options of the other proposals, since the other proposals still need to have DH group size limits to deal with servers unaware of the extension. All of the observations above make me think that the minimalist proposal seems to be the least likely to cause controversy and the simplest to patch into existing implementations quickly and safely. Also, none of these proposals preclude any of the other ones, so it's conceivable that we could aim for a relatively rapid rollout of the minimalist proposal while shooting for longer-term adoption of one of the others. So i'm currently leaning toward the minimalist proposal, because i think it gives us much of the gains described in (C) without too much additional implementation hand-wringing or controversy. Thoughts? I'd be willing to write up a draft of one of these proposals and implement it if there's sufficient interest. --dkg
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Stephen Farrell
- [TLS] draft-sheffer-tls-bcp: DH recommendations Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Xuelei Fan
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Bill Frantz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael Ströder
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Stephen Farrell
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… james hughes
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Ralph Holz
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Nikos Mavrogiannopoulos
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yoav Nir
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Patrick Pelletier
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Martin Rex
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Yaron Sheffer
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Alex Elsayed
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Michael D'Errico
- Re: [TLS] draft-sheffer-tls-bcp: DH recommendatio… Peter Gutmann
- [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Kyle Hamilton
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Adam Langley
- Re: [TLS] Safe ECC usage Santosh Chokhani
- Re: [TLS] Safe ECC usage Martin Rex
- Re: [TLS] Safe ECC usage Kyle Hamilton
- Re: [TLS] Safe ECC usage Yoav Nir
- Re: [TLS] Safe ECC usage Martin Rex
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Manuel Pégourié-Gonnard
- Re: [TLS] Safe ECC usage Yoav Nir
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- [TLS] (offline note) Re: Safe ECC usage Rene Struik
- Re: [TLS] Safe ECC usage D. J. Bernstein
- [TLS] (EC)DSA potential problems (ECC "brittlenes… Martin Rex
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Watson Ladd
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Johannes Merkle
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Michael StJohns
- Re: [TLS] Safe ECC usage Dan Brown
- Re: [TLS] Safe ECC usage Nico Williams
- Re: [TLS] Safe ECC usage Bill Frantz
- Re: [TLS] Safe ECC usage D. J. Bernstein
- Re: [TLS] Safe ECC usage Dan Brown
- [TLS] DH group negotiation extension [was: Re: dr… Daniel Kahn Gillmor
- Re: [TLS] DH group negotiation extension [was: Re… Dang, Quynh
- Re: [TLS] DH group negotiation extension [was: Re… Patrick Pelletier
- Re: [TLS] DH group negotiation extension [was: Re… Watson Ladd