[TLS] Closing on PSS. PR#1114

Eric Rescorla <ekr@rtfm.com> Tue, 05 December 2017 01:25 UTC

Return-Path: <ekr@rtfm.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 5421812426E for <tls@ietfa.amsl.com>; Mon, 4 Dec 2017 17:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2ItJm8WsN_P9 for <tls@ietfa.amsl.com>; Mon, 4 Dec 2017 17:25:01 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 EE11A1242F5 for <tls@ietf.org>; Mon, 4 Dec 2017 17:25:00 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id v190so419307ywg.4 for <tls@ietf.org>; Mon, 04 Dec 2017 17:25:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=4g4LX+W+Ii6jb64jLDvtyWOolmsaRY59dhHGJq0/TIc=; b=QDE6o5QgOp3AGmr+WVM9Z89YbQYhxOBsvP1aEGY4BmwBLpQ5rVVRJ+/dHFel1+Fsxl HmzAGUIY5VQC2Ddx1s18iGgwzInibrKQ1+AAg7MUNluQ7LbRW4SFR9q0y1MtdfPPPGDm vwpPje0xTBYV4sc224DyqiGeukT6Gf5AeqVtDd9olW1bASS4v6/7uaaBaLuYwuk48UVY e30CL1u8FC74ZLxVmiCAEUpzi8eP3LHIlQ0KccFPcpI51G8+fM2tKR2ss/tmQVS0A/wx UCdjoVAla/WmGugkNe/O8UHfvpHRJNsnCW12625R8R98Y0yaj/UwkYluAcdWD/S+K7Y9 +j/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4g4LX+W+Ii6jb64jLDvtyWOolmsaRY59dhHGJq0/TIc=; b=ptA8B1SShrm/7xXQPPsQ0lbbRbjhZqk63sfkaOQ0Y7WOWrTW9EZRDgK2MBQypxN52m N6dNbVLXCwbqslVPJgMtZC8MAFBR3kvtJbnnpxJGH/LhjTtHTxejkKrEIcBsCBAsC9eC 6x2gANo5IPsUz3dHtrXEC4BEOgimN/o8zAYJmgENzkiuITzy/IpQ/dLJiUMQInV0lvxZ yN4ykHnhJgq7XFoblW79PJ9eetu/vU60ifZOGbLhb/3ZnfDmrdywgg3ap1Y+4nCFWSni 44IT8d4jmUEOmDKKjRNM7ZRce/994+qlAdf9ZOu6h/hbQF84SogViU68rovN4ABE46zR NA2Q==
X-Gm-Message-State: AJaThX4z63TixukGgVijJytMhXU82fWFcnMw70q7ZSLwbj5C2CIdtVs7 x3+9tVnosexh6TcZNe+w9R1bCaGxNJaew60B4hDnSTehiyw=
X-Google-Smtp-Source: AGs4zMZmeO5zn3Mv7mtrWbGghoDs5fRFs0bOK1Dnx3bD04clYZ2V6etE9Jh/D/UhsyfUOgqGdEGHu/NT83Sqzl1UqeU=
X-Received: by with SMTP id j189mr11232669ywb.504.1512437099810; Mon, 04 Dec 2017 17:24:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 4 Dec 2017 17:24:19 -0800 (PST)
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 4 Dec 2017 17:24:19 -0800
Message-ID: <CABcZeBPyZvvoZ_OQfj2k1uDz8cc3_ASTMWvD17axJx3+WFDRUw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f169e146c41055f8db479"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5SWSVLHqNVSl6oNoYxU4s-ZzV1c>
Subject: [TLS] Closing on PSS. PR#1114
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Dec 2017 01:25:03 -0000

Hi folks,

I've put together a PR that attemps to address the PSS issue.


Because there are platforms which don't have any support for PSS in
the cert validator, at all, it seems like we MUST be able to express
the following:

1. I accept PSS in CV, but nowhere in certificates, and the SPKI
   MUST be of type rsaEncryption (because this is what Chrome
   can do on some platforms).

Going forward, we want to be able to express:

2. I accept PSS in CV *and* everywhere in the certificate chain
   (otherwise PSS certificates are dead)

3. I accept EdDSA in CV but not for signing certificates
   (note that this is subtly different from the PSS case because
   you would need an EdDSA SPKI)

4. I accept EdDSA in CV and everywhere in the cert chain

Of these, #4 is mandatory, but #2 and #3 are pretty nice to have if
we want fast deployment. Otherwise, it's not possible to roll out
EdDSA (or other new algorithms) to browsers which don't have full
support in the validator, which, based on history, seems like a
pretty common situation.

Unfortunately, this seems to require two distinctions:

1. CV versus cert chain (for any incremental deployment)
2. PKCS#1 versus PSS (for the goofy PSS case).

So, I think in order to address this problem we need two constructs:

- A separate extension that refers only to the cert chain
- Two sets of RSA code points, one for PSS and one for PKCS#1.

For the first, we would introduce a new signature_algorithms_certs
which says: "this is what I support for the signature algorithms in
certificates" (and by extension SPKI) If this is present, you filter:

   (a) CV signatures/EE keys against signature_algorithms

   (b) the signatures on certificates (and keys of their signers)
   against signature_algorithms_cert

If it's absent, you filter everything against signature_algorithms as
in the current design.

For the second, we would have:

- rsa_pss_shaX_rsae       == "I support PSS signatures with rsaEncryption
                             [these would use the current rsa_pss_shaX code
- rsa_pss_shaX_rsassa_pss == "I support PSS signatures with RSASSA-PSS SPKI"

To go back to our requirements, you would say #1 (PSS in CV only, with

  signature_algorithms = [rsa_pss_shaX_rsae]
  signature_algorithms_cert = [rsa_pkcs1_shaX]

You would say #2 (full PSS) as:

  signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss]
  signature_algorithms_cert = [rsa_pkcs1_shaX, rsa_pss_shaX_rsae,

You would say #3 (EdDSA in CV only as)

  signature_algorithms = [ed25519]
  signature_algorithms_cert = [something else like ecdsa_secp256r1_sha256]

And finally, #4 (full EdDSA support)

  signature_algorithms = [ed25519]
  signature_algorithms_cert = [ed25519]

I recognize that this isn't totally ideal, but I think it covers all the
cases, and even some we don't need to cover, like you would support
SPKI in the EE cert:

  signature_algorithms = [rsa_pss_shaX_rsae, rsa_pss_shaX_rsassa_pss]
  signature_algorithms_cert = [rsa_pkcs1_shaX]