Re: [TLS] Refactoring the negotiation syntax
Eric Rescorla <ekr@rtfm.com> Mon, 18 July 2016 16:03 UTC
Return-Path: <ekr@rtfm.com>
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 969AB12DA4F for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 09:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 tSC81nU-z4rg for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 09:03:49 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 F40D312B00B for <tls@ietf.org>; Mon, 18 Jul 2016 09:03:48 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id i12so162762747ywa.1 for <tls@ietf.org>; Mon, 18 Jul 2016 09:03:48 -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; bh=EeJFXHljhpMZkhCcd5qY0RagN54119xdELIML8aL8Lk=; b=PICaCVbSxQdVBlJwGsaxaH3GAuShkAPYsLnn9D5FAIGJxR7qOCqZrD4gZwlfQxD+xk v+OvEBDJVMj++8Wz6LVOH3JWMt2azY00BZm7zWB2/igpdCweMbg6oydsrcH26cDO+bIr /O1R6I2vCDcaYcd41C46eJO1g28CvkCwhIGfIkOroV9HEi2TwY3rV29cegu51o4t54Fy qPoFoUySzO/LeSLt+kD4FC4UGszEdUtbL9hcIl37amCda9r1wtENQYRHtKVbwezwanei 9r1K9VR6oHwgS7guv8rR71f0ks+3rhKyHJRcmkBwBlCfDzI12xS8uc9b0B+lI7HY9y65 vAgQ==
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; bh=EeJFXHljhpMZkhCcd5qY0RagN54119xdELIML8aL8Lk=; b=bY9RyfQc8sVoAVVf2ytgkNfeOWXKKcJwFzOsYgjbRRnR45XVYP5Ixyfpa2810fYB9z 7Fa4ZdXzx20LvL0LeVzvS0dg5fqc+5YYrZaTG5z5giavBKHfsSjKhZr7ChVZ2N3aGytP yuiKWAy0caNiBr9z5QHBFDYSuoiYi9dsTI1CMJvkBp8/k9z2PyTUn5+Fmu+H2IWO56Yd ZzD5C4JYeuIMnLuBotl8YR6vX6TBg26TKy1Ox88Gui6yd9RcJsMAxr59BnfZ+OzXCWxy jw2BrffSZeKcSKF9KQFoKp52Sh2+wpGdtMqGPTJHlO0RuPl/T2j0epupMzkPHK2NL3Pn cP3g==
X-Gm-Message-State: ALyK8tIlDoiG3/dyPfihRdMJStCFb/fWdzYQ7Zj73/NZ60opST7LsA717Xa1a3ODDYJWo8cEzxN4+4T8bwkHbg==
X-Received: by 10.129.161.129 with SMTP id y123mr26476061ywg.214.1468857828164; Mon, 18 Jul 2016 09:03:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Mon, 18 Jul 2016 09:03:08 -0700 (PDT)
In-Reply-To: <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBPh+BGtnBb725G+YzZZzdSUh5KtViqh3Z339apSKRpygg@mail.gmail.com> <CAJU8_nXwuyLgNGpyvAsmyAq4e_nR9U0g3vtrj3tNR2tHmSqPkQ@mail.gmail.com> <20160718150750.GA13139@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 18 Jul 2016 18:03:08 +0200
Message-ID: <CABcZeBP3Ufi7_s9GcU4Us2VNYyTW+kGgoLJ1heY1tgcBDiNTKA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a114f8db21314ff0537eb1d32"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3J9Acl9wY4ODJSQXKUNb9Hmat4s>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring the negotiation syntax
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 18 Jul 2016 16:03:52 -0000
On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote: > > On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > > > > There have been a lot of discussions about whether we should try to > > > refactor cipher-suite negotiation to be less monolithic in the cipher > > > suite. I've generally been on the "no" side of that on cost/benefit > > > grounds as well as not quite seeing how it would fit into the rest > > > of the infrastructure. However, now that we're starting to get full > > > implementations, and it's becoming clearer how the new elements > > > (principally PSK-resumption and key_shares) interact with cipher > > > suites, I've started to think that in fact we may be able to clean > > > things up. One proposal for this is below [0]. I know this is > > > pretty late in the process, but if we do want this change it's > > > better to do it now. > > > > > > I'm sure we'll need to discuss this in Berlin, but in the meantime, > > > fire away. > > > > > > > > > The basic idea here is to factor out the TLS 1.3 negotiation into three > > > mostly orthogonal axes. > > > > > > - Symmetric cipher/PRF -- indicated by the cipher suite list as in > TLS 1.2 > > > - Key exchange -- indicated by the key_shares and pre_shared_key > extensions > > > - Authentication -- indicated the signature_algorithms and > pre_shared_key > > > extensions > > > > > > > Tl;dr: I think this is a good approach because it eliminates much of the > > existing negotiation redundancy/complexity and combinatorial explosion in > > the 1.3+ ciphersuite menu. > > I recently tried to write code to handle this ciphersuite negotiation, so > that it always negotiates a valid choice if any valid choice exists. > > I think the end result was insane. The problem that makes it so difficult > is that legacy signature types, group types and protection/PRFs interact, > so not all supported offers that server has enabled are actually possible > to chose. > Can you say more about this? I spent some time mocking up an implementation locally and it was pretty clean. Perhaps what made it easier is that I did: 1. Define new cipher suites that were totally agnostic about the key exchange and signature. 2. Assume everything was orthogonal except for the PSK/signature/key exchange interaction... -Ekr -Ekr > > > The longer version: the argument I made in Prague (though IIRC not very > > clearly) was that while it would be nice to limit the ciphersuite options > > to agreed-upon "good" combinations based on some sane notion of > > forward-looking security margin (notwithstanding the practical inability > to > > see the future), the reality on the ground is that authentication is > based > > on something pre-existing---the server has one or two long-term keys of a > > fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on > > demand---so it really only makes sense for the client to indicate what it > > supports and to deal with whatever the server chooses to send it on that > > basis. So I'd argue that this one is orthogonal based on that constraint, > > and so it should be negotiated separately. > > If you are talking about "strength-matching", there is no sane notion of > security equivalence with protection, key exchange and signatures (due to > different sub-threshold, multi-key and period properties). > > And coupling those in a way that doesn't lead to great difficulty (even > greater than currently) REALLY causes the ciphersuite space to > combinatorially explode. > > > AEAD and PRF OTOH don't come with built-in keys, so they can always be > > chosen as a pair as a function of the desired security margin. > > Except in some situations (e.g. 64-bit systems with hardware AES and > CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384. > > The "match security" is IMO about not having the weakest algorithm not > being too weak, or "paying too much" for algorithm that is much above > anything else. > > But what it doesn't consider is what if the stronger algorithm is > actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384. > > Or if on 32-bit hardware where you don't have hw AES? Then > X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256 > if you don't have Ed25519), nevermind that it has "256-bit" symmetric > cipher, > but everything else at "128-bit" level... > > > Key agreement is not clearly in either category: when it's PSK, it's > based > > on what you have, so it's similar to authentication; but when it's > (EC)DHE, > > it's not, and so ideally you'd like the chosen group to be tied to the > > AEAD/PRF security margin. But, since the client has to offer specific > > groups rather than specifying general support for ECDHE or EdDHE, both > > because ideally we want the client key share sent in the first flight and > > because unlike RSA or FFDHE a client can't generalize to key sizes it > > hasn't seen before, it actually still shares a lot in common with the > auth > > case of being sort-of something you have rather than something you can > > choose on the fly. So I'm also in agreement that this is mostly > orthogonal > > and should be negotiated separately. > > "Security matching" between groups and symmetric ciphers is already highly > problematic, and depends on all sorts of assumptions (and is generally > biased towards symmetric ciphers being less secure than they seem). > > Sure, the server might bias choices, but actually enforcing anything here > is IMO unwise. > > > So now you have several grab bags and need to choose one from each. Is it > > necessary to tie the various bits together by security margin? Not clear. > > It's probably fine to assume a client isn't going to announce support for > > anything it doesn't think is secure enough, so the only practical > downside > > to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary > > additional CPU consumption of AES-256/SHA-384. The client was willing to > > accept P-256 server authentication, so presumably it's happy with that > > security margin; and anyway, the server could prefer ciphersuites and > ECDHE > > groups that better match the available auth credentials. > > IMO, no it is not necressary to tie the security margins. In case of > authentication and encryption, there is also the issue that authentication > is good if it is unbroken at that moment, whereas key exchange and > encryption > must remain unbroken for long time since. > > So that someone thinks ECDSA P-256 is OK for authentication does not mean > that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think > that 128-bit symmetric encryption is OK. > > > Or maybe prospective security margin is too complex and/or too > ill-defined > > to bother with, and a server should just choose the least CPU-intensive > > combination of everything. > > Well, yeah, it is ill-defined. Of course, there can be bad algorithms > that one wants to disable. > > However, interactions between bad algorithms are much less likely than > actual bad algorithms causing problems by themselves. > > > -Ilari >
- Re: [TLS] Refactoring the negotiation syntax Ilari Liusvaara
- Re: [TLS] Refactoring the negotiation syntax Eric Rescorla
- Re: [TLS] Refactoring the negotiation syntax Kyle Rose
- Re: [TLS] Refactoring the negotiation syntax Ilari Liusvaara
- Re: [TLS] Refactoring the negotiation syntax Kyle Rose
- Re: [TLS] Refactoring the negotiation syntax Ilari Liusvaara
- Re: [TLS] Refactoring the negotiation syntax Ilari Liusvaara
- Re: [TLS] Refactoring the negotiation syntax Eric Rescorla
- Re: [TLS] Refactoring the negotiation syntax Ilari Liusvaara
- Re: [TLS] Refactoring the negotiation syntax Eric Rescorla
- Re: [TLS] Refactoring the negotiation syntax Dave Garrett
- Re: [TLS] Refactoring the negotiation syntax Eric Rescorla
- [TLS] Refactoring the negotiation syntax Eric Rescorla