Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-06.txt

From: [email-masked]
Date: Wed, 05 Feb 2020 12:36:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Delegated Credentials for TLS
        Authors         : Richard Barnes
                          Subodh Iyengar
                          Nick Sullivan
                          Eric Rescorla
	Filename        : draft-ietf-tls-subcerts-06.txt
	Pages           : 15
	Date            : 2020-02-05

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-subcerts-06
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 9 Feb 2020 16:02:42 +0200

I noticed the following:

> The algorithm and expected_cert_verify_algorithm fields MUST be of a
> type advertised by the client in the SignatureSchemeList and are
> considered invalid otherwise.  Clients that receive invalid delegated
> credentials MUST terminate the connection with an "illegal_parameter"
> alert.

This can be interpretted that the delegated_credentials extension
constrains the end-entity certificate algorithm if DC is sent. This has
seemingly undesirable consequences if the list diverges from what the
signature_algorithms contains:

1) If delegated_credentials contains algorithm that signature_algorithms
does not, the server may use that as DC signing algorithm, which will
cause PKIX code to blow up.

2) If delgated_credentials is missing some algorithm that
signature_algorithms contains, the client needs to constrain the PKIX
validation further.

These issues are made worse by the fact that delegated credential
validation code is seemingly intended to be separate from PKIX validation
code, meaning the two can diverge from one another (which is a reason
for having separate lists).

Looking at the steps to validate the delegated credential, there is
no explicit step to validate signing algorithm, which would imply that
the signing algorithm is constrained by the PKIX code, which would
contradict the above.

Then because *_rsae is not allowed in expected algorithm, clients would
need to include algorithm that can not be used, if they support *_rsae
for PKIX signatures (however, there could be reasons not to support
*_rsae for signing DCs, see below).

And:

> The algorithm and expected_cert_verify_algorithm fields MUST be of a
> type advertised by the server in the "signature_algorithms" extension
> and are considered invalid otherwise.  Servers that receive invalid
> delegated credentials MUST terminate the connection with an
> "illegal_parameter" alert.

Is there a reason why client can specify another set of algorithms for
verification of delegated credentials, but the server can not?

Then in security considerations, I do not see the following issue
discussed:

- Server has RSA key that has delegation_usage and is usable for
  RSA encryption.
- Server is vulernable to BB98/ROBOT.
- Attacker uses BB98/ROBOT to sign a delegated credential.
- Attacker impersonates the server using the forged delegated
  credential.

It is much easier to perform this kind of attack than to use BB98/ROBOT
to impersonate without delgated credentials:

- Much longer time window to perform the attack (limited by certificate
  lifetime, not how long client waits).
- One can impersonate server multiple times per successful attack, not
  just once.

This could be generalized to any signing oracle, but the ones
associated with RSA encryption (BB98/ROBOT/DROWN) are the most common
ones.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Feb 2020 08:33:00 -0800

> for having separate lists).

I think the intent of the change was to make two separate lists so the
TLS implementation could implement new signature schemes and DCs with
those keys could be issued, while being signed by existing certs that
would be selected based on what the PKIX library allows.  The PKIX
library is only checking the validity of the EE certificate and the
chain to the root, the signature by the EE certificate on the DC is
only being checked by the TLS library. The PKIX library never sees the
DC, and what is in delegated_credentials doesn't matter for the EE to
root verification.

> associated with RSA encryption (BB98/ROBOT/DROWN) are the most common

Should we explicitly prohibit including the credential and supporting
RSA decryption? Unfortunately I seem to recall PKIX doesn't have a way
to do this because of widespread compatibility issues.

Sincerely,
Watson Ladd

>
>
>
>
>
> -Ilari
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Carrick Bartle <[email-masked]>
Date: Thu, 13 Feb 2020 15:45:50 -0800

TL;DR: I find it difficult to understand the second-to-last paragraph of the Introduction, so I took a stab at revising it. Let me know if I should put it in a pull request.

This is the paragraph I'm referring to:

"These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low- trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases that they do not realize a compromise has occurred. The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials. In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446], if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance. On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk."

Here are my issues with it:

- I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.

- I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.

- The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.

Taking all these points together, here's my suggestion for a revision to make what I think the thrust of the paragraph is more clear:

"These dependencies cause problems in practice. Server operators often want to create short-lived certificates for servers in low-trust zones such as Content Delivery Network (CDNs) or remote data centers. This allows server operators to limit the exposure of keys in cases where they do not realize a compromise has occurred. But the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short-lived credentials. For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver OCSP stapled response. While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates is even worse: the service that depends on those certificates would go down entirely. Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service."

Carrick

> On Feb 5, 2020, at 12:36 PM, [email-masked] wrote:
> 
>

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 14 Feb 2020 11:27:36 -0800

Ilari,

Thank you for identifying these errors in the document. There was no
intention to allow the client to constrict the server certificate's
algorithm with the delegated_credential extension, and no intention to
restrict the delegated credential's algorithm with the
signature_algorithms. Let me propose some minor text changes to address the
issues.

As a reminder, the CertificateVerify.algorithm is constrained by the
signature_algorithms
extension, as stated in RFC 8446:

   If the CertificateVerify message is sent by a server, the signature
   algorithm MUST be one offered in the client's "signature_algorithms"
   extension unless no valid certificate chain can be produced without
   unsupported algorithms (see Section 4.2.3
<https://tools.ietf.org/html/rfc8446#section-4.2.3>).

Original text from 4.1.2.:

   The expected_cert_verify_algorithm fields MUST be of a
   type advertised by the client in the SignatureSchemeList and are
   considered invalid otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_parameter"
   alert.

proposed text:

   The expected_cert_verify_algorithm field MUST be of a

   type advertised by the client in the SignatureSchemeList and is

   alert.

As for the second point, we did not add the capability for the server to
advertise a different set of signature_algorithms for client authentication
other than the one advertised via the "signature_algorithms" extension.
This was perhaps an oversight. I propose that we add that capability and
I'd be happy to propose a PR to that effect.

The new text of 4.3.2. would look something like:

   A server which supports this specification SHALL send an
   "delegated_credential" extension in the CertificateRequest message
   when requesting client authentication.  The body of the

   extension consists of a SignatureSchemeList.  If the server receives a
   delegated credential without indicating support in its
   CertificateRequest, then the server MUST abort with an
   "unexpected_message" alert.

...

   The algorithm field MUST be of a
   type advertised by the server in the "signature_algorithms" extension

   of the CertificateRequest message and the expected_cert_verify_algorithm

   field MUST be of a type advertised by the client in the SignatureSchemeList

   and considered invalid otherwise.  Clients that receive invalid
   delegated credentials MUST terminate the connection with an
   "illegal_parameter" alert.

Nick

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 14 Feb 2020 11:36:40 -0800

Carrick,

Thank you for reading the document and identifying an embarrassingly
difficult to parse motivating paragraph (with an annoying unclosed
parenthesis to boot). You've correctly identified the meaning it was trying
to convey and we'll happily review this as a PR here:
https://github.com/tlswg/tls-subcerts/. I've noticed a few other
readability issues in the document, if you find anything else, we'll
happily look at those too.

Nick

On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle <cbartle891=
[email-masked]> wrote:

> TL;DR: I find it difficult to understand the second-to-last paragraph of
> the Introduction, so I took a stab at revising it. Let me know if I should
> put it in a pull request.
>
>
> "These dependencies cause problems in practice. Server operators often
> want to create short-lived certificates for servers in low- trust zones
> such as Content Delivery Network (CDNs) or remote data centers. This allows
> server operators to limit the exposure of keys in cases that they do not
> realize a compromise has occurred. The risk inherent in
> cross-organizational transactions makes it operationally infeasible to rely
> on an external CA for such short- lived credentials. In Online Certificate
> Status Protocol (OCSP) stapling (i.e., using the Certificate Status
> extension type ocsp [RFC8446], if an operator chooses to talk frequently to
> the CA to obtain stapled responses, then failure to fetch an OCSP stapled
> response results only in degraded performance. On the other hand, failure
> to fetch a potentially large number of short lived certificates would
> result in the service not being available, which creates greater
> operational risk."
>
> - I think OCSP is being brought up here as an example of a way that
> dependence on a CA can go wrong, but that isn't really made explicit.
>
> - I'm not sure what "only" means in "only in degraded performance." Is it
> "the worst that can happen is just degraded performance" or "it can result
> only in degraded performance, as opposed to better performance"? At first I
> thought it was the latter, but after reading the subsequent sentence, I
> realized it was probably the former.
>
> - The use of "On the other hand" sounds like the rest of the sentence is
> going to describe a way that failure to receive something from a CA
> resulted in better performance, which obviously would be silly.
>
> Taking all these points together, here's my suggestion for a revision to
> make what I think the thrust of the paragraph is more clear:
>
> "These dependencies cause problems in practice. Server operators often
> want to create short-lived certificates for servers in low-trust zones such
> as Content Delivery Network (CDNs) or remote data centers. This allows
> server operators to limit the exposure of keys in cases where they do not
> realize a compromise has occurred. But the risk inherent in
> cross-organizational transactions makes it operationally infeasible to rely
> on an external CA for such short-lived credentials. For instance, in the
> case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the
> Certificate Status extension type ocsp [RFC8446]), a CA may fail to deliver
> OCSP stapled response. While this will result in degraded performance, the
> ramifications of failing to deliver short-lived certificates is even worse:
> the service that depends on those certificates would go down entirely.
> Thus, ensuring independence from CAs for short-lived certificates is
> critical to the uptime of a service."
>
>
> Carrick
>
>
>

---

From: Carrick Bartle <[email-masked]>
Date: Fri, 14 Feb 2020 11:44:46 -0800

Great! I'll push it on over and continue reviewing.

> On Feb 14, 2020, at 11:36 AM, Nick Sullivan <nick=[email-masked]> wrote:
> 
> Carrick,
> 
> Thank you for reading the document and identifying an embarrassingly difficult to parse motivating paragraph (with an annoying unclosed parenthesis to boot). You've correctly identified the meaning it was trying to convey and we'll happily review this as a PR here: https://github.com/tlswg/tls-subcerts/ <https://github.com/tlswg/tls-subcerts/>. I've noticed a few other readability issues in the document, if you find anything else, we'll happily look at those too.
> 
> Nick
> 
> On Thu, Feb 13, 2020 at 3:46 PM Carrick Bartle <cbartle891=[email-masked] <mailto:[email-masked]>> wrote:
> > On Feb 5, 2020, at 12:36 PM, [email-masked] <mailto:[email-masked]> wrote:
> > 
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ <https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/>
> > 
> > https://tools.ietf.org/html/draft-ietf-tls-subcerts-06 <https://tools.ietf.org/html/draft-ietf-tls-subcerts-06>
> > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06 <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-06>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-06>
> > 
> > 
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> > 
> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Feb 2020 10:55:29 +0200

>    credentials MUST terminate the connection with an "illegal_parameter"

The section number looks incorrect (it is about client authentication)
and the original looks to be copied from the new text. Did you mean
section 4.1.1 (Server authentication) and:

OLD:

NEW:

>    "illegal_parameter" alert.

There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean
section 4.1.2 (Client authentication)?  The latter proposed paragraph
seems like it says "client" in two places it should say  "server", did you
mean:

   The algorithm field MUST be of a
   type advertised by the server in the "signature_algorithms" extension
   of the CertificateRequest message and the expected_cert_verify_algorithm
   field MUST be of a type advertised by the server in the SignatureSchemeList
   and considered invalid otherwise.  Servers that receive invalid
   delegated credentials MUST terminate the connection with an
   "illegal_parameter" alert.

-Ilari

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 19 Feb 2020 12:09:39 -0800

Good catches on the section number and server/client questions. Confirming
below.

Here's a PR with the proposed change:
https://github.com/tlswg/tls-subcerts/pull/54

On Sat, Feb 15, 2020 at 12:55 AM Ilari Liusvaara <[email-masked]>
wrote:

> Yes, 4.1.1. I'll put this into a PR.

> section 4.1.2 (Client authentication)?

Yes, 4.1.2 is the right section.

The latter proposed paragraph
>    "illegal_parameter" alert.

Yes, that's correct.