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
>