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

[Joseph Salowey <[e-mail]>]

HI Daniel

Some comments inline below:

On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <[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.


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


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



> 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]> on behalf of Salz, Rich <rsalz=
> [e-mail]>
> *Sent:* Monday, June 29, 2020 12:00 PM
> *To:* Joseph Salowey <[e-mail]>; <[e-mail]> <[e-mail]>
> *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
>
>
> I’d still like to see test vectors.
>