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

[Watson Ladd <[e-mail]>]

On Mon, Feb 10, 2020 at 7:59 AM Ilari Liusvaara
<[e-mail]> wrote:
>
> 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).

I think the intent of the change was to make two separate lists so the
TLS implementation could implement new signature schemes and DCs with
those keys could be issued, while being signed by existing certs that
would be selected based on what the PKIX library allows.  The PKIX
library is only checking the validity of the EE certificate and the
chain to the root, the signature by the EE certificate on the DC is
only being checked by the TLS library. The PKIX library never sees the
DC, and what is in delegated_credentials doesn't matter for the EE to
root verification.

>
> 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.

Should we explicitly prohibit including the credential and supporting
RSA decryption? Unfortunately I seem to recall PKIX doesn't have a way
to do this because of widespread compatibility issues.

Sincerely,
Watson Ladd

>
>
>
>
>
> -Ilari
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls