Subject: Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 11:06:55 +0000

Sean,

We've had some additional discussions in person here at IETF 99 with folks
who were in the proxy certificates and short-lived certs camp, and we think
there is now more agreement that the mechanism described in this draft is
superior to the alternatives. I've included a summary of some of the pros
and cons of the approaches:

*Proxy certificates vs. Delegated Credentials*
*Pro proxy certificates*:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
*Con proxy certificates*:
- Proxy certificates adds additional complexity to the delegation other
than limiting the time period (full X.509, additional constraints  such as
hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as
part of TLS:
-- There have been problems and inconsistencies around pathlen and
constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated
creds (which can easily be implemented in TLS as demonstrated by the 3
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE
cert. This is a binding weaker than delegated credentials which includes a
signature over the EE certificate.

*Short-lived certs vs. Delegated Credentials*
*Pro short-lived certs*:
- Short lived certs work with existing libraries, no new code changes.
*Con short-lived certs*:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be
logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must
provide proof of domain possession to CA vs. internally managed credential
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials
you can fall back to a LURK-style protocol with the long-lived certificate
key.

Given these comparisons, we think the proposed draft is the superior option
and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner <[email-masked]> wrote:

> All,
>
> During the WG call for adoption, a couple of questions were raised about
> comparison/analysis of sub-certs versus proxy and/or short-lived
> certificates.  There is some discussion currently in the draft, but the
> chairs feel that these issues need further discussion (and elaboration in
> the draft) prior to WG adoption.  So let’s keep the conversation going.
>
> J&S
>
> > On Apr 12, 2017, at 15:31, Sean Turner <[email-masked]> wrote:
> >
> > All,
> >
> > At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the
> list so please let the list know whether you support adoption of the draft
> and are willing to review/comment on the draft before 20170429.  If you
> object to its adoption, please let us know why.
> >
> > Clearly, the WG is going to need to work through the trade-offs between
> short-lived certificates and sub-certs because both seem, to some, to be
> addressing the same problem.
> >
> > Cheers,
> >
> > J&S
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Tue, 18 Jul 2017 11:40:40 +0000

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per se.

I had expressed a couple of concerns at the time the call for adoption was first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who were in the proxy certificates and short-lived certs camp, and we think there is now more agreement that the mechanism described in this draft is superior to the alternatives. I've included a summary of some of the pros and cons of the approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated creds (which can easily be implemented in TLS as demonstrated by the 3 interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE cert. This is a binding weaker than delegated credentials which includes a signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must provide proof of domain possession to CA vs. internally managed credential minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials you can fall back to a LURK-style protocol with the long-lived certificate key.

Given these comparisons, we think the proposed draft is the superior option and would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
All,

During the WG call for adoption, a couple of questions were raised about comparison/analysis of sub-certs versus proxy and/or short-lived certificates.  There is some discussion currently in the draft, but the chairs feel that these issues need further discussion (and elaboration in the draft) prior to WG adoption.  So let’s keep the conversation going.

J&S

> On Apr 12, 2017, at 15:31, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170429.  If you object to its adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between short-lived certificates and sub-certs because both seem, to some, to be addressing the same problem.
>
> Cheers,
>
> J&S
>

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 12:45:41 +0000

> - Potentially problematic to the CT ecosystem (all certificates must be logged in CT, which may bloat them).

That's a browser policy, not an IETF requirement, right?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 12:47:21 +0000

> That's a browser policy, not an IETF requirement, right?

And to be even more pedantic, it's the possible-future policy of Chrome, but not yet required nor implemented

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 13:19:57 +0000

It's a reality of the current CT system. If a crawler sees a short-lived
certificate, it will submit it to a CT log and it will be accepted.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 13:35:00 +0000

Thomas,

Thanks for your comments. Let me see if I can summarize them:

- A disadvantage of delegated credentials vs short-lived certs is that it
requires client opt-in. This is also a disadvantage of proxy certificates.
If client support is below 100%, a LURK-type system may be required to keep
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software
updates on both client and server. This is also a disadvantage of proxy
certificates. I think this is covered by my point below: "Short lived certs
work with existing libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by
a third party (either the CA's internal logs and optionally Certificate
Transparency logs).

I should state that short-lived certificates are possible right now and
it's supported by some CAs, though not necessarily at the scale needed to
provide, say, a unique 7-day certificate for each server of a large
Internet company. This draft's advantages apply most strongly to
organizations who don't want to tie their ability to have functional TLS on
the ability for CAs to maintain high-availability issuance services.  How
much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <
[email-masked]> wrote:

> I had expressed a couple of concerns at the time the call for adoption was
> first issued [1], which I think are still valid.
>
>
>
> On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Sean,
>
> -- Requires frequent exchanges with an external Certificate Authority
> (must provide proof of domain possession to CA vs. internally managed
> credential minter for delegated credentials).
>
> Given these comparisons, we think the proposed draft is the superior
> option and would like to continue the discussion about adopting it.
>
>
>
> Nick
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 13:56:50 +0000

Okay, you said “potentially” a problem.  I guess so.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Tue, 18 Jul 2017 16:26:06 +0000

Hi Nick,

Your write-up is spot on, thanks.

Let me comment on a few points:

“How much Delegated Credentials can be rotated and diversified inside an organization is only limited by the operational ability of the organization that has control of the EE private key.”

The self-service/agile nature of D-C is great. With that, though, comes a cost of ownership that maybe not all players can afford.

There should be ways to mitigate this, say allowing the next S-T in line to be available “long enough” before it becomes active.

I understand the logics but, since LURK boxes don’t scale, the cost to cover your entire footprint for the sporadic cases when the CA is down might be a bit prohibitive.

Cheers, t

On 18/07/2017, 14:35, "Nick Sullivan" <[email-masked]<mailto:[email-masked]>> wrote:

Thomas,
Thanks for your comments. Let me see if I can summarize them:
- A disadvantage of delegated credentials vs short-lived certs is that it requires client opt-in. This is also a disadvantage of proxy certificates. If client support is below 100%, a LURK-type system may be required to keep long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software updates on both client and server. This is also a disadvantage of proxy certificates. I think this is covered by my point below: "Short lived certs work with existing libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by a third party (either the CA's internal logs and optionally Certificate Transparency logs).
I should state that short-lived certificates are possible right now and it's supported by some CAs, though not necessarily at the scale needed to provide, say, a unique 7-day certificate for each server of a large Internet company. This draft's advantages apply most strongly to organizations who don't want to tie their ability to have functional TLS on the ability for CAs to maintain high-availability issuance services.  How much Delegated Credentials can be rotated and diversified inside an organization is only limited by the operational ability of the organization that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nick,

Cheers, thanks,
t

Sean,

Nick

J&S

---

From: Watson Ladd <[email-masked]>
Date: Tue, 18 Jul 2017 09:34:27 -0700

On Jul 18, 2017 9:26 AM, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <
[email-masked]> wrote:

Hi Nick,

“How much Delegated Credentials can be rotated and diversified inside an
organization is only limited by the operational ability of the organization
that has control of the EE private key.”

The self-service/agile nature of D-C is great. With that, though, comes a
cost of ownership that maybe not all players can afford.

Outsourcing to get to something like short lived certs is possible here. If
you can put a cert on a webserver I'm sure you can put it on a delegated
credential creator and point your server at it.

There should be ways to mitigate this, say allowing the next S-T in line to
be available “long enough” before it becomes active.

I understand the logics but, since LURK boxes don’t scale, the cost to
cover your entire footprint for the sporadic cases when the CA is down
might be a bit prohibitive.

CA reliability is not good.

Cheers, t

On 18/07/2017, 14:35, "Nick Sullivan" <[email-masked]> wrote:

Thomas,

Nick

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing
per se.

Cheers, thanks,

t

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" <[email-masked]
on behalf of [email-masked]> wrote:

Sean,

*Pro short-lived certs*:

*Con short-lived certs*:

Nick

All,

J&S

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 18 Jul 2017 23:06:34 +0200

On 18/07/17 18:34, Watson Ladd wrote:
>
>     I understand the logics but, since LURK boxes don’t scale, the
>     cost to cover your entire footprint for the sporadic cases when
>     the CA is down might be a bit prohibitive.
>
>
 From my own experience, I agree that CA reliability is "not good". 
However if I'm using short-term certs with say, a 7 day validity, and 
(per draft-ietf-acme-star) the next certificate is issued halfway 
through this period, it means that the CA has to to be unavailable for 
all of 3.5 days for the failure to affect the delegated site. That's a 
lot, even for a CA.

On the other hand the LURK signing box (though managed by the same 
organization, which is a clear benefit) needs to be available at the 
same level of the delegated site - 99.99% of the time or whatever your 
standard is.

Thanks,
     Yaron

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 Jul 2017 10:27:48 -0400

Nick:

Thanks for this summary.  This resolves my previous concerns.

Russ

> On Jul 18, 2017, at 7:06 AM, Nick Sullivan <[email-masked]> wrote:
> 
> Sean,
> 
> On Fri, May 19, 2017 at 12:58 AM Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
> All,
> 
> > On Apr 12, 2017, at 15:31, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > All,
> >
> > [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts <https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>