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

[Nick Sullivan <[e-mail]>]

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 <[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).
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>