Re: [TLS] A la carte handshake negotiation

David Benjamin <davidben@chromium.org> Sat, 13 June 2015 18:28 UTC

Return-Path: <davidben@google.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 017241ACD8B for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 11:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Level:
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zDutzsNuf4SP for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 11:28:19 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 288881ACD57 for <tls@ietf.org>; Sat, 13 Jun 2015 11:28:19 -0700 (PDT)
Received: by igblz2 with SMTP id lz2so28339240igb.1 for <tls@ietf.org>; Sat, 13 Jun 2015 11:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=6gAiIO/HCvDAjeeaepiEESlV2fR/O7aFgv2s+jYCPP4=; b=ohA4SpnezrZ7GUpWLPP+bfxg0LYk8FxGZZHvYdDovNH6lhkm6xvJF7bE8EJttVMCVc sctPd45Nv0coDBo3aEJT83UfgxR1ZKG9eLhRJx8G7XP3FMdy0iSXcbq1uZ9xFnMW8So3 +HlC5obAmMwpK/8Xd1RSoUHY7EXCI1IWL7vrE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=6gAiIO/HCvDAjeeaepiEESlV2fR/O7aFgv2s+jYCPP4=; b=eTskIgzQDweAKokOf6Kvrcb2sZ3aEKhbScbVYw4YH2gMKritxexpHHWBjIZhf0vxEn zJvBR+bKDlY59zFVMJN1mM+a2B209iUSlXXEfLVyLXM0o+zQMna8AKRlf/OWWJopNk3k 8YtLKaaRW5rfK9hAartDwrjDWU0GXrLXcWib1PBn6PG/werbmoBluXIRu8bzz9/HIQq7 fw7hB2uqDd1ATKVaUp74dGjQKwd2Ob7DK0qti492vqtlI9mWRzlOL7t+6oaMxY4tYpMB A9TGe3hcbk9fmCUFO6TWY/ZXPdhyfhLT5cBxnUBwKmHikdelGoJ5R1sSzxRZAtc2vNoG HOKw==
X-Gm-Message-State: ALoCoQmUf3p04ov4qoTwpDS4nrdXsAgAtZSyvNIGCRT9X4UUal9Oxr4RSVC/bGa1WpZ88MRKVlH4
X-Received: by 10.107.34.193 with SMTP id i184mr2561274ioi.56.1434220098356; Sat, 13 Jun 2015 11:28:18 -0700 (PDT)
MIME-Version: 1.0
References: <201506111558.21577.davemgarrett@gmail.com>
In-Reply-To: <201506111558.21577.davemgarrett@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 13 Jun 2015 18:28:06 +0000
Message-ID: <CAF8qwaCAvsrcb6UbcG67XdpFwsL2T-76ZwySbzS5O0Qd0ReLSQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140e7867e36e905186a6311"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/71cYKtUMRGQ9GZ98HE2cZZWhg0s>
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:28:21 -0000

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.

ECDSA is negotiable pre-TLS-1.2, so you can't rely on an ECDSA-less
signature_algorithms to disable things on TLS 1.1 servers (though hopefully
ECDSA deployments all speak 1.2). Plus, if I'm reading this code right,
OpenSSL didn't disable cipher suites based on signature_algorithms until
1.0.2. I haven't tested this, however. (It's hard to be sure of the
behavior. RSA+ECDSA deployments probably aren't that common. Those that
exist probably do custom things in callbacks, so who knows what they check.
The built-in mechanism is slightly odd.)

On the ECDHE side of things, OpenSSL 1.0.1 has two APIs for configuring
ECDHE groups. The saner one (SSL_CTX_set_tmp_ecdh) has you just pick a
group, and that seems to honor supported_curves fine. But there's
also SSL_CTX_set_tmp_ecdh_callback. That callback is called very late, so I
believe OpenSSL won't fall back to a different cipher suite. (OpenSSL will
also treat missing supported_curves as "pick anything", not "don't do ECC".)

At a glance, I wasn't able to find any popular server software that used
SSL_CTX_set_tmp_ecdh_callback (it's kind of a weird API...). Though
apparently Android's SSLServerSocket API does.

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.

In general, I wouldn't expect filtering out cipher suites based on
signature_algorithms/supported_curves to be a well-tested path in servers.
You could easily mess it up and never notice. It's partially redundant with
the cipher list and my unscientific impression is there's not much
variance. (I expect most everyone supports and uses P-256.)

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.

David