Re: [TLS] Delegated Credentials Question about PSS

"Martin Thomson" <mt@lowentropy.net> Wed, 16 October 2019 00:00 UTC

Return-Path: <mt@lowentropy.net>
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 89BAC120835 for <tls@ietfa.amsl.com>; Tue, 15 Oct 2019 17:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=JHaPkc3D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B7Lj/mL7
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 0wIUImiOcgF7 for <tls@ietfa.amsl.com>; Tue, 15 Oct 2019 17:00:20 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4685120864 for <tls@ietf.org>; Tue, 15 Oct 2019 17:00:20 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D145F21D6E for <tls@ietf.org>; Tue, 15 Oct 2019 20:00:19 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 15 Oct 2019 20:00:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=Uare7ANPQW/TtfiP3QCb0jxD2C2oM8L RlRf0hOkHT94=; b=JHaPkc3DIjuUr+tmJqUH0sNMT3EkoZkfM6lFhTAPrlFCLY1 h+Zs8lLWfxjAsKMvmhpAEjZku4p3wRhEcVC03r7+KVwl4y6zmpF9dtdnHBOGYvid vLMBtbuHlRPL8GhqJglS14q7vdYVhAPa+5Zc5SKTx58w+WyiqRRy1zo/N2kJgdAv AxuXuyEh+T/JFpEyddFp8Cg+Br3RZNVDhCekq2dPuzaYivacOer9ue/BjvE/Q0VU ExewnDwrMmODMruHWWV8X8zR0DrtnW1wDmvoYnS77QCXR9lGrdyumsXK80gYMaVA bU70fvIgD3VjPDV/J1BcSIKHa8VZtyE8GWReH4Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Uare7A NPQW/TtfiP3QCb0jxD2C2oM8LRlRf0hOkHT94=; b=B7Lj/mL7R+ZHg0mAM0A/0m ijMcxOSsUC/moVLzRJLwI7SLOqYOD5g5RiUnK/ThNlCdlTUiqdRRgnHPhxWEuasX /fLvgbyk+5l0HJ5+jAo5G/MuN7I8zUt522gAs8wXEkPPtEcfMQF9S1p8w6NdhOCc eZQ37rn5kXHR4UVbKo64utYYfmxd0uErPkBxB/FPuGP2N299Z6hlTP/qEHbrxziX mIbk8Eo1SdOtcRMUWC37RZqKuAiIXl1B2QRN8+k8cu8JE+bqDiGYkm1i+qupp1jn iPWIfPpABqFt9Ob8Ji6a6bIEItz8xblMfxFQVEfsOCl3akQRKDUhOBqnFMrCoqag ==
X-ME-Sender: <xms:k12mXf3ka4LNUo1krCe44LfL5d4kh5ZzsjCyydLtu-Azd5HtnuKU3Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeeggddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:k12mXa7dlVlZsL7m9LytVlsxPfyZQMIgwPSM9NyjMKSTqaiJ3WB7TA> <xmx:k12mXUE8C9N62uZG4VudpgAiFxBE9TNSvxzY1ZJuflsq2Keem6cK3w> <xmx:k12mXS93dgqbiaofXFkKRfA1WonG3fCPbVFTFGuCW-ZUvzV2DG98TQ> <xmx:k12mXTFJZLjhrlvLC1L6aiH1HDCJCvToGcIZCdx4E-HfXjUb78aadA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C134E00A5; Tue, 15 Oct 2019 20:00:19 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2
Mime-Version: 1.0
Message-Id: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com>
In-Reply-To: <D11B62D0-2970-478F-A987-CECB45D58976@vigilsec.com>
References: <CAFDDyk-ohwH4pfeen8iFRHCqb8Pb95-DagORA_NtgaG9AWyoMQ@mail.gmail.com> <D11B62D0-2970-478F-A987-CECB45D58976@vigilsec.com>
Date: Tue, 15 Oct 2019 16:59:59 -0700
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UrQF_m_55eTGS2i4_8Q3pl-rAN0>
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:00:26 -0000

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
>