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
>