Draft: draft-ietf-tls-subcerts

Commentary: NOTE : is not a global s / TLS/(D)TLS . There were a couple of places where the change did n't make sense because particular sections in TLS 1.3 ( s3.1 ) and TLS 1.2 ( s7.6 ) . is also not a global s/{{RFC8446}}/{{RFC8446 } } { { } } . There were a couple of places where 8446 defines things that draft - ietf - tls - dtls also uses . changed the context string in s4 . Likely not strictly required , but likely also no harm . 
 Thanks for doing this work , Sean ! 
 if this looks good to you , please merge and cut a new version of the draft . 
 Add explicit support for DTLS . Verified on - list that there appears to be no issues : Need to add normative reference to DTLS as well " DTLS Okay " = Yes in IANA considerations section .
Mailing list commentary: Hi During AD review of draft - ietf - tls - subcerts , he noted that we need to address whether the I - D can also apply to DTLS . This might be useful for WebRTC , for example . Right now the I - D exclusively mentions TLS . The fix might be as easy as a global replace of TLS with ( D)TLS . Can anybody think of a reason to preclude DTLS ? We also need to say one way or the other becase we need to tell IANA to what to put in the “ DTLS - Only ” column when registering the “ delegated_credentials ” extension . Cheers , spt ( for the chairs )
Paragraph (version A):
The organizational separation between the operator of a TLS endpoint
and the certification authority can create limitations.  For example,
the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the
certification authority.  This document describes a mechanism by
which operators may delegate their own credentials for use in TLS,
without breaking compatibility with peers that do not support this
specification.
Paragraph (version A):
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.
Paragraph (version B):
The organizational separation between the operator of a (D)TLS
endpoint and the certification authority can create limitations.  For
example, the lifetime of certificates, how they may be used, and the
algorithms they support are ultimately determined by the
certification authority.  This document describes a mechanism by
which operators may delegate their own credentials for use in (D)TLS,
without breaking compatibility with peers that do not support this
specification.
Paragraph (version B):
Server operators often deploy (D)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.
Paragraph (version A):
The server operator can only use TLS signature schemes for which
the CA will issue credentials.
Paragraph (version A):
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.  Furthermore, this
mechanism allows the server to use modern signature algorithms such
as Ed25519 RFC8032 even if their CA does not support them.
Paragraph (version B):
The server operator can only use (D)TLS signature schemes for
which the CA will issue credentials.
Paragraph (version B):
To reduce the dependency on external CAs, this document proposes a
limited delegation mechanism that allows a (D)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.
Furthermore, this mechanism allows the server to use modern signature
algorithms such as Ed25519 RFC8032 even if their CA does not support
them.
Paragraph (version A):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate with which the
credential may be used.  This document specifies the use of delegated
credentials in TLS 1.3 or later; their use in prior versions of the
protocol is not allowed.
Paragraph (version B):
Peers accepting the delegated credential use it as the certificate
key for the (D)TLS handshake.
Paragraph (version B):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate with which the
credential may be used.  This document specifies the use of delegated
credentials in (D)TLS 1.3 or later; their use in prior versions of
the protocol is not allowed.
Paragraph (version A):
Each delegated credential is bound to a specific signature
algorithm for use in the TLS handshake (RFC8446 section 4.2.3).
This prevents them from being used with other, perhaps unintended
signature algorithms.  The signature algorithm bound to the
delegated credential can be chosen independantly of the set of
signature algorithms supported by the end-entity certificate.
Paragraph (version B):
Each delegated credential is bound to a specific signature
algorithm for use in the (D)TLS handshake (RFC8446 section 4.2.3).
This prevents them from being used with other, perhaps unintended
signature algorithms.  The signature algorithm bound to the
delegated credential can be chosen independantly of the set of
signature algorithms supported by the end-entity certificate.
Paragraph (version A):
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.
Paragraph (version B):
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 (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13.
Paragraph (version A):
Use of short-lived certificates with automated certificate issuance,
e.g., with Automated Certificate Management Environment (ACME)
RFC8555, reduces the risk of key compromise, but has several
limitations.  Specifically, it introduces an operationally-critical
dependency on an external party (the CA).  It also limits the types
of 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.
Paragraph (version B):
Use of short-lived certificates with automated certificate issuance,
e.g., with Automated Certificate Management Environment (ACME)
RFC8555, reduces the risk of key compromise, but has several
limitations.  Specifically, it introduces an operationally-critical
dependency on an external party (the CA).  It also limits the types
of algorithms supported for (D)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.
Paragraph (version A):
The code changes required in order to create and verify delegated
credentials, and the implementation complexity this entails, are
localized to the TLS stack.  This has the advantage of avoiding
changes to security-critical and often delicate PKI code.
Paragraph (version A):
This document defines the following TLS extension code point.
Paragraph (version B):
The code changes required in order to create and verify delegated
credentials, and the implementation complexity this entails, are
localized to the (D)TLS stack.  This has the advantage of avoiding
changes to security-critical and often delicate PKI code.
Paragraph (version B):
This document defines the following (D)TLS extension code point.
Paragraph (version A):
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.  An example of when a
server could choose not to send a delegated credential is when the
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
Paragraph (version B):
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
(D)TLS 1.3 or a later version is negotiated.  An example of when a
server could choose not to send a delegated credential is when the
SignatureSchemes listed only contain signature schemes for which a
corresponding delegated credential does not exist or are otherwise
unsuitable for the connection.
Paragraph (version A):
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential.  The client MUST ignore the extension unless
TLS 1.3 or a later version is negotiated.
Paragraph (version B):
If the extension is present, the client MAY send a delegated
credential; if the extension is not present, the client MUST NOT send
a delegated credential.  The client MUST ignore the extension unless
(D)TLS 1.3 or a later version is negotiated.
Paragraph (version A):
A new extension was chosen instead of adding a new Extended Key Usage
(EKU) to be compatible with deployed TLS and PKI software stacks
without requiring CAs to issue new intermediate certificates.
Paragraph (version B):
A new extension was chosen instead of adding a new Extended Key Usage
(EKU) to be compatible with deployed (D)TLS and PKI software stacks
without requiring CAs to issue new intermediate certificates.
Paragraph (version A):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of 34.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in TLS 1.3 RFC8446.
Paragraph (version B):
This document registers the "delegated_credentials" extension in the
"TLS ExtensionType Values" registry.  The "delegated_credentials"
extension has been assigned a code point of 34.  The IANA registry
lists this extension as "Recommended" (i.e., "Y") and indicates that
it may appear in the ClientHello (CH), CertificateRequest (CR), or
Certificate (CT) messages in (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13.
Additionally, the "DTLS-Only" column is assigned the value "N".
Paragraph (version A):
Delegated credentials limit the exposure of the private key used in a
TLS connection by limiting its validity period.  An attacker who
compromises the private key of a delegated credential can act as a
man-in-the-middle until the delegated credential expires.  However,
they cannot create new delegated credentials.  Thus, delegated
credentials should not be used to send a delegation to an untrusted
party, but is meant to be used between parties that have some trust
relationship with each other.  The secrecy of the delegated
credential's private key is thus important and access control
mechanisms SHOULD be used to protect it, including file system
controls, physical security, or hardware security modules.
Paragraph (version B):
Delegated credentials limit the exposure of the private key used in a
(D)TLS connection by limiting its validity period.  An attacker who
compromises the private key of a delegated credential can act as a
man-in-the-middle until the delegated credential expires.  However,
they cannot create new delegated credentials.  Thus, delegated
credentials should not be used to send a delegation to an untrusted
party, but is meant to be used between parties that have some trust
relationship with each other.  The secrecy of the delegated
credential's private key is thus important and access control
mechanisms SHOULD be used to protect it, including file system
controls, physical security, or hardware security modules.
Paragraph (version A):
Delegated credentials are only used in TLS 1.3 connections.  However,
the certificate that signs a delegated credential may be used in
other contexts such as TLS 1.2.  Using a certificate in multiple
contexts opens up a potential cross-protocol attack against delegated
credentials in TLS 1.3.
Paragraph (version A):
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
delegated credential could then be used by the attacker as the
equivalent of a man-in-the-middle certificate, valid for a maximum of
7 days.
Paragraph (version B):
Delegated credentials are only used in (D)TLS 1.3 connections.
However, the certificate that signs a delegated credential may be
used in other contexts such as (D)TLS 1.2.  Using a certificate in
multiple contexts opens up a potential cross-protocol attack against
delegated credentials in (D)TLS 1.3.
Paragraph (version B):
When (D)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
(D)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
delegated credential could then be used by the attacker as the
equivalent of a man-in-the-middle certificate, valid for a maximum of
7 days.
Paragraph (version A):
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.
Paragraph (version B):
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 (D)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.