Subject: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise

From: Roland Shoemaker <[email-masked]>
Date: Wed, 22 Mar 2017 14:08:04 -0700

Internally at LE we have been having discussions around how the spec can
most effectively reduce the harm of account key compromise and it seems
like it could be a good topic to bring up at the upcoming IETF meeting.

We've come up with two distinct but not mutually exclusive ideas on this
topic:

* Deactivating authorizations on key roll-over, summarized here:
https://www.ietf.org/mail-archive/web/acme/current/msg01747.html
* Only allowing a single valid authorization per name to exist at the
same time, summarized here:
https://www.ietf.org/mail-archive/web/acme/current/msg01661.html

Both of these proposals would be relatively large changes to the current
follow and introduce certain issues for both individual users and large
service integrators and could definitely use some public discussion
before the spec is finalized.

It would also be good to hear if there are any other thoughts from other
implementors/contributors as to how we can best reduce the damage done
by key compromise in general.

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Mar 2017 01:39:35 +0000

I think doing this would reset the WGLC clock; neither seem like minor changes.  We can discuss in Chicago, I hope we can make time, but the WG would definitely have to have consensus on the mailing list.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

> -----Original Message-----
> From: Roland Shoemaker [mailto:[email-masked]]
> Sent: Wednesday, March 22, 2017 5:08 PM
> To: [email-masked]; Salz, Rich; Ted Hardie
> Subject: Possible IETF meeting agenda item: reducing effects of key-
> compromise
> 
> * Only allowing a single valid authorization per name to exist at the same
> time, summarized here:
> follow and introduce certain issues for both individual users and large service
> integrators and could definitely use some public discussion before the spec is
> finalized.
>

---

From: Alan Doherty <[email-masked]>
Date: Thu, 23 Mar 2017 12:44:33 +0000

>https://www.ietf.org/mail-archive/web/acme/current/msg01661.html

i could see potential issues with the second one
(for example name.example.tld is used in both https and smtp-tls, 
https server(reverse proxy) runs its own LE client and obtains a SAN for this and other https names 
smtp server(mx) runs its own LE client and obtains a different SAN for this and other names used in smtp-tls

as both could be running in different parts of an org by different departments (behind the one NAT device)

so i would be more in favor of possibly adding (despite the fact it will likely be a LOT more work)
an exclusive(y/n) toggle to the name authorization system

eg a client account can authorize a name exclusively or non-exclusively 
(to allow exclusivity for those with only one account, and non-exclusivity for those with other needs)

but that said maybe im overthining

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

---

From: Zach Shepherd <[email-masked]>
Date: Thu, 23 Mar 2017 17:11:32 +0000

Section 7.6, Certificate Revocation, states: "Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server SHOULD consider at least the following accounts authorized for a given certificate: ... an account that holds authorizations for all of the identifiers in the certificate."

One way to address this issue would be to replace "all" with "any". That is, allow an account holding authorization for an identifier to revoke any certificate issued for that identifier, even if the certificate is also valid for other identifiers.

Conceptually, I think this makes sense: the purpose of challenges is to verify that the an account is authorized for an identifier only if the account holder is in control of the identifier, and if the account holder is in control of the identifier, they should be able to revoke certificates issued for that identifier.

This does, obviously, have consequences on the security model:
 * Currently, an attacker which gains control of an identifier is able to create or revoke certificates issued for only that identifier. With this change, they would also be able to revoke multi-identifier certificates which include the identifier they have gained control of.
 * This successfully reduces the impact of account key compromise; if an attacker gains control of an account key, any certificates they create can be revoked.
 * This also addresses an additional issue: if an identifier changes ownership, the new owner can revoke existing certificates for that identifier, including multi-identifier certificates.

This would, essentially, be prioritizing confidentiality of each identifier over availability of all identifiers on a multi-identifier certificate. By creating a multi-identifier certificate, users would be "opting in" to this trade-off. To me, this seems like a reasonable trade-off (especially because compromise of an identifier is already catastrophic), but perhaps there are use cases for multi-identifier certificates that I'm not considering.

This seems to have minimal impact on the protocol as well as both client and server implementations.

Regards,

Zach Shepherd

________________________________
From: Acme <[email-masked]> on behalf of Roland Shoemaker <[email-masked]>
Sent: Wednesday, March 22, 2017 2:08 PM
To: [email-masked]; Salz, Rich; Ted Hardie
Subject: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise

* Deactivating authorizations on key roll-over, summarized here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_acme_current_msg01747.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=iGd1H6LLa6yZ1eailcLMJAatf_sYvR9g1BIAcBmsQig&e=
* Only allowing a single valid authorization per name to exist at the
same time, summarized here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_acme_current_msg01661.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=UbH6UN-99PK6TbADeVA6J3Yvf72wYVyKd7NoK5IKNEk&e=

_______________________________________________
Acme mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=DIKow_UF52PW12xZNcT5yhSFtlsjhnjM4W1wNPgMOvc&e=

---

From: Niklas Keller <[email-masked]>
Date: Thu, 23 Mar 2017 19:04:44 +0100

2017-03-23 18:11 GMT+01:00 Zach Shepherd <[email-masked]>:

> Section 7.6, Certificate Revocation, states: "Before revoking a
> certificate, the server MUST verify that the key used to sign the request
> is authorized to revoke the certificate. The server SHOULD consider at
> least the following accounts authorized for a given certificate: ... an
> account that holds authorizations for all of the identifiers in the
> certificate."
>
> One way to address this issue would be to replace "all" with "any". That
> is, allow an account holding authorization for an identifier to revoke any
> certificate issued for that identifier, even if the certificate is also
> valid for other identifiers.
>
> Conceptually, I think this makes sense: the purpose of challenges is to
> verify that the an account is authorized for an identifier only if the
> account holder is in control of the identifier, and if the account holder
> is in control of the identifier, they should be able to revoke certificates
> issued for that identifier.
>
>  * Currently, an attacker which gains control of an identifier is able to
> create or revoke certificates issued for only that identifier. With this
> change, they would also be able to revoke multi-identifier certificates
> which include the identifier they have gained control of.
>  * This successfully reduces the impact of account key compromise; if an
> attacker gains control of an account key, any certificates they create can
> be revoked.
>  * This also addresses an additional issue: if an identifier changes
> ownership, the new owner can revoke existing certificates for that
> identifier, including multi-identifier certificates.
>
> This would, essentially, be prioritizing confidentiality of each
> identifier over availability of all identifiers on a multi-identifier
> certificate. By creating a multi-identifier certificate, users would be
> "opting in" to this trade-off. To me, this seems like a reasonable
> trade-off (especially because compromise of an identifier is already
> catastrophic), but perhaps there are use cases for multi-identifier
> certificates that I'm not considering.
>

This might be problematic for services like Cloudflare which use one
certificate for multiple customers. One of them might authorize for their
own domain as well and could then revoke the Cloudflare certificate,
affecting multiple customers.

On the other hand, requiring all identifiers to be authorized could result
in an attacker with a compromised key to request a certificate with
additional SANs which the original owner doesn't have any control of, then
it's impossible for the original owner to revoke these.

Regards, Niklas

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 23 Mar 2017 13:55:54 -0700

I think Zach raises a really interesting point, and I think Niklas'
response is spot on. To rephrase it a bit: If ACME allowed "any"
hostname on a cert to revoke it, a multi-SAN certificate could be
revoked by the owner of any domain name on that certificate.

That would effectively prevent hosting providers and CDNs from using
multi-SAN certificates with ACME, because it would allow one customer to
revoke a certificate in active use by other customers.

In theory this problem could be solved by using only single-SAN
certificates, but since several hosting providers and CDNs are already
using ACME successfully in a multi-SAN use case, that would be a step
backwards.

Probably it's best to just document this as an issue: An attacker who
compromises a web server can request a cert for that web server's
hostname, plus an attacker-controlled hostname, preventing automated
revocation. In that case, the owner of the web server will need to rely
on the CA's certificate problem reporting system to get the certificate
revoked. Not ideal, but I don't see a lot of other choices.

On 03/23/2017 11:04 AM, Niklas Keller wrote:
> 2017-03-23 18:11 GMT+01:00 Zach Shepherd <[email-masked]
> <mailto:[email-masked]>>:
>
>     certificate, the server MUST verify that the key used to sign the
>     request is authorized to revoke the certificate. The server SHOULD
>     consider at least the following accounts authorized for a given
>     certificate: ... an account that holds authorizations for all of
>     the identifiers in the certificate."
>
>     One way to address this issue would be to replace "all" with
>     "any". That is, allow an account holding authorization for an
>     identifier to revoke any certificate issued for that identifier,
>     even if the certificate is also valid for other identifiers.
>
>     Conceptually, I think this makes sense: the purpose of challenges
>     is to verify that the an account is authorized for an identifier
>     only if the account holder is in control of the identifier, and if
>     the account holder is in control of the identifier, they should be
>     able to revoke certificates issued for that identifier.
>
>      * Currently, an attacker which gains control of an identifier is
>     able to create or revoke certificates issued for only that
>     identifier. With this change, they would also be able to revoke
>     multi-identifier certificates which include the identifier they
>     have gained control of.
>      * This successfully reduces the impact of account key compromise;
>     if an attacker gains control of an account key, any certificates
>     they create can be revoked.
>      * This also addresses an additional issue: if an identifier
>     changes ownership, the new owner can revoke existing certificates
>     for that identifier, including multi-identifier certificates.
>
>     identifier over availability of all identifiers on a
>     multi-identifier certificate. By creating a multi-identifier
>     certificate, users would be "opting in" to this trade-off. To me,
>     this seems like a reasonable trade-off (especially because
>     compromise of an identifier is already catastrophic), but perhaps
>     there are use cases for multi-identifier certificates that I'm not
>     considering.
>
> certificate for multiple customers. One of them might authorize for
> their own domain as well and could then revoke the Cloudflare
> certificate, affecting multiple customers.
>
> On the other hand, requiring all identifiers to be authorized could
> result in an attacker with a compromised key to request a certificate
> with additional SANs which the original owner doesn't have any control
> of, then it's impossible for the original owner to revoke these.
>
> Regards, Niklas  
>
>