On Wed, Feb 05, 2020 at 12:36:52PM -0800, internet-dra...@ietf.org 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
