Subject: [Acme] Short term certificates - two options

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jul 2016 11:51:57 +0200

Hi,

At the LURK BoF this week there was some interest in having a solution
where a domain owner can delegate to some other entity (which we will
call "the TLS server") the authority to terminate TLS connections on its
behalf, using short-term certificates. These certificates allow the
domain owner to terminate the TLS server's authorization when necessary,
without requiring certificate revocation - which we know doesn't work
reliably. The certificates' validity is measured in days, e.g. 3 days.

First, I would like to request the working group to adopt short-term
certificates as a charter item.

Second, I would like the group's advice in choosing between two very
different approaches to this problem.

Option 1: Certificate Pull

This option is documented in the LURK draft [1], which will be modified
to include feedback received this week, specifically to use more
traditional certification request (CSR) flows. But the basic idea is
very simple:

1. TLS server generates a CSR once every 3 days for www.example.com,
sends it to the domain owner using an authenticated REST API.

2. Domain owner validates the CSR, forwards it to ACME server, gets back
a short-term cert.

3. Domain owner returns the cert to the TLS server.

If something bad happens, the domain owner simply stops forwarding
requests from this particular TLS server.

Option 2: Certificate Delegation

This option moves more of the responsibility to the ACME server.

1. Domain owner contacts the ACME server and obtains a "delegation
ticket" which is specific to the TLS server. The ticket is good for a
long period, e.g. 1 year.

2. TLS server regularly contacts the ACME server, proves ownership of
the delegation ticket, and receives a short-term certificate.

If something bad happens, the domain owner contacts the ACME server and
revokes the delegation ticket.

Comparison:

1. Option 2 is clearly more complicated to specify and to implement.

2. Option 2 extends the ACME protocol. Many clients can ignore it, but
servers will need to implement it.

3. Option 1 requires the domain owner to have a server available
regularly, even if it is only a short REST interaction once every few
days. Option 2 doesn't require any such server.

4. Option 1 looks to the ACME server as a normal cert request, and
therefore will swamp the CT logs with lots of short-term certs. With
Option 2, we can log to CT the issuance of the delegation ticket instead
of the actual certificates.

I would appreciate your input!

Thanks,

      Yaron

[1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00

---

From: Carl Wallace <[email-masked]>
Date: Wed, 20 Jul 2016 07:04:52 -0400

On 7/20/16, 5:51 AM, "Acme on behalf of Yaron Sheffer"
<[email-masked] on behalf of [email-masked]> wrote:

><snip>

Would there be an indicator in the certificate indicating it is
essentially a proxy certificate? Ideally, relying parties could confirm
the domain owner had a role in the issuance of the certificate.

>servers will need to implement it.

Option 2 could take the form of a non-critical extension. The flow could
be something along these lines:

- TLS server generates a key pair and sends request for delegation ticket
to the domain owner
- The domain owner prepares an X.509 extension containing the key (or key
identifier), any constraints (e.g., name or validity) and the domain
owner's signature covering that information
- TLS server includes the extension in the request for a certificate
(short lived or otherwise but always consistent with constraints in the
extension)
- CA issues a certificate containing the non-critical extension
- TLS clients that want to understand the delegation can verify the
extension, others would carry on without processing the non-critical
extension

If this were always a long-lived certificate, the pre-certificate
mechanism in CT could be adapted with the domain owner signing instead of
the log (or maybe using CT exactly and acting as a special case log), but
this would complicate issuance.

>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme

---

From: Tom Ritter <[email-masked]>
Date: Wed, 20 Jul 2016 06:07:56 -0500

> of the actual certificates.

I think the CT community would strongly oppose this notion (I know I
would.)  As a domain owner, I want to know what certificates are
issued for me - that is the purpose of CT. Logging a delegation ticket
does not accomplish this. An attacker who compromises the delegation
ticket has free reign and I would never know.

Maybe there is a way to make this possible, similar to redacted
certificates, but since implementors of CT can't agree on a good way
to make redaction work functionally, it seems unlikely this would be
adopted by CT in the short order.

-tom

---

From: Niklas Keller <[email-masked]>
Date: Wed, 20 Jul 2016 14:43:45 +0200

> different approaches to this problem.

You can already delegate HTTP-01 by redirecting
`/.well-known/acme-challenge/*` (maybe even just for unknown tokens).

Also, for short-lived certificates, there's already the `notAfter` field
when filing applications for a certificate:

https://ietf-wg-acme.github.io/acme/#rfc.section.6.1.3

Regards, Niklas

---

From: Sean Leonard <[email-masked]>
Date: Wed, 20 Jul 2016 05:52:36 -0700

On 7/20/2016 2:51 AM, Yaron Sheffer wrote:
> [...]
> [...]
> days.

Actually a new certificate needs to be requested at least once per day. 
The 1 day before and 1 day after is for clock skew time. That increases 
all communications by 3x. Possibly much more, if you want your skew time 
to be greater than 24 hours.

If the TLS server:
a) reuses the same private key for the equivalent long-term period (1 
year) and the short-term certificates have a common continuity data item 
(either a certificate extension, or a custom RDN component, containing a 
common identifier such as a UUID), or
b) if each short-term certificate identifies the prior short-term 
certificate (by identifying the prior short-term certificate's serial 
number, or, by reserving the last 9 bits of the serial number to a 
sequence from 0 - 511, to be issued serially to the same TLS server)

...would CT be able to correlate them so as not to overwhelm the logs?

The advantage of the latter-most suggestion(s) is that CT logs could be 
engineered to record a "rolling certificate pack": the certificate 
stored is a single certificate (the base certificate), and the 
certificate is interpolated on a daily basis where the serial number 
bits change as the notBefore and notAfter times advance by a 
predetermined amount of time (e.g., 24 hours). Of course, the signature 
block would change; interpolating those bits would not be sufficient to 
regenerate the rolling certificates unless the signature blocks are 
recorded.

Sean

---

From: Niklas Keller <[email-masked]>
Date: Wed, 20 Jul 2016 15:56:57 +0200

2016-07-20 14:52 GMT+02:00 Sean Leonard <[email-masked]>:

> The 1 day before and 1 day after is for clock skew time. That increases all
> communications by 3x. Possibly much more, if you want your skew time to be
> greater than 24 hours.
>

I guess most ACME issued certificates are currently installed immediately.
The 1 hour backdate of Let's Encrypt seems to be enough to cover most clock
skews. I didn't see any complaints about that specific issue yet, at least.

> number, or, by reserving the last 9 bits of the serial number to a sequence
> from 0 - 511, to be issued serially to the same TLS server)
>

But yes, even if not every day, but every 3 days, I would be a lot of
certificates.

> engineered to record a "rolling certificate pack": the certificate stored
> is a single certificate (the base certificate), and the certificate is
> interpolated on a daily basis where the serial number bits change as the
> notBefore and notAfter times advance by a predetermined amount of time
> (e.g., 24 hours). Of course, the signature block would change;
> interpolating those bits would not be sufficient to regenerate the rolling
> certificates unless the signature blocks are recorded.
>
> Sean
>
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jul 2016 17:32:10 +0200

> this would complicate issuance.

Hi Carl,

I think this could work, but I believe there are use cases 
(specifically, CDNs) where people do not want to advertise the delegation.

Besides, I am personally averse to tweaking X.509. IMO it could make 
standardization much more difficult.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jul 2016 17:37:34 +0200

> adopted by CT in the short order.

Hi Tom,

As far as I understand CT, it is mostly about protecting the rightful 
domain owner from other people issuing their certs for their domains, 
using other CAs. In this case, the delegation ticket is restricted to a 
single CA and so this cannot happen.

BTW, we could associate the delegation ticket with a private key on the 
TLS server which would make it harder to compromise the ticket.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jul 2016 17:40:07 +0200

On 20/07/16 14:43, Niklas Keller wrote:
> 2016-07-20 11:51 GMT+02:00 Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>>:
>
>     Hi,
>

In fact delegating HTTP-01 is a big security issue in the context of 
rogue CDNs (or CDN employees). Please see 
https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00#section-4.3

Thanks,
	Yaron

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 20 Jul 2016 08:43:10 -0700

On Wed, 20 Jul 2016 11:51:57 +0200

> different approaches to this problem.

I prefer option 1, but with a tweak.  I think the server should only be
required to generate and register a new CSR if the key changes.
Otherwise, the CA should automatically sign new certificates
periodically and they should be retrieved from the CA by the TLS server
using a simple unauthenticated GET operation.  (Since
these certs are static, the CA would ideally serve them via a
highly-available CDN environment, much like pre-generated OCSP
responses.) This would be possible if application objects supported
renewals, as I discuss here:
https://mailarchive.ietf.org/arch/msg/acme/NFgZShOcKH38QV1hh-fT3Dnp8bs
If the domain owner wants to revoke a delegation to terminate TLS, they
just have to contact the ACME server and disable the application.

This is a simpler architecture and much more reliable since you only
need to worry about authenticating and proxying CSRs during key
rotation, which presumably doesn't need to happen that often as long as
your TLS connections use forward secrecy.  The normal day-to-day
certificate refreshes wouldn't depend on the domain owner's
server being up, and would also be resilient to brief outages of the
CA's signing infrastructure.

As for swamping CT logs, that's probably a better question for the CT
mailing list.  I will say that the working group has been trying very
hard to minimize the complexity of TLS clients (see redaction).  Doing
things like logging delegations would necessarily complicate TLS
clients (since TLS clients would need to verify the delegations) so I
suspect the answer will be to just log the short-lived certs and focus
on making logs cope (e.g. log rotation so it's easy to rotate logs when
they get too big).

Regards,
Andrew

---

From: Carl Wallace <[email-masked]>
Date: Wed, 20 Jul 2016 11:46:33 -0400

>(specifically, CDNs) where people do not want to advertise the delegation.

I favor solutions where the relying party can be aware of the delegation
if they want to be.

>standardization much more difficult.

Maybe to the certificate issuance process, but for general use existing
clients should just work out of the box.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Jul 2016 16:06:27 +0000

> I favor solutions where the relying party can be aware of the delegation if
> they want to be.

FWIW, in the CDN case origin sites generally *do not* want the end-user to be able to know.

I'd think legitimate origin owner desire trumps general visibility.

---

From: Chris Drake <[email-masked]>
Date: Thu, 21 Jul 2016 07:32:16 +1000

Hi Yaron,

What is the use case for these?

Kind Regards,
Chris Drake

Wednesday, July 20, 2016, 7:51:57 PM, you wrote:

YS> Hi,

YS> At the LURK BoF this week there was some interest in having a solution
YS> where a domain owner can delegate to some other entity (which we will
YS> call "the TLS server") the authority to terminate TLS connections on its
YS> behalf, using short-term certificates. These certificates allow the
YS> domain owner to terminate the TLS server's authorization when necessary,
YS> without requiring certificate revocation - which we know doesn't work
YS> reliably. The certificates' validity is measured in days, e.g. 3 days.

YS> First, I would like to request the working group to adopt short-term
YS> certificates as a charter item.

YS> Second, I would like the group's advice in choosing between two very
YS> different approaches to this problem.

YS> Option 1: Certificate Pull

YS> This option is documented in the LURK draft [1], which will be modified
YS> to include feedback received this week, specifically to use more
YS> traditional certification request (CSR) flows. But the basic idea is
YS> very simple:

YS> 1. TLS server generates a CSR once every 3 days for www.example.com,
YS> sends it to the domain owner using an authenticated REST API.

YS> 2. Domain owner validates the CSR, forwards it to ACME server, gets back
YS> a short-term cert.

YS> 3. Domain owner returns the cert to the TLS server.

YS> If something bad happens, the domain owner simply stops forwarding
YS> requests from this particular TLS server.

YS> Option 2: Certificate Delegation

YS> This option moves more of the responsibility to the ACME server.

YS> 1. Domain owner contacts the ACME server and obtains a "delegation
YS> ticket" which is specific to the TLS server. The ticket is good for a
YS> long period, e.g. 1 year.

YS> 2. TLS server regularly contacts the ACME server, proves ownership of
YS> the delegation ticket, and receives a short-term certificate.

YS> If something bad happens, the domain owner contacts the ACME server and
YS> revokes the delegation ticket.

YS> Comparison:

YS> 1. Option 2 is clearly more complicated to specify and to implement.

YS> 2. Option 2 extends the ACME protocol. Many clients can ignore it, but
YS> servers will need to implement it.

YS> 3. Option 1 requires the domain owner to have a server available
YS> regularly, even if it is only a short REST interaction once every few
YS> days. Option 2 doesn't require any such server.

YS> 4. Option 1 looks to the ACME server as a normal cert request, and
YS> therefore will swamp the CT logs with lots of short-term certs. With
YS> Option 2, we can log to CT the issuance of the delegation ticket instead
YS> of the actual certificates.

YS> I would appreciate your input!

YS> Thanks,

YS>       Yaron

YS> [1] https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Jul 2016 09:45:39 +0200

Sounds interesting, thank you!

I suppose if we have the ACME "application objects" and they support 
renewal/reissuance, that would also apply to my Option 2, i.e. the TLS 
server accessing ACME directly. Of course Option 2 would still require 
an extension of the ACME protocol.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Jul 2016 09:48:33 +0200

Hi Carl,
I agree to both your points in principle, but see Rich's mail.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Jul 2016 09:53:37 +0200

Hi Chris,

The LURK CDN use case is described here: 
https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3

Personally I care more about the case of the TLS server being part of 
the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box), 
and talking to enterprise-based servers that hold the long-term credentials.

Thanks,
	Yaron

---

From: Carl Wallace <[email-masked]>
Date: Thu, 21 Jul 2016 05:43:15 -0400

>I'd think legitimate origin owner desire trumps general visibility.

I am surprised enabling invisibility is a goal. Seems like we may want
that option (which is always available via sharing a P12) but also ought
have a means of enabling end clients to know delegation is in place while
validating the domain owner authorized it. The McGrew TLS proxies paper
from a few years ago may be a good option if TLS mods are on the table.

---

From: Chris Drake <[email-masked]>
Date: Thu, 21 Jul 2016 20:03:41 +1000

Hi Yaron,

The premise seems wrong:
> These certificates allow the domain owner to terminate the TLS server's authorization when necessary, 

What that is technically true, it does not facilitate the *purpose* of the termination (which would be to prevent continued CDN content distribution) - clients can simply ignore the "expired certificate" problem and still get the content.

Trying to build a kludge to use certificates where session keys should be used instead seems a bad-idea(tm) to me.

Kind Regards,
Chris Drake

Thursday, July 21, 2016, 5:53:37 PM, you wrote:

YS> Hi Chris,

YS> The LURK CDN use case is described here: 
YS> https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3

YS> Personally I care more about the case of the TLS server being part of 
YS> the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box),
YS> and talking to enterprise-based servers that hold the long-term credentials.

YS> Thanks,
YS>         Yaron

---

From: Sean Leonard <[email-masked]>
Date: Thu, 21 Jul 2016 03:36:01 -0700

> On Jul 20, 2016, at 2:51 AM, Yaron Sheffer <[email-masked]> wrote:
> 

I just wanted to check some intuition out here.

Would an [RFC5755] Attribute Certificate work effectively as a “delegation ticket”, within the meaning of Option 2 that you’re proposing?

I know people want to hate on ACs, and they aren’t widely deployed. But maybe that would be the right kind of pre-existing protocol element for this sort of thing.

AC has a Holder field; presumably the holder field would identify the the TLS server, the main certificate, or both.

Proving ownership of the delegation ticket, is just transmitting the AC. Possession is sufficient.

ACs can be revoked, as they use the same machinery as regular certificates, via CRLs (and OCSP). Again, component reuse.

ACs are signed, so they are verifiable as coming from the ACME server. If you don’t like full public-key signatures you can generate a “signature” (with a new/appropriate OID) based on some shared secret.

ACs have dates. So that part is satisfied.

You can still hate on ACs and invent some different thing; you could also use SAML or whatever. Just checking the intuition, and thinking about reusing existing componentry. Where do ACs match up, and where do they break down?

Regards,

Sean

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jul 2016 12:38:23 +0200

On 21/07/16 12:03, Chris Drake wrote:
> What that is technically true, it does not facilitate the *purpose* of
> the termination (which would be to prevent continued CDN content
> distribution) - clients can simply ignore the "expired certificate"
> problem and still get the content.
>
> Trying to build a kludge to use certificates where session keys should
> be used instead seems a bad-idea(tm) to me.
>
> Kind Regards,
> Chris Drake
>

Hi Chris,

I am not following your reasoning: the CDN can *always* distribute 
content under a fake or self-signed certificate, even if we have 
real-time termination of its session keys. After all, it (usually) has a 
full copy of the content!

Or are you saying that clients behave differently for expired vs. 
self-signed certs? I am not sure that this is the case.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jul 2016 12:52:25 +0200

> You can still hate on ACs and invent some different thing; you could also use SAML or whatever. Just checking the intuition, and thinking about reusing existing componentry. Where do ACs match up,…

Hi Sean,

Attribute certs would have been a wonderful fit here, but to the best of 
my knowledge, they've never been (widely) implemented. They have been a 
great idea with no practical use since 2002. And if we propose to use 
them here, it's a sure way to kill this option outright.

More specifically, when you say "ACs can be revoked" this is somewhat 
ironic. The generally accepted wisdom is that certificates cannot be 
reliably revoked today, and in fact this is the main reason why we need 
short-term certificates for the CDN use case!

Thanks,
	Yaron

---

From: Richard Barnes <[email-masked]>
Date: Fri, 22 Jul 2016 12:56:42 +0200

On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer <[email-masked]>
wrote:

>> Would an [RFC5755] Attribute Certificate work effectively as a
>> “delegation ticket”, within the meaning of Option 2 that you’re proposing?
>>
>> I know people want to hate on ACs, and they aren’t widely deployed. But
>> maybe that would be the right kind of pre-existing protocol element for
>> this sort of thing.
>>
>> AC has a Holder field; presumably the holder field would identify the the
>> TLS server, the main certificate, or both.
>>
>> ACs can be revoked, as they use the same machinery as regular
>> certificates, via CRLs (and OCSP). Again, component reuse.
>>
>> ACs are signed, so they are verifiable as coming from the ACME server. If
>> you don’t like full public-key signatures you can generate a “signature”
>> (with a new/appropriate OID) based on some shared secret.
>>
>> You can still hate on ACs and invent some different thing; you could also
>> use SAML or whatever. Just checking the intuition, and thinking about
>> reusing existing componentry. Where do ACs match up, and where do they
>> break down?
>>
>> Regards,
>>
>> Sean
>>
>>
> Hi Sean,
>
> great idea with no practical use since 2002. And if we propose to use them
> here, it's a sure way to kill this option outright.
>

Yeah, I sent the following to Sean yesterday and forgot to CC the list:

"""
I mean, technically yes, ACs would work here, in the sense that a tank will
get you to the office :)

I think the more likely candidate is OAuth, since (a) ACME is based on
HTTP, and (b) OAuth is built for delegating authorization.
"""

--Richard

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jul 2016 13:02:13 +0200

On 22/07/16 12:56, Richard Barnes wrote:
>
>
> On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             On Jul 20, 2016, at 2:51 AM, Yaron Sheffer
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
[snip]
>
>         Regards,
>
>         Sean
>
>
>     Hi Sean,
>
>     Attribute certs would have been a wonderful fit here, but to the
>     best of my knowledge, they've never been (widely) implemented. They
>     have been a great idea with no practical use since 2002. And if we
>     propose to use them here, it's a sure way to kill this option outright.
>
>     More specifically, when you say "ACs can be revoked" this is
>     somewhat ironic. The generally accepted wisdom is that certificates
>     cannot be reliably revoked today, and in fact this is the main
>     reason why we need short-term certificates for the CDN use case!
>
>
> I mean, technically yes, ACs would work here, in the sense that a tank
> will get you to the office :)
>

Hi Richard,

It's kind of early for this level of detail, but don't you think a 
simple JWT (https://tools.ietf.org/html/rfc7519) signed by the ACME 
server is sufficient here?

Thanks,
	Yaron

---

From: Sean Leonard <[email-masked]>
Date: Fri, 22 Jul 2016 04:17:13 -0700

> On Jul 22, 2016, at 4:02 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> It's kind of early for this level of detail, but don't you think a simple JWT (https://tools.ietf.org/html/rfc7519) signed by the ACME server is sufficient here?

Uh oh, bike-shedding on specs. ;-)

There are at least four delegation ticket technologies floating around IETF to my knowledge:
attribute certificate
JWT
OAuth
Kerberos

...and I am sure there are others. My overall point is that for Option 2, there was a discussion point that Option 2 would be too complicated to implement: “Option 2 is clearly more complicated to specify and to implement.” Well it has to involve more technology, but if you use an off-the-shelf piece of tech that works, then we don’t need to invent a fifth (or nth) ticket delegation technology that happens to be specific to ACME.

Sean

PS Re: attribute certificates, there is a noRevAvail extension, which allows an issuer to state explicitly that there is no revocation information, so don’t bother checking. This means it’s an option that some issuers can have revocation info and some won’t. Some ppl may be bothered by too many options; others will like the optionality. I don’t think the other delegation ticket technologies have such optionality, as they come to mind.

---

From: Chris Drake <[email-masked]>
Date: Fri, 22 Jul 2016 21:21:03 +1000

Hi Yaron,

Best I can tell, everyone has jumped onto solving a cool problem, without there actually being any reason to solve it?

I asked about the use case, and CDN authority revocation was all I got (imho a really *weak* reason).  Maybe I got it wrong?

What *exactly* is a use case for short-term certificates? What about HSTS/HPKP? 
Why would *any* expired short-term certificate be useful?  Practically no ordinary user cares about bad certs - heck - iPhone users don't even have a way to check a cert even if they wanted to.

Kind Regards,
Chris Drake

Friday, July 22, 2016, 8:38:23 PM, you wrote:

YS> Hi Chris,

YS> I am not following your reasoning: the CDN can *always* distribute 
YS> content under a fake or self-signed certificate, even if we have 
YS> real-time termination of its session keys. After all, it (usually) has a
YS> full copy of the content!

YS> Or are you saying that clients behave differently for expired vs. 
YS> self-signed certs? I am not sure that this is the case.

YS> Thanks,
YS>         Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jul 2016 14:52:06 +0200

On 22/07/16 13:21, Chris Drake wrote:
> Hi Yaron,
>
> Best I can tell, everyone has jumped onto solving a cool problem,
> without there actually being any reason to solve it?
>
> I asked about the use case, and CDN authority revocation was all I got
> (imho a really *weak* reason).  Maybe I got it wrong?
>
> Why would *any* expired short-term certificate be useful?  Practically
> no ordinary user cares about bad certs - heck - iPhone users don't even
> have a way to check a cert even if they wanted to.
>
> Kind Regards,
> Chris Drake
>

Hi Chris,

Can you please explain why CDN authority revocation is a weak use case?

Let me share my preferred use case: I am running a large web property in 
the cloud, where TLS connections are terminated on a cloud-based load 
balancer (Amazon ELB, for a concrete example). I would like the cloud 
provider to present my identity (www.example.com), but I want to revoke 
this authority as soon as something bad happens, e.g. the cloud provider 
is breached.

There may be alternative solutions, but I think short-term certs are a 
reasonable solution here. Either the content owner gives the cloud 
provider a new cert every X days (option 1), or the cloud provider can 
get the short-term cert directly from the CA (option 2).

A solution that certainly CANNOT work is to give the cloud provider a 
regular 1-year cert and revoke it if a breach occurs. Because we know 
that cert revocation doesn't work.

Thanks,
	Yaron

---

From: Chris Drake <[email-masked]>
Date: Sat, 23 Jul 2016 19:44:10 +1000

Hi Yaron,

It's a weak use case, because short-lived certificates do not solve the problem.  I'm not saying CDN revocation is weak (actually - I will say that next, but I wasn't initially) - I *am* saying that trying to accomplish it with short-lived certs isn't sensible; totally the wrong tool for the job.

Not to mention - the idea of your CDN getting beached? - whoever invented that as a reason is clutching at improbable straws!  If you need to stop your CDN distributing your stuff, go erase your content from them; showing "expired certificates" to customers a few days later is totally not going to cut it (nor will it stop the distribution for everyone who ignore those warning, which will be almost everyone.)
Plus - the main idea of a CDN is for speed; regularly changing certs will slow everyone down too.

Kind Regards,
Chris Drake

Friday, July 22, 2016, 10:52:06 PM, you wrote:

YS> Hi Chris,

YS> Can you please explain why CDN authority revocation is a weak use case?

YS> Let me share my preferred use case: I am running a large web property in
YS> the cloud, where TLS connections are terminated on a cloud-based load 
YS> balancer (Amazon ELB, for a concrete example). I would like the cloud 
YS> provider to present my identity (www.example.com), but I want to revoke
YS> this authority as soon as something bad happens, e.g. the cloud provider
YS> is breached.

YS> There may be alternative solutions, but I think short-term certs are a
YS> reasonable solution here. Either the content owner gives the cloud 
YS> provider a new cert every X days (option 1), or the cloud provider can
YS> get the short-term cert directly from the CA (option 2).

YS> A solution that certainly CANNOT work is to give the cloud provider a 
YS> regular 1-year cert and revoke it if a breach occurs. Because we know 
YS> that cert revocation doesn't work.

YS> Thanks,
YS>         Yaron

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 23 Jul 2016 10:12:18 +0000

Browsers check validity time.  They do not look for CRL's; they sometimes look for OCSP status.

"I want to get my content off a CDN" is a valid use-case.  Sometimes it's not a CDN breach, sometimes it's a business decision.  I don't want to erase my content, I want to rotate it across multiple CDN's as my needs change.

---

From: Chris Drake <[email-masked]>
Date: Sun, 24 Jul 2016 08:06:18 +1000

Hi Rich,

> "I want to get my content off a CDN" is a valid use-case. 
Perhaps, however, trying to use short-lived certificates for that is not.

Changing your CDN is a CDN problem, not a certificate problem.  What happens to your content *after* you've changed your CDN is *not* a problem you can fix with certificates.

Kind Regards,
Chris Drake

Saturday, July 23, 2016, 8:12:18 PM, you wrote:

SR> Browsers check validity time.  They do not look for CRL's; they sometimes look for OCSP status.

SR> "I want to get my content off a CDN" is a valid use-case. 
SR> Sometimes it's not a CDN breach, sometimes it's a business
SR> decision.  I don't want to erase my content, I want to rotate it
SR> across multiple CDN's as my needs change.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 24 Jul 2016 01:26:45 +0000

> What happens to your content *after* you've changed your CDN is *not* a problem you can fix with certificates.

Gee, I thought I showed otherwise.

If the certificate expires, the browsers will ignore it.

Ok?

---

From: Chris Drake <[email-masked]>
Date: Sun, 24 Jul 2016 20:52:32 +1000

Hi Rich,

> If the certificate expires, the browsers will ignore it.

Yes, exactly, that is my point.  Certificate expiry is a near-useless mechanism for CDN revocation.

Kind Regards,
Chris Drake

>> What happens to your content *after* you've changed your CDN is *not* a problem you can fix with certificates.

SR> Gee, I thought I showed otherwise.

SR> If the certificate expires, the browsers will ignore it.

SR> Ok?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Jul 2016 17:00:02 +0200

> mechanism for CDN revocation.

By "Ignore", I believe Rich meant "Reject".

-Ekr

---

From: Chris Drake <[email-masked]>
Date: Mon, 25 Jul 2016 08:03:57 +1000

Hi Eric,

Every browser in the world lets you retrieve content despite any kind of certificate problem, expiry included, so no, this idea will never be suitable for CDN revocation.
Certificate expiry will take DAYS before anything at all happens, so no, this idea will never be suitable for CDN revocation *for sure*.

CDN revocation is itself a rare and silly use case to start with.  Banks do not use special paper so that people rolling cigarettes out of them have less-carcinogenic experiences. Yes, it's a use case.  No, it's not sensible.

More people smoke tobacco through banknotes than will ever want to revoke CDN permissions in your use case.

Imagine a bank which kept all it's money in a big pile on the street, with a post-it note stuck there saying "please do not take this money".
This is what you are proposing with your idea.

Maybe there's a valid use case for short-lived certs?  This CDN one is not.

Kind Regards,
Chris Drake

Monday, July 25, 2016, 1:00:02 AM, you wrote:

-Ekr
 
Kind Regards,
Chris Drake

SR> Ok?

---

From: Eric Mill <[email-masked]>
Date: Sun, 24 Jul 2016 18:53:38 -0400

On Sun, Jul 24, 2016 at 6:03 PM, Chris Drake <[email-masked]> wrote:

> Hi Eric,
>
> Every browser in the world lets you retrieve content despite any kind of
> certificate problem, expiry included, so no, this idea will never be
> suitable for CDN revocation.
>

This is not true. Most browsers will flag a full-screen certificate warning
and not allow the user to proceed without clicking through scary text.

Additionally, browsers that support HSTS will not allow users to click
through these warnings at all, for origins which have a statically or
dynamically set HSTS policy.

In both cases, certificate expiration can deter user interaction with an
origin. In the latter case, the barrier to user interaction with the
website behind the expired certificate is very high.

-- Eric

---

From: Chris Drake <[email-masked]>
Date: Mon, 25 Jul 2016 09:13:29 +1000

Hi Eric,

Stop trolling.  If you want to argue, address every point, and leave the thread in place.

>This is not true.
Sorry. It is true.

I'll bet you 1BTC that I can use whatever browser you want to get whatever content you like from any expired-cert site you nominate.  Even if the browser tried hard to stop me, I can always still proxy it too, like https://hide.me/en/proxy 

Kind Regards,
Chris Drake

Monday, July 25, 2016, 8:53:38 AM, you wrote:

This is not true. Most browsers will flag a full-screen certificate warning and not allow the user to proceed without clicking through scary text.

Additionally, browsers that support HSTS will not allow users to click through these warnings at all, for origins which have a statically or dynamically set HSTS policy.

In both cases, certificate expiration can deter user interaction with an origin. In the latter case, the barrier to user interaction with the website behind the expired certificate is very high.

-- Eric

---

From: Eric Mill <[email-masked]>
Date: Sun, 24 Jul 2016 19:17:46 -0400

On Sun, Jul 24, 2016 at 7:13 PM, Chris Drake <[email-masked]> wrote:

>
>
> >> Every browser in the world lets you retrieve content despite any kind
> of certificate problem, expiry included, so no, this idea will never be
> Sorry. It *is *true.
> I'll bet you 1BTC that I can use whatever browser you want to get whatever
> content you like from any expired-cert site you nominate.  Even if the
> browser tried hard to stop me, I can always still proxy it too, like
> https://hide.me/en/proxy
>

That's not a useful counter-example, because the discussion is about
whether expired certificates would be meaningfully effective at stopping
users from interacting with CDN content. Extremely few users have the
interest or ability in taking any of the actions you described -- those who
would do so are not the target audience for the expired certificates.

-- Eric

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 25 Jul 2016 19:38:48 +0300

I think we are slowly but surely getting into the weeds on this one. 
When we talk about "CDN revocation" (for lack of a better term), we mean 
that after a certain date, the owner of the content:

- Does not want the CDN, or a rogue employee of the CDN, to present the 
content as an authoritative source. If the user sees a big browser 
warning, that would *not* look authoritative.

- Does not want the CDN to be able to MITM the site for more sensitive 
traffic, such as POST messages that contain user passwords.

Short-term certs would handle this use case just fine.

And as a content owner, it's really nice to able to leave a CDN whenever 
I want to, without having to rely on it to keep my secrets for a few 
more years while we no longer have a business relationship.

Thanks,
	Yaron

---

From: Alan Doherty <[email-masked]>
Date: Mon, 25 Jul 2016 18:36:44 +0100

i have to ask how/why would you be sending the user to said cdn supplier (via dns)
in the first place 
for them to see said expired cert (plus warnings if client gives them)

i agree, user/owner sudden distrust of a previously trusted cdn is the worst possible reason to demand CAs provide a method to have insanely short (and thus more expensive to provide in terms of resources) certs available

(renewal takes X resources, CA has resources to handle Y normal renewals per 90 days) based on letsencrypt terms
a 2 day cert is x*45 times the resources thus ,to handle the same amount of customers 45 times the server capacity and bandwith to operate

i would suggest for the few requiring/demanding their chosen cdn salt earth and delete all data when they leave policy instead pay the extra at start to have explicit personalised terms of service drawn up with their cdn supplier they will terminate/delete/purge all data within x hours or notification instead

rather than making the CA (and cdn) work harder (not smarter) every day just so they (the owner) can have less hassle the 1 day they quit

automation may make repetitive tasks easier, but its still never good to repeat tasks more often unnecessarily just because automation has made it possible/easy

(especially as a cdn will normally have a maxed out san cert on each ip to enable swapping/loadbalancing reassigning domains to servers on the fly, and thus 1 customer demanding a 2 day renewal basically causes all to be 2 day renewal)

at 17:38 25/07/2016  Monday, Yaron Sheffer wrote:
>I think we are slowly but surely getting into the weeds on this one. When we talk about "CDN revocation" (for lack of a better term), we mean that after a certain date, the owner of the content:
>
>- Does not want the CDN, or a rogue employee of the CDN, to present the content as an authoritative source. If the user sees a big browser warning, that would *not* look authoritative.
>
>- Does not want the CDN to be able to MITM the site for more sensitive traffic, such as POST messages that contain user passwords.
>
>And as a content owner, it's really nice to able to leave a CDN whenever I want to, without having to rely on it to keep my secrets for a few more years while we no longer have a business relationship.
>
>Thanks,
>        Yaron
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 25 Jul 2016 17:38:22 +0000

> i have to ask how/why would you be sending the user to said cdn supplier
> (via dns) in the first place for them to see said expired cert (plus warnings if
> client gives them)

DNS caching.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 25 Jul 2016 21:12:41 +0300

Hi Alan,

Please refer back to my answer. We are talking MITM attacks here, not 
regular operation. The attacker can spoof DNS, e.g. by colluding with a 
local ISP.

Thanks,
	Yaron

---

From: Alan Doherty <[email-masked]>
Date: Mon, 25 Jul 2016 22:42:06 +0100

dns caching is less than a 2 day cert (if sensible dns cache times set by you)

so your talking about a cdn you used to authorize
suddenly becoming an attacker

and dns cache poisoning to do so

(as if switching from a cdn A to cdn B normally you expect to operate through both for whatever time you told ppl to dns cache for rather than have half your clients (seeing old dns) fail suddenly)

if a planned move you would reduce the cache time from say 24h to 5mins, 24 hours prior to the swich, then at the time of the switch re-raise to 24 after testing new dns values work
(so ideally after this 5 mins you can tell the old cdn to purge, most though most wait 24 hours for any bad isps who have told their caches to ignore your cache maximums if below their minimums, (very few nowdays))

either way your 'bad actor' cdn has 2 days with your cert 'fix' so it really dosnt 'fix' them 
also as your ex-cdn being a traceable legal entity (unlike anon blackhat hacker) is sue able easily so i cant see the real world case

and as it really is becominng more edge by the second its way outside of a CAs purview to fix

its the sort of thing i think is not a case for acme having normal or short term certs
but for acme to allow CA to provide fixed term certs

provider/CA  X can decide themselves to profit from your use-scenario by offering
normal user acme api (certs of nominal term)
special user acme api (delivering all certs with a shorter fixed term)

rather than having a selector in the design of the protocol for user custom terms, thus if wanting short lease certs pitch the idea to CAs and see if any is interested in doing business with you, equally finding a cdn willing to adjust their system to accommodate 

(nb a your chosen cdn like your chosen anti-malware provider should be wholey trusted, before use, to not become a hacker tomorrow, or your shopping for both based on the wrong criteria, as both can own you in ways you could never conceivably ever detect, and both rely on their good reputation/security to stay in business, trying to adjust acme, CAs , dns or any other protocol to make it easier to distrust a cdn is pointless, you have to trust them or build/operate your own there is no middle ground)

At 19:12 25/07/2016  Monday, Yaron Sheffer wrote:
>Hi Alan,
>
>Please refer back to my answer. We are talking MITM attacks here, not regular operation. The attacker can spoof DNS, e.g. by colluding with a local ISP.
>
>Thanks,
>        Yaron
>

---

From: Alan Doherty <[email-masked]>
Date: Mon, 25 Jul 2016 22:54:03 +0100

btw cache poisoning is however an idea acme should consider
so it could mandate the verification by CA backends of all dns verification lookups via unrelated sources

aka i submit a http-01 auth of www.my.com
it looks up www.my.com on local dns and performs the verification
it also looks up www.my.com via google-dns and open-dns to verify the returned ip(s) match
if differences occur either
fail and demand another auth method
OR
verify via every ip returned to ensure none is the result of a poisoned local cache (keep alternate sources of dns unlisted so attacker has harder time poisoning 3)
(as differences might occur normally with some cdn load balancing systems)

worth thinking about?

---

From: Patrick Figel <[email-masked]>
Date: Tue, 26 Jul 2016 00:23:30 +0200

On 25/07/16 23:42, Alan Doherty wrote:
> its the sort of thing i think is not a case for acme having normal
> or short term certs but for acme to allow CA to provide fixed term 
> certs
> 
> provider/CA  X can decide themselves to profit from your
> use-scenario by offering normal user acme api (certs of nominal term)
> rather than having a selector in the design of the protocol for user 
> custom terms [...]

Note that the current ACME draft already has "notBefore" and "notAfter"
fields for this purpose. The actual certificate lifetime a CA permits is
a policy decision and shouldn't be anything ACME dictates (which no one
is suggesting).

The question here is whether the kind of "Certificate Delegation" you'd
typically see with a CDN (or similar use-case) should be part of ACME,
or rather something that happens behind the scenes.

I'd lean towards Option 1. Regarding the pro arguments for Option 2:
1. It's not clear whether not submitting the actual certificates to CT
is feasible or even a good idea. How would logging only a delegation
ticket interact with something like Expect-CT (or CT stapling in
general)? Seems like this would require changes to various existing
software infrastructure in order to work. I also don't expect the 3-day
certificates to become the default, so this might be a bit of a
premature optimization with regards to CT submission load if only a
small number of high-profile targets decide to make use of it.
2. The domain owner-controlled "certificate management server" seems
like it would be a more flexible option in general. This would allow
organizations to add their own auditing and validation controls to the
process, as opposed to a simple "here's your delegation ticket, now go
talk to the ACME server." It also doesn't sound like a huge obstacle for
the kind of organization that would even consider the risk of CDN
delegation/revocation, IMO.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 26 Jul 2016 20:07:43 -0400

>I'd think legitimate origin owner desire trumps general visibility.

Use the extension as the means of signaling authorization to the CA. The
CA could omit the extension from the issued certificate when local policy
permits it and include the extension in the certificate when it does not.
Interested parties can verify the extension when present, disinterested
parties can ignore it without penalty.