Re: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

[Ilari Liusvaara <[e-mail]>]

On Wed, Feb 05, 2020 at 12:36:52PM -0800, [e-mail] 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