Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Fri, 23 Jun 2017 19:24:39 +0300

Hi Martin, Thomas,
> Hi Martin,
>
> Thanks for your review.
>
> On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:
>> A few brief comments on this draft.
>>
[snip]
>> I don't understand Section 3.3 at all.  I'd recommend removing this
>> section.  The DNO will decide what authorizations it requests amply
>> without this level of proscription in standards.
> Yaron: thoughts on this?
This is yet another LURK leftover, where we make assumptions about the 
capabilities of the NDC. Prescription makes sense in some particular 
cases, but I agree this should be folded into the security 
considerations (specifically Sec. 5.1) instead of the protocol's body.
>
>> In Section 3.4, the use of the Expires header field is a common
>> mistake.  This is an HTTP caching directive.  It should probably be
>> shorter than the expiration time of the certificate (half in fact),
>> but not for the reasons that you might think.  The purpose of a
>> recommendation on Expires is to ensure that the certificate is not
>> cached beyond the point where a newer certificate will be issued.  You
>> should remove this text.
> OK
Is there some other common header to denote that the value of a URL is 
only good for X time?

[snip]

>
>> Don't mention time-sensitive policy actions by the CA/B Forum.
> Makes sense.
I disagree. CA/B forum decisions (unlike IETF standards) are mandatory 
for some parties to follow and so can be relied upon by the DNO.
>
>> Can't you simply ensure that the CDN can't modify the CAA record?
> This is the minimum we could say.  At this point, I think we are trying
> to explore a bit what other mitigations can be put in place.
Unfortunately this is insufficient, because in the case of CDN's, some 
of the authorization methods are subject to spoofing.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Jun 2017 10:52:07 +1000

On 24 June 2017 at 02:24, Yaron Sheffer <[email-masked]> wrote:
>>> Expires is to ensure that the certificate is not
> Is there some other common header to denote that the value of a URL is only
> good for X time?

Isn't enough to rely on the server echoing your parameters?  (Another
reason to use absolute values for the end of the recurring interval.)

> I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for
> some parties to follow and so can be relied upon by the DNO.

This is a protocol.  What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.

> Unfortunately this is insufficient, because in the case of CDN's, some of
> the authorization methods are subject to spoofing.

If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 25 Jun 2017 17:56:30 +0300

> reason to use absolute values for the end of the recurring interval.)
I'm not following you. In Sec. 3.4 we're saying that the (periodically 
rolling) certificate is always available on the same URL, the 
"certificate endpoint". Since the content available at that URL changes 
from time to time, we wanted to indicate its end-of-validity with an 
HTTP header. If "Expires" is not the right header, is there a better way 
to do it?
> They aren't the only ones creating policy that might affect someone
But people are not obligated to implement IETF protocols. OTOH some 
organizations *are* bound by CA/B Forum rules. And this section is 
predicated on the assumption at all "reasonable" CAs do honor CAA 
records, otherwise a rogue CDN employee can create a certificate for the 
domain on a non-ACME CA, if they only require a proof of ownership of 
the web server.
> certificate being issued, so what is the problem?
Basic CAA, prior to Hugo's draft, only says which CA you are trusting. 
But that CA can still choose the spoofable http-01 authorization - 
spoofable if you are the CDN and so you control the web pages.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jun 2017 11:49:21 +1200

On 26 June 2017 at 02:56, Yaron Sheffer <[email-masked]> wrote:
> rolling) certificate is always available on the same URL, the "certificate
> endpoint". Since the content available at that URL changes from time to
> time, we wanted to indicate its end-of-validity with an HTTP header. If
> "Expires" is not the right header, is there a better way to do it?

I was talking about using the order.  The creation of the order and
the representation that you receive at that point will include the
time.  And that's enough.  That info can be conveyed along with the
URL for the certificate to endpoints, if they care.

> predicated on the assumption at all "reasonable" CAs do honor CAA records,
> otherwise a rogue CDN employee can create a certificate for the domain on a
> non-ACME CA, if they only require a proof of ownership of the web server.

Just say what the protocol does and avoid all that muck.  You lose
generality, currency, correctness, and it's just more work to talk
about CABF stuff.  The web isn't the only user of this stuff and I
have started to see drafts lose sight of that.

> Basic CAA, prior to Hugo's draft, only says which CA you are trusting. But
> that CA can still choose the spoofable http-01 authorization - spoofable if
> you are the CDN and so you control the web pages.

My understanding is that in this model you *need* CAA with the
extension.  As you say CAA doesn't cut it.  The text as it stands
basically implies that, but it also says a bunch of other stuff, which
obfuscates that important message.  So say exactly that: MUST use CAA
with the acme extension and that needs to be immutable so that the
untrusted thingamy can't just rewrite the policy.  That's all I was
asking for.