[TLS] TLS 1.3 signature algorithms in TLS 1.2

David Benjamin <davidben@chromium.org> Tue, 12 July 2016 17:47 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C350B12D586 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AAyCVWU5Wp6s for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:47:38 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 EB11312D59F for <tls@ietf.org>; Tue, 12 Jul 2016 10:47:37 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id f6so86544561ith.1 for <tls@ietf.org>; Tue, 12 Jul 2016 10:47:37 -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 :cc; bh=nc2P3z3RgDhSVmSNL8eUBgI1dbndGEyNf/3CzqsnRwY=; b=PeJ7vWKQI6WGJBBew5DjhJXosDIgQINtUAERpbiAgR2SYkBNT20vYIdpny4wJjWsGU JdShJWboH8W54MctoPfwtyWLLva2bSkfnx9RReZqEKfZIRewkQJXQ8Rv/n6qq7AIvnrW 2H2lwwUW9Lkvl+Y0gvWXypihS0jozqqMeXYlI=
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:cc; bh=nc2P3z3RgDhSVmSNL8eUBgI1dbndGEyNf/3CzqsnRwY=; b=ZMxLpMYb4ChWDfJ2HziSLKgrNJm+d/OWmv+Ou8a1I2xZ8OWqEXi+sasWLDThXj4qsQ brl8K5RpEdPm8Nlrmr4mQMcBauW3V1TZozZDPsJWQ6PBeFTg5gcR+E6D2YSp4nipoKK3 drmm8NO7DVXVvIOTKDenKvvoz8UeE1i4yx/S9CeGYeHKSnvHgQF0OOBrgKSbbWaEa21A QNmiEHQ9pFfj+Mg0yijZP7uTHWgOCz5gUn+TakBzpqyiMPhG6VSarIcQHsd5wnKWJ2rK VpXt1PQ8pKTX3kdbr9OG3Ld0RX04eEY3TND91KGk32GdE95udT+eNcQ1G1HBQLhT5saO 4QuQ==
X-Gm-Message-State: ALyK8tJnJPnA2vdJtNFfJp1QJP6b03vG1V3NodcMpWDUFykEsbU/hzkpZRGfrlULKDgwRpogir6q2mtcS4L9WjFN
X-Received: by with SMTP id 201mr13813958ith.18.1468345657027; Tue, 12 Jul 2016 10:47:37 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 12 Jul 2016 17:47:26 +0000
Message-ID: <CAF8qwaDcf99O46F1v5ZK8_0079iWgkSoGwD+w-KFd-cRqM_sdw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a114370be4c1f4a053773ddb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AGkqiRrEO3-G6DIdNx5EyqGhsig>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] TLS 1.3 signature algorithms in TLS 1.2
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: Tue, 12 Jul 2016 17:47:39 -0000

[Changing subject since the other thread is about something else.]

On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusvaara@welho.com>

> > ###  Signature Algorithms
> >
> > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are
> >   encoded in two octets, so SignatureScheme values have been allocated to
> >   align with TLS 1.2's encoding. Some legacy pairs are left unallocated.
> These
> >   algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or
> >   negotiated by any implementation. In particular, MD5 {{SLOTH}} and
> SHA-224
> >   MUST NOT be used.
> >
> > * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA
> hash/signature pairs.
> >   However, the old semantics did not constrain the signing curve.
> Also, for interoperability, any legal TLS 1.3 meaning of these algorithms
> must
> be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything
> else
> would be pointless trap.
> This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those
> work.
> Also, even if meaning of the ECDSA codepoints changed, those would not
> break
> that rule, since new definition is strict subset of old.

Certainly, whether RSA-PSS and EdDSA are defined in 1.2 or not needs to be
decided. Otherwise, a server may see a 1.3 ClientHello with an RSA-PSS
offer, implement RSA-PSS (because the underlying library can do 1.3), but
select 1.2 (because, for whatever reason, the server is still set to 1.2).
If the client believes RSA-PSS does not exist in 1.2 but the server does,
we will have interop failure. There's a few other analogous situations with
things reversed.

I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist
in 1.2 because we're not touching the 1.2 registries. But this should be
clarified in the spec. I would actually prefer they stay 1.3-only. I
personally could live with either, but that's because we've backported the
1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some
minor weirdness). I did intentionally mean for the scheme to be
backportable, but I do not think it should be mandated that implementations
do so.

1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a
hash function and a signature algorithm which takes a pre-hashed value. A
1.3 signature scheme is a function that takes a message. This means that,
to backport to TLS 1.2, implementations must remove all pre-hash steps and:

1. For ServerKeyExchange, assemble the client_random || server_random ||
ServerKeyExchange payload and then pass it into the signature scheme.
Current logic probably hashes and then feeds the hash in.

2. Client CertificateVerify in TLS 1.2 messed up. We sign the full
handshake transcript, so there's interactions with the PRF. I've seen
implementations which require signing hash match the PRF hash, sometimes
with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a
mess. I've also seen implementations which decouple them, at the cost of
maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting
forces the second choice.

Notably, if backporting EdDSA, there is no rolling hash one can maintain
for CertificateVerify anyway. EdDSA is inherently message-based, which
motivated the 1.3 change. (That and simpler interfaces.)

There is a middle ground: we backport RSA-PSS (then we should assign it in
the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA.
I intentionally did not do this. I did not want, many years down the line
when EdDSA certificates actually exist, for implementations to discover the
message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style
so any questions about the new scheme would be resolved early.

(We've implemented the message-based scheme and it seems to be just fine.
If you're willing to pay the cost of the backport to all versions, it
actually ends up quite tidy.)


[*] SSL 3.0 ServerKeyExchange is compatible with 1.3's API, but SSL 3.0
CertificateVerify signs some complex construction rather than simply a hash.