Re: [Acme] ACME breaking change: Most GETs become POSTs
We have already had some discussion on this. I do not want to reset the WGLC.
Please take a look at the PR, it addresses issue that were brought up during
IESG review.
If you have objections or concerns, please reply by the end of next week, 14
sep.
From: Richard Barnes
Date: Thursday, September 6, 2018 at 11:02 AM
To: "acme@ietf.org"
Cc: "" , Eric Rescorla
, Adam Roach
Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
Resent-From:
Resent-To: Rich Salz , Yoav Nir
Resent-Date: Thursday, September 6, 2018 at 11:02 AM
After the weekend's discussions, I've updated the PR to reflect what I
understand to be emerging agreement on these topics:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy
analysis?
PROPOSED RESOLUTION: Yes.
ISSUE 2: How should we signal that POST-as-GET request is different from other
POST requests?
PROPOSED RESOLUTION: A JWS with a zero-octet payload ("")
ISSUE 3: Should servers be required to allow GET requests for certificate URLs?
PROPOSED RESOLUTION: No, but they MAY
ISSUE 4: How should we address the risk that an attacker can discover URLs by
probing for Unauthorized vs. Not Found?
PROPOSED RESOLUTION: Security considerations that recommend non-correlatable
URL plans
https://github.com/ietf-wg-acme/acme/pull/445
Adam: Is this looking like an approach that would satisfy your DISCUSS?
Chairs / EKR: How would you like to proceed on closing this out? What are the
next process steps?
On Fri, Aug 31, 2018 at 6:08 PM Richard Barnes wrote:
Hey all,
This thread forked into a couple of different issues, so I wanted to post a
little end-of-day summary of the issues and where we stand. I've updated the
PR [1] to reflect most of today's discussion.
===
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy
analysis?
It seems like there's pretty strong agreement that we should get rid of GET, as
the architecturally cleanest option.
===
ISSUE 2: How should we signal that POST-as-GET request is different from other
POST requests?
The current PR signals this by sending a JWS with an empty (zero-octet)
payload, instead of a JSON object. Jacob and Daniel suggested that we should
instead use the payload being an empty JSON object as the signal. An earlier
draft PR used a field in the protected header.
===
ISSUE 3: Should servers be required to allow GET requests for certificate URLs?
I had proposed this earlier today; Jacob and Daniel pushed back. I have
implemented a compromise in the latest PR, where servers MAY accept GET
requests.
===
ISSUE 4: How should we address the risk that an attacker can discover URLs by
probing for Unauthorized vs. Not Found?
There seemed to be agreement on the list that this should be addressed with
some guidance to servers on how to assign URLs. I have just added some text to
the PR for this.
===
It seems to me we're pretty much closed on the first issue, and the other three
are still open. Please send comments, so we can resolve this issue and get the
document back in motion!
Thanks,
--Richard
[1]
https://github.com/ietf-wg-acme/acme/pull/445
On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews
mailto:j...@eff.org>> wrote:
ACME currently has unauthenticated GETs for some resources. This was
originally discussed in January 2015[1]. We decided to put all sensitive
data in the account resource and consider all GET resources public, with
a slant towards transparency.
Adam Roach recently pointed out in his Area Director review that even
when the contents of GET URLs aren’t sensitive, their correlation may
be. For instance, some CAs might consider the grouping of certificates
by account to be sensitive.
Richard Barnes proposes[2] to change all GETs to POSTs (except directory
and new-nonce). This will be a breaking change. Clients that were
compatible with previous drafts, informally called ACMEv1 and ACMEv2,
will not be compatible with a draft that mandates POSTs everywhere. It
will be a painful change, since the ecosystem just started switching to
ACMEv2, which looked to be near-final.
I think this is the right path forwards. ACME will be a simpler, better
protocol long-term if all requests are authenticated. However, if we’re
taking this path we should aim to come to consensus and land the final
spec quickly to reduce uncertainty for ACME client implementers.
[1]
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
On 04/09/2018 16:16, Gerd v. Egidy wrote: Hi Alexey, SMTP does allow choosing an arbitrary "From:" address, so just being able to send an email with a specific "From:" address alone doesn't prove anything. This is true, the document needs to add some text about some form of validation. Possibly DKIM/DMARC. fair enough. Couldn't the token just be transmitted back to the CA via HTTPS like the rest of the ACME protocol? As per above, I think this is not good enough. But wouldn't that create two different levels of validation? Let's consider user Alice. She, or her domain admin, has set up DNSSEC, DKIM, SPF and DMARC. When she does the email-reply-00 challenge, mail reception and sending is proven properly. But user Bob has none of that, just a basic domain with one A record, no DNSSEC and nothing else. When he does the email-reply-00 challenge, essentially just mail reception is proven, as sending could be forged without issue. The CA would hand out the same kind of certificates to both of them and a third party won't know which level of validation was done. Querying the dns data of Bob won't help, because he could have changed it after the certificate was issued. I think it is CA's policy whether they want to trust an email address from a domain with no DMARC/DKIM/SPF/etc. But I think the document should specify whether there are any minimum requirements on email address validation. Is a CA like Let's Encrypt ok with such a difference? Or do you want to make the use of DKIM and DMARC mandatory for a user before he can use the email-reply-00 challenge? I am leaning this way. Or at least thinking of saying something like "or comparable validation" in the document. DKIM/DMARC already deal with some of this, so I think they should be encouraged in this context. (They are easy to handle in MTAs, as more support is available). Supporting S/MIME might be a reasonable alternative as well. I'm ok with both of these mechanisms, they would both solve the issue. I just think if we allow a CA to send S/MIME, there should be something like "a client MUST support decoding MIME emails" in the RFC so that there is no surprise if a CA suddenly starts using it. I agree! Best Regards, Alexey ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
After the weekend's discussions, I've updated the PR to reflect what I
understand to be emerging agreement on these topics:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
privacy analysis?
PROPOSED RESOLUTION: Yes.
ISSUE 2: How should we signal that POST-as-GET request is different from
other POST requests?
PROPOSED RESOLUTION: A JWS with a zero-octet payload ("")
ISSUE 3: Should servers be required to allow GET requests for certificate
URLs?
PROPOSED RESOLUTION: No, but they MAY
ISSUE 4: How should we address the risk that an attacker can discover URLs
by probing for Unauthorized vs. Not Found?
PROPOSED RESOLUTION: Security considerations that recommend
non-correlatable URL plans
https://github.com/ietf-wg-acme/acme/pull/445
Adam: Is this looking like an approach that would satisfy your DISCUSS?
Chairs / EKR: How would you like to proceed on closing this out? What are
the next process steps?
On Fri, Aug 31, 2018 at 6:08 PM Richard Barnes wrote:
> Hey all,
>
> This thread forked into a couple of different issues, so I wanted to post
> a little end-of-day summary of the issues and where we stand. I've updated
> the PR [1] to reflect most of today's discussion.
>
> ===
>
> ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the
> privacy analysis?
>
> It seems like there's pretty strong agreement that we should get rid of
> GET, as the architecturally cleanest option.
>
> ===
>
> ISSUE 2: How should we signal that POST-as-GET request is different from
> other POST requests?
>
> The current PR signals this by sending a JWS with an empty (zero-octet)
> payload, instead of a JSON object. Jacob and Daniel suggested that we
> should instead use the payload being an empty JSON object as the signal.
> An earlier draft PR used a field in the protected header.
>
> ===
>
> ISSUE 3: Should servers be required to allow GET requests for certificate
> URLs?
>
> I had proposed this earlier today; Jacob and Daniel pushed back. I have
> implemented a compromise in the latest PR, where servers MAY accept GET
> requests.
>
> ===
>
> ISSUE 4: How should we address the risk that an attacker can discover URLs
> by probing for Unauthorized vs. Not Found?
>
> There seemed to be agreement on the list that this should be addressed
> with some guidance to servers on how to assign URLs. I have just added
> some text to the PR for this.
>
> ===
>
> It seems to me we're pretty much closed on the first issue, and the other
> three are still open. Please send comments, so we can resolve this issue
> and get the document back in motion!
>
> Thanks,
> --Richard
>
> [1] https://github.com/ietf-wg-acme/acme/pull/445
>
> On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews
> wrote:
>
>> ACME currently has unauthenticated GETs for some resources. This was
>> originally discussed in January 2015[1]. We decided to put all sensitive
>> data in the account resource and consider all GET resources public, with
>> a slant towards transparency.
>>
>> Adam Roach recently pointed out in his Area Director review that even
>> when the contents of GET URLs aren’t sensitive, their correlation may
>> be. For instance, some CAs might consider the grouping of certificates
>> by account to be sensitive.
>>
>> Richard Barnes proposes[2] to change all GETs to POSTs (except directory
>> and new-nonce). This will be a breaking change. Clients that were
>> compatible with previous drafts, informally called ACMEv1 and ACMEv2,
>> will not be compatible with a draft that mandates POSTs everywhere. It
>> will be a painful change, since the ecosystem just started switching to
>> ACMEv2, which looked to be near-final.
>>
>> I think this is the right path forwards. ACME will be a simpler, better
>> protocol long-term if all requests are authenticated. However, if we’re
>> taking this path we should aim to come to consensus and land the final
>> spec quickly to reduce uncertainty for ACME client implementers.
>>
>> [1]
>> https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
>> [2] https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] POST-as-GET payload contents
I agree “” is better than “{}”.
-Tim
From: Acme On Behalf Of Richard Barnes
Sent: Wednesday, September 5, 2018 4:11 PM
To: Jacob Hoffman-Andrews
Cc: Logan Widick ; IETF ACME
Subject: Re: [Acme] POST-as-GET payload contents
On Wed, Sep 5, 2018 at 3:43 PM Jacob Hoffman-Andrews mailto:j...@eff.org> > wrote:
On 09/05/2018 12:39 PM, Richard Barnes wrote:
> Using the same notation, I'm:
>
> 1) ""
> 2) "urn:ietf:params:acme:get"
> 99) "{}"
Given that, I'm willing to compromise on "". I think the experience we
had of almost implementing bugs with that approach was informative, but
isn't decisive.
Thanks for compromising. I agree that the interop stuff will cause some
hiccups, but hopeful that rather than being a blocker for folks, it will create
some pressure for JOSE libraries to interop better in this case. In any case,
I'll update the PR to make extra clear that {payload: ""} is what's required.
Anyone else have opinions before we consider this closed?
--Richard
smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
