Re: [TLS] Remove signature algorithms from cipher suites in 1.3

Brian Smith <brian@briansmith.org> Tue, 23 December 2014 06:07 UTC

Return-Path: <brian@briansmith.org>
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 7B2301A00B8 for <tls@ietfa.amsl.com>; Mon, 22 Dec 2014 22:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 KF5-uDS_X2_A for <tls@ietfa.amsl.com>; Mon, 22 Dec 2014 22:07:36 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D0E1ACD79 for <tls@ietf.org>; Mon, 22 Dec 2014 22:07:36 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id nt9so26743294obb.5 for <tls@ietf.org>; Mon, 22 Dec 2014 22:07:35 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type; bh=VnPXLAPQCXIZprs9FvVN+J0dxJKx2Q/x7vjiTIFMvV0=; b=bpy73SxhNrI0ReZ1sjaBPgRfOJKYlLwMJa4PRxu96+pL1yMPYraNDy/TIR5UcOCXKF CXb4ouMCNg4XYnYK+owDRwzi1LuehwJmEfn53omCBG/D8h/y8FVawbLrYkRByzrE9PCm gXvpCcedrwIOsYbpFP3eJ4Tb1gNu8CsFHtYydgSSSDs9VcfjEDw3HNorh0LsyvyC+ZHR IwN6fpuWJ0rQFzal9brClsGPKygem7+XpNqf9nnjGcyP76S8h3CXZ6upGYGWy0xo951F 6Yw6T2E00WI0HFdLpSgD3gUc3Cm7sDrgEM/sS6KK1u5hQUawYgKiCgz9TegOWht6oGrA Etlw==
X-Gm-Message-State: ALoCoQmCQQTffb4VpUeIlsDa5gJrHvdRI2e7qaWEaEY1x4ijrFIrDVlQMz9yBYzjt7fbAze4qNDX
MIME-Version: 1.0
X-Received: by 10.202.184.135 with SMTP id i129mr14352744oif.68.1419314855818; Mon, 22 Dec 2014 22:07:35 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Mon, 22 Dec 2014 22:07:35 -0800 (PST)
In-Reply-To: <5498DBCE.1070909@delignat-lavaud.fr>
References: <5498DBCE.1070909@delignat-lavaud.fr>
Date: Mon, 22 Dec 2014 22:07:35 -0800
Message-ID: <CAFewVt7RiMfQTv=mkWAgUJLiy9+VSKGVT21QHauR36f4PZFp7g@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2wwyIZErPjHHG0LtMBa8nWchrnY
Cc: Karthik Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>, Alfredo Pironti <alfredo@pironti.eu>
Subject: Re: [TLS] Remove signature algorithms from cipher suites in 1.3
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: Tue, 23 Dec 2014 06:07:38 -0000

Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>; wrote:
> The current draft of TLS 1.3 relies exclusively on signatures to prove
> ownership of private keys in certificates

How would your proposal change if signature-less authentication
mechanisms were added (later)? How would we indicate support for the
signature-less authentication?

> In this design, keeping the legacy of including the signature algorithm to
> be used in the ServerCertificateVerify message within the selected cipher
> suite name can be a burden to the modularity and extensibility of the
> protocol, since adding support for new signature algorithms comes at the
> cost of an exponential increase in the length of the list of cipher suites
> sent by the client, even though the security guarantees of the handshake are
> now fully modular w.r.t authentication goals achieved by certificate and
> signatures.

In theory, that sounds like a problem. Is it really a problem in
practice, if we're not concerned about the specific case of RSA-PSS?

> The tensions between cipher suite and signature algorithm negotiation
> already existed in 1.2 and it led to oddities in the protocol, such as the
> inability to use FF-DHE authenticated by ECDSA, even though there isn't
> anything inherently wrong with this combination.

On the other hand, nobody has ever seemed to want TLS_DHE_ECDSA_*
cipher suites, so it doesn't seem like it caused any problem.

> The following paragraph,
> taken from the current 1.3 draft, is another instance of this awkwardness:
>
> "If the client has offered the "signature_algorithms" extension, the
> signature algorithm and hash algorithm MUST be a pair listed in that
> extension. Note that there is a possibility for inconsistencies here. For
> instance, the client might offer DHE_DSS key exchange but omit any DSA pairs
> from its "signature_algorithms" extension. In order to negotiate correctly,
> the server MUST check any candidate cipher suites against the
> "signature_algorithms" extension before selecting them. This is somewhat
> inelegant but is a compromise designed to minimize changes to the original
> cipher suite design."

In other words, the client might offer DHE_DSS cipher suites that are
only to be used by older servers that do not understand TLS 1.2 and
the signature_algorithms extension, while TLS 1.2 implementations
should choose ECDSA. That's pretty reasonable/desirable behavior.

> - For compatibility with previous protocol versions, existing cipher suite
> names are preserved; however, servers MUST NOT select any cipher suite that
> includes a signature algorithm other than RSA in a 1.3 handshake;

What is the practical advantage of having this restriction? I would be
concerned that there might be an interoperability loss if servers
choose TLS_ECDHE_RSA_* but use an ECDSA certificate. It would be good
to see some measurement of the effects of doing that, but it is
difficult to do such measurement. I think there should be a clear
benefit to the restriction in order to justify the effort to measure
if it would work.

> current cipher suite negotiation). All certificates in a chain MUST also be
> signed with signature algorithms supported by the client. The same
> requirements apply even if a pre-1.3 cipher suite (such as
> ECDHE_RSA_AES256_GCM_SHA384) was selected: the algorithm in the cipher suite
> name is ignored.

Many (most?) clients already work this way, so I don't think this
would be too controversial. But, it seems better for the server to
choose the cipher suite that best identifies the signature algorithm
that it actually uses (e.g. TLS_x_ECDSA_* for a ECDSA certificate),
instead of always using the RSA one.

> The main motivation for proposing these changes is to introduce support for
> PSS signatures in TLS and in certificates.

Why should anybody add any new RSA-based signature scheme now?
Shouldn't we let the RSA algorithm die off with Windows XP and other
ancient stuff? If we're not happy with ECDSA because of the
requirement for a perfect PRNG for randomized signatures, why not just
specify that ServerKeyExchange in TLS 1.3 MUST use deterministic ECDSA
signatures when an ECDSA certificate is used, or something similar
that has similar server-side efficiency as ECDSA? There's got to be
better alternatives to spending time tweaking support for RSA.

Cheers,
Brian