On Tue, Jun 30, 2020 at 9:10 AM Daniel Migault <daniel.miga...@ericsson.com> wrote:
> Hi Joe, > > Thanks for the feed back, please find my responses inline. > > Yours, > Daniel > > ------------------------------ > *From:* Joseph Salowey <j...@salowey.net> > *Sent:* Monday, June 29, 2020 10:01 PM > *To:* Daniel Migault <daniel.miga...@ericsson.com> > *Cc:* Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>; <tls@ietf.org> < > tls@ietf.org> > *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS > > HI Daniel > > Some comments inline below: > > On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault < > daniel.miga...@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. > > > <mglt> > To respond to your question regarding the status of draft-mglt-lurk-tls13 > it is a work in progress. That said, I am a bit upset by the comment, so > let me clarify my comment just in case I mis-interpreted something or I am > completely wrong. > > [Joe] I apologize if my comment came off a bit brusk. I'm not sure if the paper referenced is just applicable to TLS 1.2 or not, but if it is I can see how the text could be misleading. I think the security considerations are reasonably clear since the extension is a 1.3 extension, however I wouldn't hurt to mention that the problem manifests itself in TLS 1.3 because of 1.2 usage. I'll let the authors take a crack at the comments inline since they have more context. I'm not sure if this document is the place to have a discussion about LURK. > Firstly, I tried to briefly describe the type of errors I think I noticed, > so the co-authors do not need to parse all comments to get an idea of the > types of errors. In this case, I had the impression that the subcert was > initially intended to be an extension for TLS 1.2 and TLS 1.3, and the > scope of TLS 1.2 has been removed in version 02 while not all text have > been updated accordingly. It is a bit more than nits but I do not see > this as a major concern. > > The related work section positions KEYLESS and subcert and think that is > useful. My understanding is that KEYLESS only work for TLS 1.2 and for the > server and subcert only works with TLS 1.3. When they shared a common TLS > version, it was possible to use these 2 mechanisms together in a given TLS > session. Typically KEYLESS could host the private key of the DC or the > X509 certificate and proceed to the appropriated cryptographic operations.. > This is at least my understanding of the text below: > > """ > > These two mechanisms can be complementary. A server could use > credentials for clients that support them, while using [KEYLESS > <https://tools.ietf.org/html/draft-ietf-tls-subcerts-09#ref-KEYLESS>] to > support legacy clients. 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. > > """ > > Given that KEYLESS and DC work with different versions it seems hard to me > that this could happen. I suspect there is an error and that KEYLESS is > deployed or not seems to me a bit orthogonal to the fact that it does not > achieve what is being written - or at least what I am understanding from > the reading. > > > I believe the case of using KEYLESS-like technologies is important to be > mentioned and I believe that draft-mglt-tls13 while being work in progress > fits the use case while KEYLESS does not. > As mentioned in my text, I do not think adding LURK in the related work > section represents a major update as the technology has been mentioned in > the related work section during the adoption, and was there until version > 05, and I do not recall this has raised any concerns at least on the > mailing list. Digging on github I could only find [1], though I might have > missed some discussions. > > For the sake of clarity and trying to address potential - and purely > speculative - questions that may lie behind the initial question: > * I think the related work section is useful as it clarifies concepts that > had been confusing in the past. In addition, I have the impression that > delegation may not be entirely deployed with DC and that complementary > technology is needed - at least for the peer not supporting the extension.. > * I am not asking that KEYLESS be removed even if - as I understand - > KEYLESS only address TLS 1.2. I think that is clearly stated. > * I do not think the status of work in progress prevents soem work to be > mentioned in a related work section. In some cases a draft status is > sufficient for the IANA to assign code points. > * I also believe that [draft-mglt-lurk-tls12] should be mentioned as it > addresses some security concerns among others the signing oracle. It seems > there are some misunderstanding around this [1]. > > If there is anything you would like me to clarify, feel free to let me > know. I also believe that clarifications are provided in the inline > comments. > > [1] https://github.com/tlswg/tls-subcerts/issues/30 > > > </mglt> > > 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. > > <mglt> > That is at least one place I saw TLS 1.2 being mentioned. Note that the > related work section also revealed some issue associated to TLS 1.2 without > specifying the version. I suspected that these errors came from the initial > support of TLS 1.2 in the beginning and wanted the co-authors to carefully > review the draft in that perspective. I do not raise a comment to each of > these and leave the co-authors to look at this carefully. > > It is correct that some servers may support two versions of TLS but I am > not very familiar on how this is handled and operated. As a result I am not > able to clearly mention if there is an error or not and this is why I kept > the statement quite generic ( "Other places where the extension is > mentioned together with TLS 1.2" explicitly or not.. > > That said, I believe that if the section is entirely dedicated to the case > where two versions are being co-hosted, I believe that should be at least > clarified as well as other conditions such as (using the same key over the > two versions, supporting signing and encryption for that key...). Again I > am not very familiar with what is common practice in that scope. At least > my perception of the text below is that the section was considering the use > of DC in a context of TLS 1.2. I do not see this as a big issue either > updating this section > > """ > > When TLS 1.2 servers support RSA key exchange, .... > > """ > """ > > 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. > > """ > </mglt> > > 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. > > <mglt> > Going through the comments is not very easy, this is why I tried to > provide a brief overview. I am happy to do otherwise if that helps. > </mglt> > > > 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-boun...@ietf.org> on behalf of Salz, Rich <rsalz= > 40akamai....@dmarc.ietf.org> > *Sent:* Monday, June 29, 2020 12:00 PM > *To:* Joseph Salowey <j...@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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
