[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
From: Daniel Migault <daniel.migault=40ericsson.com () dmarc ! ietf ! org>
Date: 2020-06-30 16:10:05
Message-ID: SA0PR15MB3791976C5184C780C56DEF35E36F0 () SA0PR15MB3791 ! namprd15 ! prod ! outlook ! com
[Download RAW message or body]
Hi Joe,
Thanks for the feed back, please find my responses inline.
Yours,
Daniel
________________________________
From: Joseph Salowey <joe@salowey.net>
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>; <tls@ietf.org> <tls@ietf.org>
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 \
<daniel.migault@ericsson.com<mailto:daniel.migault@ericsson.com>> 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 <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> on behalf of Salz, Rich \
<rsalz=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>>
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <joe@salowey.net<mailto:joe@salowey.net>>; \
<tls@ietf.org<mailto:tls@ietf.org>> \
<tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
I'd still like to see test vectors.
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> Hi Joe, </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> Thanks for the feed back, please find my responses \
inline.</div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; \
font-size: 12pt; color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> Yours, <br>
Daniel</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> <br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" \
style="font-size:11pt"><b>From:</b> Joseph Salowey <joe@salowey.net><br> \
<b>Sent:</b> Monday, June 29, 2020 10:01 PM<br> <b>To:</b> Daniel Migault \
<daniel.migault@ericsson.com><br> <b>Cc:</b> Salz, Rich \
<rsalz=40akamai.com@dmarc.ietf.org>; <tls@ietf.org> \
<tls@ietf.org><br> <b>Subject:</b> Re: [TLS] 2nd WGLC for Delegated Credentials \
for TLS</font> <div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">HI Daniel
<div><br>
</div>
<div>Some comments inline below:</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault \
<<a href="mailto:daniel.migault@ericsson.com">daniel.migault@ericsson.com</a>> \
wrote:<br> </div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px \
solid rgb(204,204,204); padding-left:1ex"> <div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> <div style="margin:0px; font-size:12pt; \
font-family:Calibri,Arial,Helvetica,sans-serif"> <span \
style="margin:0px">Hi, </span></div> <div style="margin:0px; font-size:12pt; \
font-family:Calibri,Arial,Helvetica,sans-serif"> <div style="margin:0px"><br>
</div>
<div style="margin:0px">The draft has a number of nits and errors. Among \
others:<span> </span><br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">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. <br> \
</div> <div style="margin:0px"><br>
</div>
<div style="margin:0px">Technologies only available for TLS 1.2 may be mentioned in \
the related work section. <span \
style="font-family:Calibri,Arial,Helvetica,sans-serif; \
background-color:rgb(255,255,255); \
display:inline"><span> </span>[draft-mglt-lurk-tls12]<span> should be \
mentioned </span></span>similarly to KEYLESS as it addresses the security \
concerns of KEYLESS. <br> </div>
<div style="margin:0px"><br>
</div>
</div>
</div>
</div>
</blockquote>
<div><font size="4"><br>
</font></div>
<div><font size="4">[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. </font></div> <div><font size="4"><br>
</font></div>
<div><font size="4">
<div><mglt></div>
<div>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. </div> <div> </div>
<div>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.</div> <div><br>
</div>
<div>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: </div> <div><br>
</div>
<div>"""</div>
<div>
<pre style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: \
page; color: rgb(0, 0, 0)"> These two mechanisms can be complementary. A server \
could use credentials for clients that support them, while using [<a \
href="https://tools.ietf.org/html/draft-ietf-tls-subcerts-09#ref-KEYLESS" \
title=""An Analysis of TLS Handshake Proxying"">KEYLESS</a>] 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.</pre>
</div>
<div>""" </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div> <div>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.</div> <div><br>
</div>
<div>For the sake of clarity and trying to address potential - and purely speculative \
- questions that may lie behind the initial question: </div> <div>* 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. </div> <div>* 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. </div> <div>* 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. \
</div> <div>* 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 <span \
style="font-family: "Segoe UI", "Segoe UI Web (West European)", \
"Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica \
Neue", sans-serif; font-size: large; background-color: rgb(255, 255, 255); \
display: inline !important">[1].</span></div> <div><br>
</div>
<div>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.</div> \
<div><br> </div>
<div>[1] <a href="https://github.com/tlswg/tls-subcerts/issues/30">https://github.com/tlswg/tls-subcerts/issues/30</a></div>
<div><br>
</div>
<div><br>
</div>
<div></mglt> </div>
</font></div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px \
solid rgb(204,204,204); padding-left:1ex"> <div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; color:rgb(0,0,0)">
<div style="margin:0px; font-family:Calibri,Arial,Helvetica,sans-serif">
<div style="margin:0px"></div>
<div style="margin:0px"><font size="4">There are other places where the extensions is \
mentioned together with TLS 1.2 that needs to be updated. <br> </font></div>
<div style="margin:0px"><font size="4"><br>
</font></div>
</div>
</div>
</div>
</blockquote>
<div><font size="4"><br>
</font></div>
<div><font size="4">[Joe] The only place I see TLS 1.2 mentioned is in the security \
consideration section in reference to the <span \
style="color:rgb(0,0,0)">Bleichenbacher attack which is relevant if a server supports \
both TLS 1.3 and RSA key exchange with TLS 1.2. </span></font></div>
<div><font size="4">
<div><mglt></div>
<div>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.</div> <div><br>
</div>
<div>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.. </div> <div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>"""</div>
<div>
<pre style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: \
page; color: rgb(0, 0, 0)">When TLS 1.2 servers support RSA key exchange, ....</pre> \
</div> <div>"""</div>
<div>"""</div>
<div>
<pre style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: \
page; color: rgb(0, 0, 0)">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. </pre>
</div>
<div>"""</div>
<div></mglt> </div>
</font></div>
<div><font size="4"><br>
</font></div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px \
solid rgb(204,204,204); padding-left:1ex"> <div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; color:rgb(0,0,0)">
<div style="margin:0px; font-family:Calibri,Arial,Helvetica,sans-serif">
<div style="margin:0px"></div>
<div style="margin:0px"><font size="4">I also think that test vectors would be good \
as well as a link to a formal verification publication (if available).</font></div> \
<div style="margin:0px"><font size="4"><br> </font></div>
<div style="margin:0px"><font size="4">Please see all my comments inline, I hope they \
help.<br> </font></div>
<div style="margin:0px"><font size="4"><br>
</font></div>
</div>
</div>
</div>
</blockquote>
<div><font size="4">[Joe] Thanks, I didn't get through these yet. The \
authors should take a look. </font></div> <div><font size="4">
<div><br>
</div>
<div><mglt></div>
<div>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. </div> \
<div></mglt> </div> </font></div>
<div><font size="4"> </font></div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px \
solid rgb(204,204,204); padding-left:1ex"> <div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> <div style="margin:0px; font-size:12pt; \
font-family:Calibri,Arial,Helvetica,sans-serif"> <div style="margin:0px"></div>
<div style="margin:0px">Yours,<span> </span><br>
</div>
<div style="margin:0px">Daniel<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">----<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> \
Delegated Credentials for TLS<br> </div>
<div style="margin:0px"> \
draft-ietf-tls-subcerts-09<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">1. Introduction<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Typically, a TLS server uses a certificate \
provided by some entity<br> </div>
<div style="margin:0px"> other than the operator of the server (a \
"Certification Authority" or<br> </div>
<div style="margin:0px"> CA) [RFC8446] [RFC5280]. This \
organizational separation makes the<br> </div>
<div style="margin:0px"> TLS server operator dependent on the CA for some \
aspects of its<br> </div>
<div style="margin:0px"> operations, for example:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * Whenever the server operator wants to \
deploy a new certificate, it<br> </div>
<div style="margin:0px"> has to interact with the CA.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * The server operator can only use TLS \
signature schemes for which<br> </div>
<div style="margin:0px"> the CA will issue credentials.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> These dependencies cause problems in \
practice. Server operators<br> </div>
<div style="margin:0px"> often deploy TLS termination services in \
locations such as remote<br> </div>
<div style="margin:0px"> data centers or Content Delivery Networks (CDNs) \
where it may be<br> </div>
<div style="margin:0px"> difficult to detect key compromises. \
Short-lived certificates may be<br> </div>
<div style="margin:0px"> used to limit the exposure of keys in these \
cases.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I believe it would be clearer to<br>
</div>
<div style="margin:0px">summarize the problem and link it to the<br>
</div>
<div style="margin:0px">use case. I would propose something<br>
</div>
<div style="margin:0px">around:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">These dependencies cause problems in<br>
</div>
<div style="margin:0px">practice, the management of key exposure<br>
</div>
<div style="margin:0px">necessarily requires an interaction with<br>
</div>
<div style="margin:0px">the CA.<span> </span><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Typically server operators....<br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> However, short-lived certificates need to be \
renewed more frequently<br> </div>
<div style="margin:0px"> than long-lived certificates. If an \
external CA is unable to issue a<br> </div>
<div style="margin:0px"> certificate in time to replace a deployed \
certificate, the server<br> </div>
<div style="margin:0px"> would no longer be able to present a valid \
certificate to clients.<br> </div>
<div style="margin:0px"> With short-lived certificates, there is a \
smaller window of time to<br> </div>
<div style="margin:0px"> renew a certificates and therefore a higher risk \
that an outage at a<br> </div>
<div style="margin:0px"> CA will negatively affect the uptime of the \
service.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> To reduce the dependency on external CAs, this \
document proposes a<br> </div>
<div style="margin:0px"> limited delegation mechanism that allows a TLS \
peer to issue its own<br> </div>
<div style="margin:0px"> credentials within the scope of a certificate \
issued by an external<br> </div>
<div style="margin:0px"> CA. These credentials only enable the \
recipient of the delegation to<br> </div>
<div style="margin:0px"> speak for names that the CA has \
authorized. For clarity, we will<br> </div>
<div style="margin:0px"> refer to the certificate issued by the CA as a \
"certificate", or<br> </div>
<div style="margin:0px"> "delegation certificate", and the one \
issued by the operator as a<br> </div>
<div style="margin:0px"> "delegated credential" or \
"DC".<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">From the text it is unclear why the<br>
</div>
<div style="margin:0px">signature scheme appears to be a<br>
</div>
<div style="margin:0px">constraint as well how it does not opens<br>
</div>
<div style="margin:0px">to some sort of downgrade attacks if<br>
</div>
<div style="margin:0px">left to the operator. <br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">3. Solution Overview<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">3.1. Rationale<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Delegated credentials present a better \
alternative than other<br> </div>
<div style="margin:0px"> delegation mechanisms like proxy certificates \
[RFC3820] for several<br> </div>
<div style="margin:0px"> reasons:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * There is no change needed to certificate \
validation at the PKI<br> </div>
<div style="margin:0px"> layer.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * X.509 semantics are very rich. \
This can cause unintended<br> </div>
<div style="margin:0px"> consequences if a service owner creates \
a proxy certificate where<br> </div>
<div style="margin:0px"> the properties differ from the leaf \
certificate. For this reason,<br> </div>
<div style="margin:0px"> delegated credentials have very \
restricted semantics that should<br> </div>
<div style="margin:0px"> not conflict with X.509 semantics.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * Proxy certificates rely on the \
certificate path building process<br> </div>
<div style="margin:0px"> to establish a binding between the proxy \
certificate and the<br> </div>
<div style="margin:0px"> server certificate. Since the \
certificate path building process<br> </div>
<div style="margin:0px"> is not cryptographically protected, it \
is possible that a proxy<br> </div>
<div style="margin:0px"> certificate could be bound to another \
certificate with the same<br> </div>
<div style="margin:0px"> public key, with different X..509 \
parameters. Delegated<br> </div>
<div style="margin:0px"> credentials, which rely on a \
cryptographic binding between the<br> </div>
<div style="margin:0px"> entire certificate and the delegated \
credential, cannot.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> * Each delegated credential is bound to a \
specific signature<br> </div>
<div style="margin:0px"> algorithm that may be used to sign the \
TLS handshake ([RFC8446]<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Barnes, et al. Expires 28 \
December 2020 [Page 6]<br> \
</div> <div style="margin:0px"><br>
</div>
<div style="margin:0px">Internet-Draft Delegated \
Credentials for TLS June 2020<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> section 4.2.3). This prevents them \
from being used with other,<br> </div>
<div style="margin:0px"> perhaps unintended signature \
algorithms.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">It is not clear to me why there is a<br>
</div>
<div style="margin:0px">"may be used". I suppose it concerns the<br>
</div>
<div style="margin:0px">use of the DC not the algorithm but that<br>
</div>
<div style="margin:0px">was confusing.<span> </span><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">I also believe that the specific<br>
</div>
<div style="margin:0px">signature algorithm to sign the<br>
</div>
<div style="margin:0px">delegated credential could be part of<br>
</div>
<div style="margin:0px">the rational. <br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">3.2. Related Work<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Many of the use cases for delegated credentials \
can also be addressed<br> </div>
<div style="margin:0px"> using purely server-side mechanisms that do not \
require changes to<br> </div>
<div style="margin:0px"> client behavior (e.g., a PKCS#11 interface or a \
remote signing<br> </div>
<div style="margin:0px"> mechanism [KEYLESS]). These mechanisms, \
however, incur per-<br> </div>
<div style="margin:0px"> transaction latency, since the front-end server \
has to interact with<br> </div>
<div style="margin:0px"> a back-end server that holds a private \
key. The mechanism proposed<br> </div>
<div style="margin:0px"> in this document allows the delegation to be \
done off-line, with no<br> </div>
<div style="margin:0px"> per-transaction latency. The figure below \
compares the message flows<br> </div>
<div style="margin:0px"> for these two mechanisms with TLS 1.3 \
[RFC8446].<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Remote key signing:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Client \
Front-End Back-End<br> </div>
<div style="margin:0px"> |----ClientHello--->| \
|<br> </div>
<div style="margin:0px"> |<---ServerHello----| \
|<br> </div>
<div style="margin:0px"> |<---Certificate----| \
|<br> </div>
<div style="margin:0px"> | \
|<---remote sign---->|<br> </div>
<div style="margin:0px"> |<---CertVerify-----| \
|<br> </div>
<div style="margin:0px"> | .... \
| \
|<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Delegated credentials:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Client \
Front-End Back-End<br> </div>
<div style="margin:0px"> | \
|<--DC distribution->|<br> </div>
<div style="margin:0px"> |----ClientHello--->| \
|<br> </div>
<div style="margin:0px"> |<---ServerHello----| \
|<br> </div>
<div style="margin:0px"> |<---Certificate----| \
|<br> </div>
<div style="margin:0px"> |<---CertVerify-----| \
|<br> </div>
<div style="margin:0px"> | .... \
| \
|<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> These two mechanisms can be complementary. \
A server could use<br> </div>
<div style="margin:0px"> credentials for clients that support them, while \
using [KEYLESS] to<br> </div>
<div style="margin:0px"> support legacy clients.<span> </span><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I believe that this sentence does not<br>
</div>
<div style="margin:0px">show any complementary as subcert and<br>
</div>
<div style="margin:0px">KEYLESS are targeting different version<br>
</div>
<div style="margin:0px">of TLS, so they can hardly be<br>
</div>
<div style="margin:0px">complementary. However (and luckily)<br>
</div>
<div style="margin:0px">LURK provides an extension for TLS 1.3<br>
</div>
<div style="margin:0px">[draft-mglt-lurk-tls13] which enable a<br>
</div>
<div style="margin:0px">complementary use of these mechanisms<br>
</div>
<div style="margin:0px">these mechanisms. I believe that would<br>
</div>
<div style="margin:0px">be good to indicate the reason they<br>
</div>
<div style="margin:0px">complement each other which is that LURK<br>
</div>
<div style="margin:0px">protects the credentials for its<br>
</div>
<div style="margin:0px">operations. These operations could be<br>
</div>
<div style="margin:0px">performed in the scope of subcert or TLS<br>
</div>
<div style="margin:0px">1.3.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Note also that in a related section it<br>
</div>
<div style="margin:0px">also worth mentioning that credentials<br>
</div>
<div style="margin:0px">may be managed in different ways and<br>
</div>
<div style="margin:0px">KEYLESS represents an valuable way to<br>
</div>
<div style="margin:0px">protect and manage these credentials in<br>
</div>
<div style="margin:0px">TLS 1.2. However, KEYLESS is known to<br>
</div>
<div style="margin:0px">presents some vulnerabilities (PFS,<br>
</div>
<div style="margin:0px">signing oracle) so the protection<br>
</div>
<div style="margin:0px">remains limited while the LURK extension<br>
</div>
<div style="margin:0px">for TLS 1.2 [draft-mglt-lurk-tls12]<br>
</div>
<div style="margin:0px">addressed these issues and as a result<br>
</div>
<div style="margin:0px">should provide a better protection.<br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">The private key for a delegated credential<br>
</div>
<div style="margin:0px"> can be used in place of a certificate private \
key, so it is important<br> </div>
<div style="margin:0px"> that the Front-End and Back-End are parties that \
have a trusted<br> </div>
<div style="margin:0px"> relationship.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Use of short-lived certificates with automated \
certificate issuance,<br> </div>
<div style="margin:0px"> e.g., with Automated Certificate Managment \
Environment (ACME)<br> </div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">Management<span> </span><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"> [RFC8555], reduces the risk of key compromise, \
but has several<br> </div>
<div style="margin:0px"> limitations. Specifically, it introduces \
an operationally-critical<br> </div>
<div style="margin:0px"> dependency on an external party. It also \
limits the types of<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Barnes, et al. Expires 28 \
December 2020 [Page 7]<br> \
</div> <div style="margin:0px"><br>
</div>
<div style="margin:0px">Internet-Draft Delegated \
Credentials for TLS June 2020<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> algorithms supported for TLS authentication to \
those the CA is<br> </div>
<div style="margin:0px"> willing to issue a certificate for. \
Nonetheless, existing automated<br> </div>
<div style="margin:0px"> issuance APIs like ACME may be useful for \
provisioning delegated<br> </div>
<div style="margin:0px"> credentials.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">4. Delegated Credentials<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> While X.509 forbids end-entity certificates from \
being used as<br> </div>
<div style="margin:0px"> issuers for other certificates, it is valid to \
use them to issue<br> </div>
<div style="margin:0px"> other signed objects as long as the certificate \
contains the<br> </div>
<div style="margin:0px"> digitalSignature KeyUsage ([RFC5280] section \
4.2.1.3). We define a<br> </div>
<div style="margin:0px"> new signed object format that would encode only \
the semantics that<br> </div>
<div style="margin:0px"> are needed for this application. The \
credential has the following<br> </div>
<div style="margin:0px"> structure:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> struct {<br>
</div>
<div style="margin:0px"> uint32 valid_time;<br>
</div>
<div style="margin:0px"> SignatureScheme \
expected_cert_verify_algorithm;<br> </div>
<div style="margin:0px"> opaque \
ASN1_subjectPublicKeyInfo<1..2^24-1>;<br> </div>
<div style="margin:0px"> } Credential;<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> valid_time: Time in seconds relative to \
the beginning of the<br> </div>
<div style="margin:0px"> delegation certificate's notBefore value \
after which the delegated<br> </div>
<div style="margin:0px"> credential is no longer valid. \
This MUST NOT exceed 7 days.<br> </div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I believe the behavior of the "verifying<br>
</div>
<div style="margin:0px">peer" should also be specified maybe<br>
</div>
<div style="margin:0px">with a reference.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> expected_cert_verify_algorithm: The \
signature algorithm of the<br> </div>
<div style="margin:0px"> credential key pair, where the type \
SignatureScheme is as defined<br> </div>
<div style="margin:0px"> in [RFC8446]. This is expected to \
be the same as<br> </div>
<div style="margin:0px"> CertificateVerify.algorithm sent by the \
server. Only signature<br> </div>
<div style="margin:0px"> algorithms allowed for use in \
CertificateVerify messages are<br> </div>
<div style="margin:0px"> allowed. When using RSA, the \
public key MUST NOT use the<br> </div>
<div style="margin:0px"> rsaEncryption OID, as a result, the \
following algorithms are not<br> </div>
<div style="margin:0px"> allowed for use with delegated \
credentials: rsa_pss_rsae_sha256,<br> </div>
<div style="margin:0px"> rsa_pss_rsae_sha384, \
rsa_pss_rsae_sha512.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">It is unclear whether the<br>
</div>
<div style="margin:0px">expected_cert_verify_algorithm and<br>
</div>
<div style="margin:0px">CertificateVerify.algorithm needs to be<br>
</div>
<div style="margin:0px">checked and what needs to be done in<br>
</div>
<div style="margin:0px">case of mismatch (with the RSA caveat).<br>
</div>
<div style="margin:0px">I believe that should be clarified.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> ASN1_subjectPublicKeyInfo: The \
credential's public key, a DER-<br> </div>
<div style="margin:0px"> encoded [X.690] SubjectPublicKeyInfo as \
defined in [RFC5280].<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> The delegated credential has the following \
structure:<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> struct {<br>
</div>
<div style="margin:0px"> Credential cred;<br>
</div>
<div style="margin:0px"> SignatureScheme algorithm;<br>
</div>
<div style="margin:0px"> opaque \
signature<0...2^16-1>;<br> </div>
<div style="margin:0px"> } DelegatedCredential;<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> algorithm: The signature algorithm used to \
verify<br> </div>
<div style="margin:0px"> DelegatedCredential.signature.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I am wondering if any checks should be<br>
</div>
<div style="margin:0px">performed with the<br>
</div>
<div style="margin:0px">CertificateVerify.algorithm or if any<br>
</div>
<div style="margin:0px">algorithm would be acceptable. Unless I<br>
</div>
<div style="margin:0px">am missing something it seems a weak<br>
</div>
<div style="margin:0px">algorithm can be used - assuming the<br>
</div>
<div style="margin:0px">registry contains such weak algorithms.<br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Barnes, et al. Expires 28 \
December 2020 [Page 8]<br> \
</div> <div style="margin:0px"><br>
</div>
<div style="margin:0px">Internet-Draft Delegated \
Credentials for TLS June 2020<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> signature: The delegation, a signature \
that binds the credential to<br> </div>
<div style="margin:0px"> the end-entity certificate's public key \
as specified below. The<br> </div>
<div style="margin:0px"> signature scheme is specified by \
DelegatedCredential.algorithm.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">4.1.1. Server Authentication<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> A client which supports this specification SHALL \
send a<br> </div>
<div style="margin:0px"> "delegated_credential" extension in \
its ClientHello. The body of the<br> </div>
<div style="margin:0px"> extension consists of a SignatureSchemeList:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Barnes, et al. Expires 28 \
December 2020 [Page 9]<br> \
</div> <div style="margin:0px"><br>
</div>
<div style="margin:0px">Internet-Draft Delegated \
Credentials for TLS June 2020<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> struct {<br>
</div>
<div style="margin:0px"> SignatureScheme \
supported_signature_algorithm<2..2^16-2>;<br> </div>
<div style="margin:0px"> } SignatureSchemeList;<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> If the client receives a delegated credential \
without indicating<br> </div>
<div style="margin:0px"> support, then the client MUST abort with an \
"unexpected_message"<br> </div>
<div style="margin:0px"> alert.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> If the extension is present, the server MAY send \
a delegated<br> </div>
<div style="margin:0px"> credential; if the extension is not present, the \
server MUST NOT send<br> </div>
<div style="margin:0px"> a delegated credential. The server MUST \
ignore the extension unless<br> </div>
<div style="margin:0px"> TLS 1.3 or a later version is negotiated.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> The server MUST send the delegated credential as \
an extension in the<br> </div>
<div style="margin:0px"> CertificateEntry of its end-entity certificate; \
the client SHOULD<br> </div>
<div style="margin:0px"> ignore delegated credentials sent as extensions \
to any other<br> </div>
<div style="margin:0px"> certificate.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> The expected_cert_verify_algorithm field MUST be \
of a type advertised<br> </div>
<div style="margin:0px"> by the client in the SignatureSchemeList and is \
considered invalid<br> </div>
<div style="margin:0px"> otherwise. Clients that receive invalid \
delegated credentials MUST<br> </div>
<div style="margin:0px"> terminate the connection with an \
"illegal_parameter" alert.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I am wondering what would prevent any<br>
</div>
<div style="margin:0px">downgrade attacks if the<br>
</div>
<div style="margin:0px">SignatureSchemeList and<br>
</div>
<div style="margin:0px">signature_algorithms have two different<br>
</div>
<div style="margin:0px">sets of lists. My current understanding<br>
</div>
<div style="margin:0px">is that these extensions are handled<br>
</div>
<div style="margin:0px">independently, but I might be missing<br>
</div>
<div style="margin:0px">something.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">I am wondering if that would be<br>
</div>
<div style="margin:0px">appropriated to specify the signature of<br>
</div>
<div style="margin:0px">the CertificateVerify depending on the<br>
</div>
<div style="margin:0px">presence of the delegated credential - I<br>
</div>
<div style="margin:0px">mean the key used to generate it.<span> </span><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">4.1.3. Validating a Delegated Credential<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> On receiving a delegated credential and a \
certificate chain, the peer<br> </div>
<div style="margin:0px"> validates the certificate chain and matches the \
end-entity<br> </div>
<div style="margin:0px"> certificate to the peer's expected \
identity. It also takes the<br> </div>
<div style="margin:0px"> following steps:<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> 1. Verify that the current time is within \
the validity interval of<br> </div>
<div style="margin:0px"> the credential. This is done \
by asserting that the current time<br> </div>
<div style="margin:0px"> is no more than the delegation \
certificate's notBefore value plus<br> </div>
<div style="margin:0px"> \
DelegatedCredential.cred.valid_time.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> 2. Verify that the credential's remaining \
validity time is no more<br> </div>
<div style="margin:0px"> than the maximum validity \
period. This is done by asserting that<br> </div>
<div style="margin:0px"> the current time is no more than \
the delegation certificate's<br> </div>
<div style="margin:0px"> notBefore value plus \
DelegatedCredential.cred.valid_time plus the<br> </div>
<div style="margin:0px"> maximum validity period.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> 3. Verify that \
expected_cert_verify_algorithm matches the scheme<br> </div>
<div style="margin:0px"> indicated in the peer's \
CertificateVerify message and that the<br> </div>
<div style="margin:0px"> algorithm is allowed for use with \
delegated credentials.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I am wondering if a reference to specify<br>
</div>
<div style="margin:0px">what allowed would not be needed unless<br>
</div>
<div style="margin:0px">it means advertised in the extension. <br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> 4. Verify that the end-entity certificate \
satisfies the conditions<br> </div>
<div style="margin:0px"> in Section 4.2.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> 5. Use the public key in the peer's \
end-entity certificate to verify<br> </div>
<div style="margin:0px"> the signature of the credential \
using the algorithm indicated by<br> </div>
<div style="margin:0px"> DelegatedCredential.algorithm.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> If one or more of these checks fail, then the \
delegated credential is<br> </div>
<div style="margin:0px"> deemed invalid. Clients and servers that \
receive invalid delegated<br> </div>
<div style="margin:0px"> credentials MUST terminate the connection with \
an "illegal_parameter"<br> </div>
<div style="margin:0px"> alert. If successful, the participant \
receiving the Certificate<br> </div>
<div style="margin:0px"> message uses the public key in the credential to \
verify the signature<br> </div>
<div style="margin:0px"> in the peer's CertificateVerify message.<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">7. Security Considerations<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">[...]<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">7.6. The Impact of Signature Forgery Attacks<br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> When TLS 1.2 servers support RSA key exchange, \
they may be vulnerable<br> </div>
<div style="margin:0px"> to attacks that allow forging an RSA signature \
over an arbitrary<br> </div>
<div style="margin:0px"> message [BLEI]. TLS 1.2 [RFC5246] (Section \
7.4.7.1.) describes a<br> </div>
<div style="margin:0px"> mitigation strategy requiring careful \
implementation of timing<br> </div>
<div style="margin:0px"> resistant countermeasures for preventing these \
attacks. Experience<br> </div>
<div style="margin:0px"> shows that in practice, server implementations \
may fail to fully stop<br> </div>
<div style="margin:0px"> these attacks due to the complexity of this \
mitigation [ROBOT]. For<br> </div>
<div style="margin:0px"> TLS 1.2 servers that support RSA key exchange \
using a DC-enabled end-<br> </div>
<div style="margin:0px"> entity certificate, a hypothetical signature \
forgery attack would<br> </div>
<div style="margin:0px"> allow forging a signature over a delegated \
credential. The forged<br> </div>
<div style="margin:0px"> credential could then be used by the attacker as \
the equivalent of a<br> </div>
<div style="margin:0px"> man-in-the-middle certificate, valid for 7 \
days.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"><mglt><br>
</div>
<div style="margin:0px">I do not see the relevance to TLS 1.3.<span> </span><br>
</div>
<div style="margin:0px"></mglt><br>
</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Server operators should therefore minimize the \
risk of using DC-<br> </div>
<div style="margin:0px"> enabled end-entity certificates where a \
signature forgery oracle may<br> </div>
<div style="margin:0px"> be present. If possible, server operators \
may choose to use DC-<br> </div>
<div style="margin:0px"> enabled certificates only for signing \
credentials, and not for<br> </div>
<div style="margin:0px"> serving non-DC TLS traffic. Furthermore, \
server operators may use<br> </div>
<div style="margin:0px"> elliptic curve certificates for DC-enabled \
traffic, while using RSA<br> </div>
<div style="margin:0px"> certificates without the DelegationUsage \
certificate extension for<br> </div>
<div style="margin:0px"> non-DC traffic; this completely prevents such \
attacks.<br> </div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px"> Note that if a signature can be forged over an \
arbitrary credential,<br> </div>
<div style="margin:0px"> the attacker can choose any value for the \
valid_time field. Repeated<br> </div>
<div style="margin:0px"> signature forgeries therefore allow the attacker \
to create multiple<br> </div>
<div style="margin:0px"> delegated credentials that can cover the entire \
validity period of<br> </div>
<div style="margin:0px"> the certificate. Temporary exposure of the \
key or a signing oracle<br> </div>
<div style="margin:0px"> may allow the attacker to impersonate a server \
for the lifetime of<br> </div>
<div style="margin:0px"> the certificate.<br>
</div>
<div style="margin:0px"><br style="font-size:16px; \
background-color:rgb(255,255,255)"> </div>
</div>
<br>
</div>
<div id="x_gmail-m_2156990323853246716appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_gmail-m_2156990323853246716divRplyFwdMsg" dir="ltr"><font face="Calibri, \
sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> TLS <<a \
href="mailto:tls-bounces@ietf.org" target="_blank">tls-bounces@ietf.org</a>> on \
behalf of Salz, Rich <rsalz=<a href="mailto:40akamai.com@dmarc.ietf.org" \
target="_blank">40akamai.com@dmarc.ietf.org</a>><br> <b>Sent:</b> Monday, June 29, \
2020 12:00 PM<br> <b>To:</b> Joseph Salowey <<a href="mailto:joe@salowey.net" \
target="_blank">joe@salowey.net</a>>; <<a href="mailto:tls@ietf.org" \
target="_blank">tls@ietf.org</a>> <<a href="mailto:tls@ietf.org" \
target="_blank">tls@ietf.org</a>><br> <b>Subject:</b> Re: [TLS] 2nd WGLC for \
Delegated Credentials for TLS</font> <div> </div>
</div>
<div lang="EN-US">
<div>
<div>
<div>
<div>
<div>
<p>I’d still like to see test vectors.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--===============2644179229364981062==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic