Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2
David Benjamin <davidben@chromium.org> Tue, 12 July 2016 17:53 UTC
Return-Path: <davidben@google.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 CDD7912D5B0 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGNNoGtAW2Ae for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 10:53:44 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 BCB0012D59F for <tls@ietf.org>; Tue, 12 Jul 2016 10:53:44 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id b62so23632368iod.3 for <tls@ietf.org>; Tue, 12 Jul 2016 10:53:44 -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=TEknbLBTmXLwfsSsW7yZIeg+Okp8KYXlt+NgvwPG4Q0=; b=cB9haDjxJIbC5Or6m30824E3htgWFzbKxT/gfSxGlrZFVm2sFPX8LH8fbG3NON0RRt Ufv3wGTvyXiLKBKNkly6rd92RrAekHioQWiWk9PWB5VvJLi4QtLdGFSDUWYKcxszEHdt pdQNKrpSiiOfWIvZW3iSQnO2mWrDlbh4yFpFQ=
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=TEknbLBTmXLwfsSsW7yZIeg+Okp8KYXlt+NgvwPG4Q0=; b=cjqutxE5Kln3u7Gn79XyOYXhrdKRVhI7o5/qRDKJJfL7bGcbxM3tsPXx2IOUzUDeXP ApuyL24O4p/+4M2SicthC6iEehDNUmoIW+tl38MT7XZASPxgaI9gayA6QSXF0atxySBg sUqAVleUcwkALiltO00frFEqFvP4hrtWGG1aJpNWihJSlmfqlIiGyTHwrvpZhYTQXDGC JGiolSGdj2fAsWsHCV5DMbhYK90WKAgw++q6MojEkAy2TRby4jmvy18z1UdrRjbp0iiE kUYYKJ0kefPnvDsy1EGPpQwBy+j2aYADlIpDRpD23tRsG9nzEOcYRvtJJMSgndGVQHac sC7w==
X-Gm-Message-State: ALyK8tKJ5uEtmakYN5baEur13xS+XK4vBsu/WGdfaTAvEOdV9MrFwKWnKlyEG2jc9tJBEiaJM/ZRW9QLiXgWLlFX
X-Received: by 10.107.52.133 with SMTP id b127mr4499232ioa.6.1468346023973; Tue, 12 Jul 2016 10:53:43 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBMiLmwBeuLt=v4qdcJwe5rdsK_9R4-2TUXYC=sttmwH-g@mail.gmail.com> <20160712041624.GA30472@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaDcf99O46F1v5ZK8_0079iWgkSoGwD+w-KFd-cRqM_sdw@mail.gmail.com>
In-Reply-To: <CAF8qwaDcf99O46F1v5ZK8_0079iWgkSoGwD+w-KFd-cRqM_sdw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 12 Jul 2016 17:53:34 +0000
Message-ID: <CAF8qwaDN8EmzeTKPAPpcU-F7V+Ofp114cFbOuY9JChg_D-H4SQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a11440f1c2afffa053773f315"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wdInLHXJSSMRzB4lg2RNO25933U>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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:53:47 -0000
On Tue, Jul 12, 2016 at 1:47 PM David Benjamin <davidben@chromium.org> wrote: > [Changing subject since the other thread is about something else.] > > On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: > >> > ### 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.) > I should add: 1.3 CertificateVerify does not have this problem. One signs, e.g.: RSA-PSS-SHA384(padding || context || Hash(HS Context) || Hash(resumption_context)) The HS Context can be maintained as a rolling hash of the PRF hash. The signature scheme internally may use a different pre-hash or no pre-hash at all and the handshake logic doesn't care. 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.) > > David > > [*] 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. >
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Peter Gutmann
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt David McGrew
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Watson Ladd
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Hubert Kario
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Benjamin Kaduk
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Atul Luykx
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- [TLS] TLS 1.3 signature algorithms in TLS 1.2 David Benjamin
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Scott Fluhrer (sfluhrer)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- [TLS] New draft: draft-ietf-tls-tls13-14.txt Eric Rescorla
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dave Garrett
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Ilari Liusvaara
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Dang, Quynh (Fed)
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny
- Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt Paterson, Kenny