Re: [TLS] Delegated Credentials Question about PSS
Nick Sullivan <nick@cloudflare.com> Wed, 16 October 2019 00:13 UTC
Return-Path: <nick@cloudflare.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 88982120830 for <tls@ietfa.amsl.com>; Tue, 15 Oct 2019 17:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 mt99pDvaDXQU for <tls@ietfa.amsl.com>; Tue, 15 Oct 2019 17:13:31 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 AFD8312082D for <tls@ietf.org>; Tue, 15 Oct 2019 17:13:31 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id v10so14419403vsc.7 for <tls@ietf.org>; Tue, 15 Oct 2019 17:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UgZUpnuOddeC5JqTUMsId07lmxmlTlp7tdlr0H5NvmA=; b=KyXZJfsFIlOhMUiP+nP2+tOTtDHMkhkqru2EpsrCvUZPF3hO9o77TaTqkYXS4Rrprv zhbCKkf1QYxDHd3JFDaVybO7duGtQJCxEDJlBrX9lGKRKbPtcvscpatOFv73lnxRRYiF zUsTTxmdT4Ax4WVwjlYIRsH4XteGM9i1nNiDE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UgZUpnuOddeC5JqTUMsId07lmxmlTlp7tdlr0H5NvmA=; b=sWYQ6+LD3OwcAcneI4wwQRE0a0US9UlrednuiPxIbatX9mrQZvfW0k6zinb77E8Pkt iXOqZEpTjabEmbhqzMtoScPTv89IcXfH+hr5p7SzNESmBpW95Mb52jq5/LOpId0V7uT4 3L3AdwtJpuW/AyqNjaPMA2Vk7oCdtX2SglvA3NCwF7370m1M0lXB3mpjrJd2T/wttMzz MhrUU1fblpCogFxuAdvfqx4h2A+euCNkPosOqma4wRSxt6vwhgdFaWuiXlhcpujIT2gQ C3irFDscH3J/KfB/4kqHFEi6VLXy28zDangyrS9c/2uK0RNVb1YX8nTpH2zTn+XZKdaU TgYQ==
X-Gm-Message-State: APjAAAVAkBGwUJEvBYMeE0SYEwt3uP+0MSP1AJTLpgtqhpt8Z06WX/cS i3CxaUYz+BF9Ub4AwygCXjHsgpAFRLm0WJ/oeZTQt5wuCYgs2Q==
X-Google-Smtp-Source: APXvYqy4lbQt0p+VncvkpTySMahxTrUpPzT+rlQGe9T4oRZJeieIHJV9JETJ2yusQKZByTCFlezJecstrKMlY7kFUYQ=
X-Received: by 2002:a67:f98b:: with SMTP id b11mr21403868vsq.53.1571184810470; Tue, 15 Oct 2019 17:13:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAFDDyk-ohwH4pfeen8iFRHCqb8Pb95-DagORA_NtgaG9AWyoMQ@mail.gmail.com> <D11B62D0-2970-478F-A987-CECB45D58976@vigilsec.com> <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com>
In-Reply-To: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Tue, 15 Oct 2019 17:13:13 -0700
Message-ID: <CAFDDyk-oEr=s5XFqAoXWe8kqMwf=RNzLJXFfezctZ=pAG7kK3A@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008170eb0594fbf822"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fAAoCp7oIUqAoQFhmHEcOv1X14E>
Subject: Re: [TLS] Delegated Credentials Question about PSS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 16 Oct 2019 00:13:35 -0000
One may note that no matter what the choice is with respect to RSA, this particular wrinkle also applies more broadly. For example, if a client advertises support for ed25519 in "signature_algorithms" in order to support ed25519 delegated credentials, it should also be prepared to receive an ed25519 certificate. Nick On Tue, Oct 15, 2019 at 5:00 PM Martin Thomson <mt@lowentropy.net> wrote: > I think that what Nick proposes is consistent with this, and it also > matches my preference. Requiring a PSS OID is nice in that it creates a > strong constraint. > > However, there is a wrinkle. The way you signal support for the signature > scheme is through the signature_algorithms extension. If you advertise > rsa_pss_pss_*, then that means that you are also indicating support for an > end entity certificate with a PSS SPKI. Some certificate validation > software hasn't been updated to support that and might choke if they got a > PSS SPKI in a certificate. > > I don't know if we could support RSA without double checking our code. > Adding support shouldn't be too hard, and we don't current advertise PSS > support, so it's not a complete deal breaker for us, but it's worth > highlighting. > > On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote: > > When we were working on RFC 4055, we thought it would be important to > > allow a certified RSA public key to be bound to a specific algorithm > > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it > > would be important for the certified RSA public key to be used with any > > of the algorithms (constrained by key usage extension). > > > > Section 1.2 says: > > > > The rsaEncryption object identifier continues to identify the subject > > public key when the RSA private key owner does not wish to limit the > > use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. > > > > ... > > > > When the RSA private key owner wishes to limit the use of the public > > key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object > > identifier MUST be used in the algorithm field within the subject > > public key information ... > > > > When the RSA private key owner wishes to limit the use of the public > > key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object > > identifier MUST be used in the algorithm field within the subject > > public key information ... > > > > I would like to continue with the approach. > > > > Russ > > > > > > > On Oct 15, 2019, at 6:34 PM, Nick Sullivan <nick= > 40cloudflare.com@dmarc.ietf.org> wrote: > > > > > > TLSWG, > > > > > > I'd like some feedback on a potential issue raised by Martin Thomson > at the last IETF. The question is about the interaction between the SPKI > and the signature scheme for RSA delegated credentials. The main concern is > around the interaction between the rsaEncryption OID and the signature > scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not > explicitly in DCs (yet). This issue is tracked on Github as issues/28 < > https://github.com/tlswg/tls-subcerts/issues/28>. > > > > > > Given the feedback on Github, I see two main choices to resolve this > issue: > > > > > > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be > used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* > signature schemes. > > > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated > signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature > schemes. > > > > > > Does anyone have a strong preference for one of these options? > > > > > > My take: > > > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be > backward-compatible with existing rsaEncryption OID certs while enabling > RSA-PSS. We don't have this legacy in delegated credentials, so I'm > inclined to prefer 2). > > > > > > The only reason I see to go for 1) is the risk of implementation > difficulties. The RSA PSS OIDs are hard to get right in code. However, > considering that RSA DCs are unlikely to be widely used in favor of > elliptic-curve DCs, the implementation risk seems low and restricted to > implementations who choose to support RSA DCs as an optional feature. > > > > > > Nick > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Delegated Credentials Question about PSS Nick Sullivan
- Re: [TLS] Delegated Credentials Question about PSS Russ Housley
- Re: [TLS] Delegated Credentials Question about PSS Martin Thomson
- Re: [TLS] Delegated Credentials Question about PSS Nick Sullivan
- Re: [TLS] Delegated Credentials Question about PSS Martin Thomson
- Re: [TLS] Delegated Credentials Question about PSS Watson Ladd
- Re: [TLS] Delegated Credentials Question about PSS Martin Thomson
- Re: [TLS] Delegated Credentials Question about PSS Nick Sullivan