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

[Nick Sullivan <[e-mail]>]

Daniel,

Thank you for your thorough review. We've attempted to address these
comments in the latest version on Github and are preparing to submit a -10.
Answers inline below for these comments.

Hannes, thank you for your comment as well.

The changes are tracked here:
https://github.com/tlswg/tls-subcerts/pull/80

On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault <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.
>
> There are other places where the extensions is mentioned together with TLS
> 1.2 that needs to be updated.
>
> 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.
>
> 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>
>

I tried to move the sentences around but wasn't able to get something more
satisfactory. It's currently structured as:

Reality of deployment
Problem: dependencies
Flaws in existing solutions
Proposed solution (this)


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

The second bullet was left unaddressed, so I added some text here.
Downgrades are not a current concern in TLS 1.3 since weak signature
algorithms have been removed and clients advertise signature algorithm
support and can remove weak algorithms should they arise.

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

The sentence was re-structured a bit. I don't understand the second
comment, since the signature algorithm to sign the DC is constricted by the
EE cert's key type. The only ambiguity there is for RSA, which we addressed
by allowing only PSS.

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

Joe had some comments on this as well. This section is meant to
illustrate that it is possible to create a fallback with a remote oracle so
a reference to a paper seemed more apt than an active draft (which would be
challenging to reference in an RFC). Implementations can differ here, this
section is not meant to be instructive.

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

Fixed, thanks!


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

This is valid and echoes Hannes's comment later in this thread. I've
updated the text here to refer directly to the relying peer's behavior. The
issuance requirement of 7 days is defined in section 3 and the behavior is
now defined in 4.1.3.


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

This bullet 3 in section 4.1.3.


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

Echoing my answer above, only signature algorithms listed
in SignatureSchemeList are permitted, so the peer is able to disable weak
algorithms at will.

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

The signature_algorithms SignatureSchemeList is used to match the signature
by the certificate, the delegated_credential SignatureSchemeList is used to
match the expected_cert_verify_algorithm. Given both a certificate and all
possible DCs, the peer could select the weakest signature of the union of
both sets (if they're different). However, this doesn't permit a downgrade
attack if the validating peer doesn't advertise a weak algorithm.


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

In a key reuse scenario (same key, multiple servers) where one of the
servers permits a signing oracle, TLS 1.3 signatures can be actively
forged.

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