Ilari, Thank you for identifying these errors in the document. There was no intention to allow the client to constrict the server certificate's algorithm with the delegated_credential extension, and no intention to restrict the delegated credential's algorithm with the signature_algorithms. Let me propose some minor text changes to address the issues.
As a reminder, the CertificateVerify.algorithm is constrained by the signature_algorithms extension, as stated in RFC 8446: If the CertificateVerify message is sent by a server, the signature algorithm MUST be one offered in the client's "signature_algorithms" extension unless no valid certificate chain can be produced without unsupported algorithms (see Section 4.2.3 <https://tools.ietf.org/html/rfc8446#section-4.2.3>). Original text from 4.1.2.: The expected_cert_verify_algorithm fields MUST be of a type advertised by the client in the SignatureSchemeList and are considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. proposed text: 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. As for the second point, we did not add the capability for the server to advertise a different set of signature_algorithms for client authentication other than the one advertised via the "signature_algorithms" extension. This was perhaps an oversight. I propose that we add that capability and I'd be happy to propose a PR to that effect. The new text of 4.3.2. would look something like: A server which supports this specification SHALL send an "delegated_credential" extension in the CertificateRequest message when requesting client authentication. The body of the extension consists of a SignatureSchemeList. If the server receives a delegated credential without indicating support in its CertificateRequest, then the server MUST abort with an "unexpected_message" alert. .... The algorithm field MUST be of a type advertised by the server in the "signature_algorithms" extension of the CertificateRequest message and the expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. Nick On Mon, Feb 10, 2020 at 7:59 AM Ilari Liusvaara <[email protected]> wrote: > On Wed, Feb 05, 2020 at 12:36:52PM -0800, [email protected] wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Delegated Credentials for TLS > > Authors : Richard Barnes > > Subodh Iyengar > > Nick Sullivan > > Eric Rescorla > > Filename : draft-ietf-tls-subcerts-06.txt > > Pages : 15 > > Date : 2020-02-05 > > I noticed the following: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the client in the SignatureSchemeList and are > > considered invalid otherwise. Clients that receive invalid delegated > > credentials MUST terminate the connection with an "illegal_parameter" > > alert. > > This can be interpretted that the delegated_credentials extension > constrains the end-entity certificate algorithm if DC is sent. This has > seemingly undesirable consequences if the list diverges from what the > signature_algorithms contains: > > 1) If delegated_credentials contains algorithm that signature_algorithms > does not, the server may use that as DC signing algorithm, which will > cause PKIX code to blow up. > > 2) If delgated_credentials is missing some algorithm that > signature_algorithms contains, the client needs to constrain the PKIX > validation further. > > These issues are made worse by the fact that delegated credential > validation code is seemingly intended to be separate from PKIX validation > code, meaning the two can diverge from one another (which is a reason > for having separate lists). > > Looking at the steps to validate the delegated credential, there is > no explicit step to validate signing algorithm, which would imply that > the signing algorithm is constrained by the PKIX code, which would > contradict the above. > > Then because *_rsae is not allowed in expected algorithm, clients would > need to include algorithm that can not be used, if they support *_rsae > for PKIX signatures (however, there could be reasons not to support > *_rsae for signing DCs, see below). > > > And: > > > The algorithm and expected_cert_verify_algorithm fields MUST be of a > > type advertised by the server in the "signature_algorithms" extension > > and are considered invalid otherwise. Servers that receive invalid > > delegated credentials MUST terminate the connection with an > > "illegal_parameter" alert. > > Is there a reason why client can specify another set of algorithms for > verification of delegated credentials, but the server can not? > > > Then in security considerations, I do not see the following issue > discussed: > > - Server has RSA key that has delegation_usage and is usable for > RSA encryption. > - Server is vulernable to BB98/ROBOT. > - Attacker uses BB98/ROBOT to sign a delegated credential. > - Attacker impersonates the server using the forged delegated > credential. > > It is much easier to perform this kind of attack than to use BB98/ROBOT > to impersonate without delgated credentials: > > - Much longer time window to perform the attack (limited by certificate > lifetime, not how long client waits). > - One can impersonate server multiple times per successful attack, not > just once. > > This could be generalized to any signing oracle, but the ones > associated with RSA encryption (BB98/ROBOT/DROWN) are the most common > ones. > > > > > > -Ilari > > > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
