Re: [TLS] A la carte handshake negotiation

Dave Garrett <davemgarrett@gmail.com> Sat, 13 June 2015 18:59 UTC

Return-Path: <davemgarrett@gmail.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 E57241A8940 for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 11:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 C-gyempZSrIG for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 11:59:34 -0700 (PDT)
Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (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 474801A88ED for <tls@ietf.org>; Sat, 13 Jun 2015 11:59:34 -0700 (PDT)
Received: by qcnj1 with SMTP id j1so17827238qcn.0 for <tls@ietf.org>; Sat, 13 Jun 2015 11:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=RRiAoS9C70SQ801PROhC4yuCfP9B16DQZ9v2jEM2VGQ=; b=ytPjvp+umKflGcipxaN8NmaWre4tDGdhPnbEX6Rznx42a3jSj5XP5muqddOafN38ek N4Chbt33wLmsUBvFMH9BDi+gEZPH0s/L3dyqY4XTTzvtWHuAAF9w3OnD2Ys72haiLkxI 16J4NLMf2JX8a9ybvxEPC+HWY0nDX0GT+lqpZoMgpPePQ2jA5/OrBd7eufXMixCIuxNa iiLZh9sOrBf/6kQt/tMMgsXhJyowPyeg60ekTyfcQfLfYur1EeOH0KGORccYn351/Rhk x3iZO4HqXqMXGEYT1UkduuxP1/K7hd5iGwVHWk1xTpfCEVRtIdfAKAlEDj072sXtMPIo rBNQ==
X-Received: by 10.55.40.199 with SMTP id o68mr43924941qko.23.1434221973353; Sat, 13 Jun 2015 11:59:33 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id e71sm3578215qka.40.2015.06.13.11.59.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Jun 2015 11:59:32 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: David Benjamin <davidben@chromium.org>
Date: Sat, 13 Jun 2015 14:59:31 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <201506111558.21577.davemgarrett@gmail.com> <CAF8qwaCAvsrcb6UbcG67XdpFwsL2T-76ZwySbzS5O0Qd0ReLSQ@mail.gmail.com>
In-Reply-To: <CAF8qwaCAvsrcb6UbcG67XdpFwsL2T-76ZwySbzS5O0Qd0ReLSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201506131459.31745.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/F-DVDmgJpLYeo4QWu1zOmnkDNKk>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
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: <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: Sat, 13 Jun 2015 18:59:36 -0000

On Saturday, June 13, 2015 02:28:06 pm David Benjamin wrote:
> On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett <davemgarrett@gmail.com>; wrote:
> > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely via
> > the "supported_groups" & "signature_algorithms" extensions.
> > [...]
> > 4) All TLS 1.3 implementations are expected to be able to handle ECC, but
> > are not required to offer or negotiate it. (at least, here)
> 
> Are you sure this proposal completely achieves that? I believe, by using
> ECDHE_ECDSA as the representative key exchange, this effectively requires
> all clients to offer the ECDHE_ECDSA variant of every bulk cipher.

Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required under this proposal.

[snip]
> Personally, mandatory ECDHE seems just fine. Still, something to be aware
> of. ECDSA might be more of a nuisance. At least as things stand currently,
> Chrome does not offer ECDSA suites on Windows XP because the system
> certificate verifier can't handle it.

At some point, clients that want to continue supporting EOL OSes forever are going to have to roll their own implementations of modern crypto instead of attempting to rely on the OS. Either that, or drop support.

[snip]
> Wouldn't it be simpler to just add a supported_aeads extension and make the
> cipher suite list meaningless for 1.3? With all the obsolete ciphers gone,
> most clients would probably only offer 2-3 of them. The interop risks of a
> bad compatibility cipher suite list seem simple enough. Ensure that:
> 
>   {legacy cipher list} ∩ {all 1.3 combos} ⊆ {key ex.} × {sig alg.} × {aeads}
> 
> But I haven't thought about this very hard and haven't been following the
> topic, so that may be opening a huge can of worms.

That's essentially the nuke it all from orbit, just to be sure, solution. ;)

I'm not against it. It would trade one form of complexity (reduced suites + existing extensions) for a new form of complexity (existing extensions + a new extension), but that could be worth it and simpler overall. If we want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3 support are separate, this is the way to do it.

The largest benefit of this approach might actually just be dropping the need to define the missing ECDHE_* suites to fill in the gaps that got overlooked (e.g. expired drafts). The whole extension and its initial codepoint assignments could be defined in the TLS 1.3 spec.

It wouldn't be quite as simple as you propose, though, because we'd definitely have to add a new way to declare anon or PSK support via extensions, but that's doable.

That said, there was push back against full a la carte in previous discussion on this list. The reason for ending up at this proposal was the desire to use _existing_ systems (ciphers + existing extensions) in a consistent manner to negotiate things with fewer suites, rather than overhaul everything. 

I'm perfectly willing to throw out my draft proposal and switch to this strategy if we agree it is worth implementing. Obsoleting the entire cipher suite system would be opening a can of worms, but it might be a smaller can of worms than we currently have to deal with.


Dave