Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Daniel Migault <[e-mail]>]

Hi Joe,

Thanks for the feed back, please find my responses inline.

Yours,
Daniel

________________________________
From: Joseph Salowey <[e-mail]>
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault <[e-mail]>
Cc: Salz, Rich <rsalz=[e-mail]>; <[e-mail]> <[e-mail]>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

HI Daniel

Some comments inline below:

On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

The draft has a number of nits and errors. Among others:

The related work section mentions KEYLESS and subcert being complementary that is KEYLESS can perform the operations associated to the DC and/or those associated to the cert key. I do not think that is correct. KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned during the adoption period and until version 05 that should not cause any issues.

Technologies only available for TLS 1.2 may be mentioned in the related work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLESS as it addresses the security concerns of KEYLESS.


[Joe] KEYLESS is a deployed technology that is addressing some of the same use cases as Delegated credentials.  I'm not sure of the status of draft-mglt-lurk-tls13.


<mglt>
To respond to your question regarding the status of draft-mglt-lurk-tls13 it is a work in progress. That said, I am a bit upset by the comment, so let me clarify my comment just in case I mis-interpreted something or I am completely wrong.

Firstly, I tried to briefly describe the type of errors I think I noticed, so the co-authors do not need to parse all comments to get an idea of the types of errors. In this case, I had the impression that the subcert was initially intended to be an extension for TLS 1.2 and TLS 1.3, and the scope of TLS 1.2 has been removed in version 02 while not all text have been updated accordingly. It is a bit more than nits but I do not see this as a major concern.

The related work section positions KEYLESS and subcert and think that is useful. My understanding is that KEYLESS only work for TLS 1.2 and for the server and subcert only works with TLS 1.3. When they shared a common TLS version, it was possible to use these 2 mechanisms together in a given TLS session.  Typically KEYLESS could host the private key of the DC or the X509 certificate and proceed to the appropriated cryptographic operations. This is at least my understanding of the text below:

"""

   These two mechanisms can be complementary.  A server could use
   credentials for clients that support them, while using [KEYLESS<https://tools.ietf.org/html/draft-ietf-tls-subcerts-09#ref-KEYLESS>] to
   support legacy clients.  The private key for a delegated credential
   can be used in place of a certificate private key, so it is important
   that the Front-End and Back-End are parties that have a trusted
   relationship.

"""

Given that KEYLESS and DC work with different versions it seems hard to me that this could happen. I suspect there is an error and that KEYLESS is deployed or not seems to me a bit orthogonal to the fact that it does not achieve what is being written - or at least what I am understanding from the reading.

I believe the case of using KEYLESS-like technologies is important to be mentioned and I believe that draft-mglt-tls13 while being work in progress fits the use case while KEYLESS does not.
As mentioned in my text, I do not think adding LURK in the related work section represents a major update as the technology has been mentioned in the related work section during the adoption, and was there until version 05, and I do not recall this has raised any concerns at least on the mailing list. Digging on github I could only find [1], though I might have missed some discussions.

For the sake of clarity and trying to address potential - and purely speculative - questions that may lie behind the initial question:
* I think the related work section is useful as it clarifies concepts that had been confusing in the past. In addition, I have the impression that delegation may not be entirely deployed with DC and that complementary technology is needed - at least for the peer not supporting the extension.
* I am not asking that KEYLESS be removed even if - as I understand - KEYLESS only address TLS 1.2. I think that is clearly stated.
* I do not think the status of work in progress prevents soem work to be mentioned in a related work section. In some cases a draft status is sufficient for the IANA to assign code points.
* I also believe that [draft-mglt-lurk-tls12] should be mentioned as it addresses some security concerns among others the signing oracle. It seems there are some misunderstanding around this [1].

If there is anything you would like me to clarify, feel free to let  me know. I also believe that clarifications are provided in the inline comments.

[1] https://github.com/tlswg/tls-subcerts/issues/30


</mglt>
There are other places where the extensions is mentioned together with TLS 1.2 that needs to be updated.


[Joe] The only place I see TLS 1.2 mentioned is in the security consideration section in reference to the Bleichenbacher attack which is relevant if a server supports both TLS 1.3 and RSA key exchange with TLS 1.2.

<mglt>
That is at least one place I saw TLS 1.2 being mentioned. Note that the related work section also revealed some issue associated to TLS 1.2 without specifying the version. I suspected that these errors came from the initial support of TLS 1.2 in the beginning and wanted the co-authors to carefully review the draft in that perspective. I do not raise a comment to each of these and leave the co-authors to look at this carefully.

It is correct that some servers may support two versions of TLS but I am not very familiar on how this is handled and operated. As a result I am not able to clearly mention if there is an error or not and this is why I kept the statement quite generic ( "Other places where the extension is mentioned together with TLS 1.2" explicitly or not..

That said, I believe that if the section is entirely dedicated to the case where two versions are being co-hosted, I believe that should be at least clarified as well as other conditions such as (using the same key over the two versions, supporting signing and encryption for that key...). Again I am not very familiar with what is common practice in that scope. At least my perception of the text below is that the section was considering the use of DC in a context of TLS 1.2. I do not see this as a big issue either updating this section

"""

When TLS 1.2 servers support RSA key exchange, ....

"""
"""

For
   TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
   entity certificate, a hypothetical signature forgery attack would
   allow forging a signature over a delegated credential.

"""
</mglt>

I also think that test vectors would be good as well as a link to a formal verification publication (if available).

Please see all my comments inline, I hope they help.

[Joe] Thanks,  I didn't get through these yet.  The authors should take a look.

<mglt>
Going through the comments is not very easy, this is why I tried to provide a brief overview. I am happy to do otherwise if that helps.
</mglt>

Yours,
Daniel

----

                     Delegated Credentials for TLS
                       draft-ietf-tls-subcerts-09

[...]

1.  Introduction

   Typically, a TLS server uses a certificate provided by some entity
   other than the operator of the server (a "Certification Authority" or
   CA) [RFC8446] [RFC5280].  This organizational separation makes the
   TLS server operator dependent on the CA for some aspects of its
   operations, for example:

   *  Whenever the server operator wants to deploy a new certificate, it
      has to interact with the CA.

   *  The server operator can only use TLS signature schemes for which
      the CA will issue credentials.

   These dependencies cause problems in practice.  Server operators
   often deploy TLS termination services in locations such as remote
   data centers or Content Delivery Networks (CDNs) where it may be
   difficult to detect key compromises.  Short-lived certificates may be
   used to limit the exposure of keys in these cases.

<mglt>
I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA.

Typically server operators....
</mglt>

   However, short-lived certificates need to be renewed more frequently
   than long-lived certificates.  If an external CA is unable to issue a
   certificate in time to replace a deployed certificate, the server
   would no longer be able to present a valid certificate to clients.
   With short-lived certificates, there is a smaller window of time to
   renew a certificates and therefore a higher risk that an outage at a
   CA will negatively affect the uptime of the service.

   To reduce the dependency on external CAs, this document proposes a
   limited delegation mechanism that allows a TLS peer to issue its own
   credentials within the scope of a certificate issued by an external
   CA.  These credentials only enable the recipient of the delegation to
   speak for names that the CA has authorized.  For clarity, we will
   refer to the certificate issued by the CA as a "certificate", or
   "delegation certificate", and the one issued by the operator as a
   "delegated credential" or "DC".

<mglt>
>From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator.
</mglt>


3.  Solution Overview

[...]

3.1.  Rationale

   Delegated credentials present a better alternative than other
   delegation mechanisms like proxy certificates [RFC3820] for several
   reasons:

   *  There is no change needed to certificate validation at the PKI
      layer.

   *  X.509 semantics are very rich.  This can cause unintended
      consequences if a service owner creates a proxy certificate where
      the properties differ from the leaf certificate.  For this reason,
      delegated credentials have very restricted semantics that should
      not conflict with X.509 semantics.

   *  Proxy certificates rely on the certificate path building process
      to establish a binding between the proxy certificate and the
      server certificate.  Since the certificate path building process
      is not cryptographically protected, it is possible that a proxy
      certificate could be bound to another certificate with the same
      public key, with different X.509 parameters.  Delegated
      credentials, which rely on a cryptographic binding between the
      entire certificate and the delegated credential, cannot.

   *  Each delegated credential is bound to a specific signature
      algorithm that may be used to sign the TLS handshake ([RFC8446]




Barnes, et al.          Expires 28 December 2020                [Page 6]

Internet-Draft        Delegated Credentials for TLS            June 2020


      section 4.2.3).  This prevents them from being used with other,
      perhaps unintended signature algorithms.

<mglt>
It is not clear to me why there is a
"may be used". I suppose it concerns the
use of the DC not the algorithm but that
was confusing.

I also believe that the specific
signature algorithm to sign the
delegated credential could be part of
the rational.
</mglt>

3.2.  Related Work

   Many of the use cases for delegated credentials can also be addressed
   using purely server-side mechanisms that do not require changes to
   client behavior (e.g., a PKCS#11 interface or a remote signing
   mechanism [KEYLESS]).  These mechanisms, however, incur per-
   transaction latency, since the front-end server has to interact with
   a back-end server that holds a private key.  The mechanism proposed
   in this document allows the delegation to be done off-line, with no
   per-transaction latency.  The figure below compares the message flows
   for these two mechanisms with TLS 1.3 [RFC8446].

   Remote key signing:

   Client            Front-End            Back-End
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |                   |<---remote sign---->|
     |<---CertVerify-----|                    |
     |        ...        |                    |


   Delegated credentials:

   Client            Front-End            Back-End
     |                   |<--DC distribution->|
     |----ClientHello--->|                    |
     |<---ServerHello----|                    |
     |<---Certificate----|                    |
     |<---CertVerify-----|                    |
     |        ...        |                    |

   These two mechanisms can be complementary.  A server could use
   credentials for clients that support them, while using [KEYLESS] to
   support legacy clients.

<mglt>
I believe that this sentence does not
show any complementary as subcert and
KEYLESS are targeting different version
of TLS, so they can hardly be
complementary.  However (and luckily)
LURK provides an extension for TLS 1.3
[draft-mglt-lurk-tls13] which enable a
complementary use of these mechanisms
these mechanisms. I believe that would
be good to indicate the reason they
complement each other which is that LURK
protects the credentials for its
operations. These operations could be
performed in the scope of subcert or TLS
1.3.

Note also that in a related section it
also worth mentioning that credentials
may be managed in different ways and
KEYLESS represents an valuable way to
protect and manage these credentials in
TLS 1.2. However, KEYLESS is known to
presents some vulnerabilities (PFS,
signing oracle) so the protection
remains limited while the LURK extension
for TLS 1.2 [draft-mglt-lurk-tls12]
addressed these issues and as a result
should provide a better protection.
</mglt>

The private key for a delegated credential
   can be used in place of a certificate private key, so it is important
   that the Front-End and Back-End are parties that have a trusted
   relationship.


   Use of short-lived certificates with automated certificate issuance,
   e.g., with Automated Certificate Managment Environment (ACME)
<mglt>
Management
</mglt>
   [RFC8555], reduces the risk of key compromise, but has several
   limitations.  Specifically, it introduces an operationally-critical
   dependency on an external party.  It also limits the types of



Barnes, et al.          Expires 28 December 2020                [Page 7]

Internet-Draft        Delegated Credentials for TLS            June 2020


   algorithms supported for TLS authentication to those the CA is
   willing to issue a certificate for.  Nonetheless, existing automated
   issuance APIs like ACME may be useful for provisioning delegated
   credentials.

4.  Delegated Credentials

   While X.509 forbids end-entity certificates from being used as
   issuers for other certificates, it is valid to use them to issue
   other signed objects as long as the certificate contains the
   digitalSignature KeyUsage ([RFC5280] section 4.2.1.3).  We define a
   new signed object format that would encode only the semantics that
   are needed for this application.  The credential has the following
   structure:

      struct {
        uint32 valid_time;
        SignatureScheme expected_cert_verify_algorithm;
        opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
      } Credential;

   valid_time:  Time in seconds relative to the beginning of the
      delegation certificate's notBefore value after which the delegated
      credential is no longer valid.  This MUST NOT exceed 7 days.
<mglt>
I believe the behavior of the "verifying
peer" should also be specified maybe
with a reference.

</mglt>

   expected_cert_verify_algorithm:  The signature algorithm of the
      credential key pair, where the type SignatureScheme is as defined
      in [RFC8446].  This is expected to be the same as
      CertificateVerify.algorithm sent by the server.  Only signature
      algorithms allowed for use in CertificateVerify messages are
      allowed.  When using RSA, the public key MUST NOT use the
      rsaEncryption OID, as a result, the following algorithms are not
      allowed for use with delegated credentials: rsa_pss_rsae_sha256,
      rsa_pss_rsae_sha384, rsa_pss_rsae_sha512.

<mglt>
It is unclear whether the
expected_cert_verify_algorithm and
CertificateVerify.algorithm needs to be
checked and what needs to be done in
case of mismatch (with the RSA caveat).
I believe that should be clarified.

</mglt>

   ASN1_subjectPublicKeyInfo:  The credential's public key, a DER-
      encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280].

   The delegated credential has the following structure:

      struct {
        Credential cred;
        SignatureScheme algorithm;
        opaque signature<0..2^16-1>;
      } DelegatedCredential;

   algorithm:  The signature algorithm used to verify
      DelegatedCredential.signature.

<mglt>
I am wondering if any checks should be
performed with the
CertificateVerify.algorithm or if any
algorithm would be acceptable. Unless I
am missing something it seems a weak
algorithm can be used - assuming the
registry contains such weak algorithms.
</mglt>


Barnes, et al.          Expires 28 December 2020                [Page 8]

Internet-Draft        Delegated Credentials for TLS            June 2020


   signature:  The delegation, a signature that binds the credential to
      the end-entity certificate's public key as specified below.  The
      signature scheme is specified by DelegatedCredential.algorithm.

[...]

4.1.1.  Server Authentication

   A client which supports this specification SHALL send a
   "delegated_credential" extension in its ClientHello.  The body of the
   extension consists of a SignatureSchemeList:





Barnes, et al.          Expires 28 December 2020                [Page 9]

Internet-Draft        Delegated Credentials for TLS            June 2020


      struct {
        SignatureScheme supported_signature_algorithm<2..2^16-2>;
      } SignatureSchemeList;

   If the client receives a delegated credential without indicating
   support, then the client MUST abort with an "unexpected_message"
   alert.

   If the extension is present, the server MAY send a delegated
   credential; if the extension is not present, the server MUST NOT send
   a delegated credential.  The server MUST ignore the extension unless
   TLS 1.3 or a later version is negotiated.


   The server MUST send the delegated credential as an extension in the
   CertificateEntry of its end-entity certificate; the client SHOULD
   ignore delegated credentials sent as extensions to any other
   certificate.

   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.

<mglt>
I am wondering what would prevent any
downgrade attacks if the
SignatureSchemeList and
signature_algorithms have two different
sets of lists. My current understanding
is that these extensions are handled
independently, but I might be missing
something.

I am wondering if that would be
appropriated to specify the signature of
the CertificateVerify depending on the
presence of the delegated credential - I
mean the key used to generate it.

</mglt>

[...]

4.1.3.  Validating a Delegated Credential

   On receiving a delegated credential and a certificate chain, the peer
   validates the certificate chain and matches the end-entity
   certificate to the peer's expected identity.  It also takes the
   following steps:

   1.  Verify that the current time is within the validity interval of
       the credential.  This is done by asserting that the current time
       is no more than the delegation certificate's notBefore value plus
       DelegatedCredential.cred.valid_time.

   2.  Verify that the credential's remaining validity time is no more
       than the maximum validity period.  This is done by asserting that
       the current time is no more than the delegation certificate's
       notBefore value plus DelegatedCredential.cred.valid_time plus the
       maximum validity period.

   3.  Verify that expected_cert_verify_algorithm matches the scheme
       indicated in the peer's CertificateVerify message and that the
       algorithm is allowed for use with delegated credentials.

<mglt>
I am wondering if a reference to specify
what allowed would not be needed unless
it means advertised in the extension.

</mglt>

   4.  Verify that the end-entity certificate satisfies the conditions
       in Section 4.2.

   5.  Use the public key in the peer's end-entity certificate to verify
       the signature of the credential using the algorithm indicated by
       DelegatedCredential.algorithm.

   If one or more of these checks fail, then the delegated credential is
   deemed invalid.  Clients and servers that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_parameter"
   alert.  If successful, the participant receiving the Certificate
   message uses the public key in the credential to verify the signature
   in the peer's CertificateVerify message.

[...]

7.  Security Considerations

[...]

7.6.  The Impact of Signature Forgery Attacks

   When TLS 1.2 servers support RSA key exchange, they may be vulnerable
   to attacks that allow forging an RSA signature over an arbitrary
   message [BLEI].  TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a
   mitigation strategy requiring careful implementation of timing
   resistant countermeasures for preventing these attacks.  Experience
   shows that in practice, server implementations may fail to fully stop
   these attacks due to the complexity of this mitigation [ROBOT].  For
   TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
   entity certificate, a hypothetical signature forgery attack would
   allow forging a signature over a delegated credential.  The forged
   credential could then be used by the attacker as the equivalent of a
   man-in-the-middle certificate, valid for 7 days.

<mglt>
I do not see the relevance to TLS 1.3.
</mglt>

   Server operators should therefore minimize the risk of using DC-
   enabled end-entity certificates where a signature forgery oracle may
   be present.  If possible, server operators may choose to use DC-
   enabled certificates only for signing credentials, and not for
   serving non-DC TLS traffic.  Furthermore, server operators may use
   elliptic curve certificates for DC-enabled traffic, while using RSA
   certificates without the DelegationUsage certificate extension for
   non-DC traffic; this completely prevents such attacks.

   Note that if a signature can be forged over an arbitrary credential,
   the attacker can choose any value for the valid_time field.  Repeated
   signature forgeries therefore allow the attacker to create multiple
   delegated credentials that can cover the entire validity period of
   the certificate.  Temporary exposure of the key or a signing oracle
   may allow the attacker to impersonate a server for the lifetime of
   the certificate.


________________________________
From: TLS <[e-mail]<mailto:[e-mail]>> on behalf of Salz, Rich <rsalz=[e-mail]<mailto:[e-mail]>>
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS


I'd still like to see test vectors.