Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
Joseph Salowey <joe@salowey.net> Tue, 30 June 2020 02:02 UTC
Return-Path: <joe@salowey.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 80F433A0F71 for <tls@ietfa.amsl.com>; Mon, 29 Jun 2020 19:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 GcJda-5kWCz7 for <tls@ietfa.amsl.com>; Mon, 29 Jun 2020 19:01:57 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 1806A3A0F6B for <tls@ietf.org>; Mon, 29 Jun 2020 19:01:57 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id h23so14532328qtr.0 for <tls@ietf.org>; Mon, 29 Jun 2020 19:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wAZW8MlFk72IUBomT0FOk+ya+p+nLdqWuW4jlzSUZko=; b=ugqxT+ysuA6m9mErBIwEQPAk6xJehW3V9t4maQaHt3kICZXb10yCVzn13Wp8qBEuJj rH3yjFQaj6ayZPQGfq6Sj5So/P3iJAxJ097PImUPzrBorITYPHx9n7RVMH9vEEsjXcP3 I5kUR8b7ps3X7+MNqS2V6iFHddD3ANCh6bWIvPuDGSwrOe8CkKhKk8FsRcDIf/MhKu6J zTLH6se+/SmfzbAr97G30w0rqgsxN0L2Zz5utWpmjexEqHD0iek03LO/6Bu7XCrqloWC 4Z39OTfuZ+JLGcP8+Q/PIbGQzNxiTe1pMd4ein/MHwp4XOXQrkFVrzBcYuAIkfvycyda M40A==
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=wAZW8MlFk72IUBomT0FOk+ya+p+nLdqWuW4jlzSUZko=; b=k77bkj3sBXciMvL6Ap5u/+h8q5st4+o416Zs//lv3VgpV4rmDzmz+4Gy+jvZu7SW83 LMjy4jdcFFDiSBtasjkzltjVMfYJ/qm5WuxghSCkAHuZOJu0YURox08JvCMOow4RjmFr an274p0sK/P/oL+Z/ZDiRlpukGC54dSOL778Ey3j9VzhYwsqw0SzglS+cJrmE6I+hpVE kMhE4efcN6rof+lwvBktfE/aLZImCg/+1p2qQUNMpT/I5EFwiBUPCuB8ZgyhOtFCJuoC aIDu38OI35xpxq1o1pWvRrNCgyGsUbktAbvo3AlKa4RYPGuXK53j3AOJvjTEpv29+Y9w CfpA==
X-Gm-Message-State: AOAM532t6Xadg22k3Nclsqb0qBuTWedqoRO5LTAaBX+jPmXoWbdaluzj jjWo7dgePzs2n78esCfadIz86YtFZFBkY+hLmLXGBw==
X-Google-Smtp-Source: ABdhPJxHW0Ds3vqAYEiEhG9DVBquzQ8Be5ismBi5BlWkvDfXVZPppp5gRIhJPGaCpcZxcuPxp0THqxc6i0yPkkwRC1M=
X-Received: by 2002:ac8:1ac4:: with SMTP id h4mr19284162qtk.249.1593482515911; Mon, 29 Jun 2020 19:01:55 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoB3LDZ2uMJkMyDxMbbWy6yScYuURVB7GqTiwVS0f2UkTw@mail.gmail.com> <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> <MW3PR15MB37855738A57E0192BBE7796CE36E0@MW3PR15MB3785.namprd15.prod.outlook.com>
In-Reply-To: <MW3PR15MB37855738A57E0192BBE7796CE36E0@MW3PR15MB3785.namprd15.prod.outlook.com>
From: Joseph Salowey <joe@salowey.net>
Date: Mon, 29 Jun 2020 19:01:44 -0700
Message-ID: <CAOgPGoA18+P=XTpB2cLBYTP7r2=XTyaQ8u6nVp=+UcFOhrcBoA@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000051299e05a9438fe0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/c6wYAInaB-fXsMWZMW25ass5oVI>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
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: Tue, 30 Jun 2020 02:02:11 -0000
HI Daniel Some comments inline below: On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <daniel.migault@ericsson.com> wrote: > Hi, > > The draft has a number of nits and errors. Among others: > > The related work section mentions KEYLESS and subcert being complementary > that is KEYLESS can perform the operations associated to the DC and/or > those associated to the cert key. I do not think that is correct. KEYLESS > does not support TLS 1.3 while DC only works with TLS 1.3. The LURK > extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead. > As LURK was mentioned during the adoption period and until version 05 that > should not cause any issues. > > Technologies only available for TLS 1.2 may be mentioned in the related > work section. [draft-mglt-lurk-tls12] should be mentioned similarly to > KEYLESS as it addresses the security concerns of KEYLESS. > > [Joe] KEYLESS is a deployed technology that is addressing some of the same use cases as Delegated credentials. I'm not sure of the status of draft-mglt-lurk-tls13. > There are other places where the extensions is mentioned together with TLS > 1.2 that needs to be updated. > > [Joe] The only place I see TLS 1.2 mentioned is in the security consideration section in reference to the Bleichenbacher attack which is relevant if a server supports both TLS 1.3 and RSA key exchange with TLS 1.2. > I also think that test vectors would be good as well as a link to a formal > verification publication (if available). > > Please see all my comments inline, I hope they help. > > [Joe] Thanks, I didn't get through these yet. The authors should take a look. > Yours, > Daniel > > ---- > > Delegated Credentials for TLS > draft-ietf-tls-subcerts-09 > > [...] > > 1. Introduction > > Typically, a TLS server uses a certificate provided by some entity > other than the operator of the server (a "Certification Authority" or > CA) [RFC8446] [RFC5280]. This organizational separation makes the > TLS server operator dependent on the CA for some aspects of its > operations, for example: > > * Whenever the server operator wants to deploy a new certificate, it > has to interact with the CA. > > * The server operator can only use TLS signature schemes for which > the CA will issue credentials. > > These dependencies cause problems in practice. Server operators > often deploy TLS termination services in locations such as remote > data centers or Content Delivery Networks (CDNs) where it may be > difficult to detect key compromises. Short-lived certificates may be > used to limit the exposure of keys in these cases. > > <mglt> > I believe it would be clearer to > summarize the problem and link it to the > use case. I would propose something > around: > > These dependencies cause problems in > practice, the management of key exposure > necessarily requires an interaction with > the CA. > > Typically server operators.... > </mglt> > > However, short-lived certificates need to be renewed more frequently > than long-lived certificates. If an external CA is unable to issue a > certificate in time to replace a deployed certificate, the server > would no longer be able to present a valid certificate to clients. > With short-lived certificates, there is a smaller window of time to > renew a certificates and therefore a higher risk that an outage at a > CA will negatively affect the uptime of the service. > > To reduce the dependency on external CAs, this document proposes a > limited delegation mechanism that allows a TLS peer to issue its own > credentials within the scope of a certificate issued by an external > CA. These credentials only enable the recipient of the delegation to > speak for names that the CA has authorized. For clarity, we will > refer to the certificate issued by the CA as a "certificate", or > "delegation certificate", and the one issued by the operator as a > "delegated credential" or "DC". > > <mglt> > From the text it is unclear why the > signature scheme appears to be a > constraint as well how it does not opens > to some sort of downgrade attacks if > left to the operator. > </mglt> > > > 3. Solution Overview > > [...] > > 3.1. Rationale > > Delegated credentials present a better alternative than other > delegation mechanisms like proxy certificates [RFC3820] for several > reasons: > > * There is no change needed to certificate validation at the PKI > layer. > > * X.509 semantics are very rich. This can cause unintended > consequences if a service owner creates a proxy certificate where > the properties differ from the leaf certificate. For this reason, > delegated credentials have very restricted semantics that should > not conflict with X.509 semantics. > > * Proxy certificates rely on the certificate path building process > to establish a binding between the proxy certificate and the > server certificate. Since the certificate path building process > is not cryptographically protected, it is possible that a proxy > certificate could be bound to another certificate with the same > public key, with different X.509 parameters. Delegated > credentials, which rely on a cryptographic binding between the > entire certificate and the delegated credential, cannot. > > * Each delegated credential is bound to a specific signature > algorithm that may be used to sign the TLS handshake ([RFC8446] > > > > > Barnes, et al. Expires 28 December 2020 [Page 6] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > section 4.2.3). This prevents them from being used with other, > perhaps unintended signature algorithms. > > <mglt> > It is not clear to me why there is a > "may be used". I suppose it concerns the > use of the DC not the algorithm but that > was confusing. > > I also believe that the specific > signature algorithm to sign the > delegated credential could be part of > the rational. > </mglt> > > 3.2. Related Work > > Many of the use cases for delegated credentials can also be addressed > using purely server-side mechanisms that do not require changes to > client behavior (e.g., a PKCS#11 interface or a remote signing > mechanism [KEYLESS]). These mechanisms, however, incur per- > transaction latency, since the front-end server has to interact with > a back-end server that holds a private key. The mechanism proposed > in this document allows the delegation to be done off-line, with no > per-transaction latency. The figure below compares the message flows > for these two mechanisms with TLS 1.3 [RFC8446]. > > Remote key signing: > > Client Front-End Back-End > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > | |<---remote sign---->| > |<---CertVerify-----| | > | ... | | > > > Delegated credentials: > > Client Front-End Back-End > | |<--DC distribution->| > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > |<---CertVerify-----| | > | ... | | > > These two mechanisms can be complementary. A server could use > credentials for clients that support them, while using [KEYLESS] to > support legacy clients. > > <mglt> > I believe that this sentence does not > show any complementary as subcert and > KEYLESS are targeting different version > of TLS, so they can hardly be > complementary. However (and luckily) > LURK provides an extension for TLS 1.3 > [draft-mglt-lurk-tls13] which enable a > complementary use of these mechanisms > these mechanisms. I believe that would > be good to indicate the reason they > complement each other which is that LURK > protects the credentials for its > operations. These operations could be > performed in the scope of subcert or TLS > 1.3. > > Note also that in a related section it > also worth mentioning that credentials > may be managed in different ways and > KEYLESS represents an valuable way to > protect and manage these credentials in > TLS 1.2. However, KEYLESS is known to > presents some vulnerabilities (PFS, > signing oracle) so the protection > remains limited while the LURK extension > for TLS 1.2 [draft-mglt-lurk-tls12] > addressed these issues and as a result > should provide a better protection. > </mglt> > > The private key for a delegated credential > can be used in place of a certificate private key, so it is important > that the Front-End and Back-End are parties that have a trusted > relationship. > > > Use of short-lived certificates with automated certificate issuance, > e.g., with Automated Certificate Managment Environment (ACME) > <mglt> > Management > </mglt> > [RFC8555], reduces the risk of key compromise, but has several > limitations. Specifically, it introduces an operationally-critical > dependency on an external party. It also limits the types of > > > > Barnes, et al. Expires 28 December 2020 [Page 7] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > algorithms supported for TLS authentication to those the CA is > willing to issue a certificate for. Nonetheless, existing automated > issuance APIs like ACME may be useful for provisioning delegated > credentials. > > 4. Delegated Credentials > > While X.509 forbids end-entity certificates from being used as > issuers for other certificates, it is valid to use them to issue > other signed objects as long as the certificate contains the > digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a > new signed object format that would encode only the semantics that > are needed for this application. The credential has the following > structure: > > struct { > uint32 valid_time; > SignatureScheme expected_cert_verify_algorithm; > opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; > } Credential; > > valid_time: Time in seconds relative to the beginning of the > delegation certificate's notBefore value after which the delegated > credential is no longer valid. This MUST NOT exceed 7 days. > <mglt> > I believe the behavior of the "verifying > peer" should also be specified maybe > with a reference. > > </mglt> > > expected_cert_verify_algorithm: The signature algorithm of the > credential key pair, where the type SignatureScheme is as defined > in [RFC8446]. This is expected to be the same as > CertificateVerify.algorithm sent by the server. Only signature > algorithms allowed for use in CertificateVerify messages are > allowed. When using RSA, the public key MUST NOT use the > rsaEncryption OID, as a result, the following algorithms are not > allowed for use with delegated credentials: rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. > > <mglt> > It is unclear whether the > expected_cert_verify_algorithm and > CertificateVerify.algorithm needs to be > checked and what needs to be done in > case of mismatch (with the RSA caveat). > I believe that should be clarified. > > </mglt> > > ASN1_subjectPublicKeyInfo: The credential's public key, a DER- > encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. > > The delegated credential has the following structure: > > struct { > Credential cred; > SignatureScheme algorithm; > opaque signature<0..2^16-1>; > } DelegatedCredential; > > algorithm: The signature algorithm used to verify > DelegatedCredential.signature. > > <mglt> > I am wondering if any checks should be > performed with the > CertificateVerify.algorithm or if any > algorithm would be acceptable. Unless I > am missing something it seems a weak > algorithm can be used - assuming the > registry contains such weak algorithms. > </mglt> > > > Barnes, et al. Expires 28 December 2020 [Page 8] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > signature: The delegation, a signature that binds the credential to > the end-entity certificate's public key as specified below. The > signature scheme is specified by DelegatedCredential.algorithm. > > [...] > > 4.1.1. Server Authentication > > A client which supports this specification SHALL send a > "delegated_credential" extension in its ClientHello. The body of the > extension consists of a SignatureSchemeList: > > > > > > Barnes, et al. Expires 28 December 2020 [Page 9] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > struct { > SignatureScheme supported_signature_algorithm<2..2^16-2>; > } SignatureSchemeList; > > If the client receives a delegated credential without indicating > support, then the client MUST abort with an "unexpected_message" > alert. > > If the extension is present, the server MAY send a delegated > credential; if the extension is not present, the server MUST NOT send > a delegated credential. The server MUST ignore the extension unless > TLS 1.3 or a later version is negotiated. > > > The server MUST send the delegated credential as an extension in the > CertificateEntry of its end-entity certificate; the client SHOULD > ignore delegated credentials sent as extensions to any other > certificate. > > The expected_cert_verify_algorithm field MUST be of a type advertised > by the client in the SignatureSchemeList and is considered invalid > otherwise. Clients that receive invalid delegated credentials MUST > terminate the connection with an "illegal_parameter" alert. > > <mglt> > I am wondering what would prevent any > downgrade attacks if the > SignatureSchemeList and > signature_algorithms have two different > sets of lists. My current understanding > is that these extensions are handled > independently, but I might be missing > something. > > I am wondering if that would be > appropriated to specify the signature of > the CertificateVerify depending on the > presence of the delegated credential - I > mean the key used to generate it. > > </mglt> > > [...] > > 4.1.3. Validating a Delegated Credential > > On receiving a delegated credential and a certificate chain, the peer > validates the certificate chain and matches the end-entity > certificate to the peer's expected identity. It also takes the > following steps: > > 1. Verify that the current time is within the validity interval of > the credential. This is done by asserting that the current time > is no more than the delegation certificate's notBefore value plus > DelegatedCredential.cred.valid_time. > > 2. Verify that the credential's remaining validity time is no more > than the maximum validity period. This is done by asserting that > the current time is no more than the delegation certificate's > notBefore value plus DelegatedCredential.cred.valid_time plus the > maximum validity period. > > 3. Verify that expected_cert_verify_algorithm matches the scheme > indicated in the peer's CertificateVerify message and that the > algorithm is allowed for use with delegated credentials. > > <mglt> > I am wondering if a reference to specify > what allowed would not be needed unless > it means advertised in the extension. > > </mglt> > > 4. Verify that the end-entity certificate satisfies the conditions > in Section 4.2. > > 5. Use the public key in the peer's end-entity certificate to verify > the signature of the credential using the algorithm indicated by > DelegatedCredential.algorithm. > > If one or more of these checks fail, then the delegated credential is > deemed invalid. Clients and servers that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. If successful, the participant receiving the Certificate > message uses the public key in the credential to verify the signature > in the peer's CertificateVerify message. > > [...] > > 7. Security Considerations > > [...] > > 7.6. The Impact of Signature Forgery Attacks > > When TLS 1.2 servers support RSA key exchange, they may be vulnerable > to attacks that allow forging an RSA signature over an arbitrary > message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a > mitigation strategy requiring careful implementation of timing > resistant countermeasures for preventing these attacks. Experience > shows that in practice, server implementations may fail to fully stop > these attacks due to the complexity of this mitigation [ROBOT]. For > TLS 1.2 servers that support RSA key exchange using a DC-enabled end- > entity certificate, a hypothetical signature forgery attack would > allow forging a signature over a delegated credential. The forged > credential could then be used by the attacker as the equivalent of a > man-in-the-middle certificate, valid for 7 days. > > <mglt> > I do not see the relevance to TLS 1.3. > </mglt> > > Server operators should therefore minimize the risk of using DC- > enabled end-entity certificates where a signature forgery oracle may > be present. If possible, server operators may choose to use DC- > enabled certificates only for signing credentials, and not for > serving non-DC TLS traffic. Furthermore, server operators may use > elliptic curve certificates for DC-enabled traffic, while using RSA > certificates without the DelegationUsage certificate extension for > non-DC traffic; this completely prevents such attacks. > > Note that if a signature can be forged over an arbitrary credential, > the attacker can choose any value for the valid_time field. Repeated > signature forgeries therefore allow the attacker to create multiple > delegated credentials that can cover the entire validity period of > the certificate. Temporary exposure of the key or a signing oracle > may allow the attacker to impersonate a server for the lifetime of > the certificate. > > > ------------------------------ > *From:* TLS <tls-bounces@ietf.org> on behalf of Salz, Rich <rsalz= > 40akamai.com@dmarc.ietf.org> > *Sent:* Monday, June 29, 2020 12:00 PM > *To:* Joseph Salowey <joe@salowey.net>; <tls@ietf.org> <tls@ietf.org> > *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS > > > I’d still like to see test vectors. >
- [TLS] 2nd WGLC for Delegated Credentials for TLS Joseph Salowey
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Salz, Rich
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Joseph Salowey
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Joseph Salowey
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Russ Housley
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Hannes Tschofenig
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Jonathan Hoyland
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Jonathan Hoyland
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Nick Sullivan
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Ilari Liusvaara
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Sean Turner
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Daniel Migault
- Re: [TLS] 2nd WGLC for Delegated Credentials for … Joseph Salowey