Re: [Acme] ACME breaking change: Most GETs become POSTs
At 16:03 10/09/2018 Monday, Erica Portnoy wrote: >> I think you must have >> as all this discussion relates to traffic from acme-client to acme-server >> thus both https >> and obviously 1 known api/name >> >> you seem to be discussing traffic to an acme-customer's webserver > >Yes, because the acme client and the client's web server are often the same >exact server, and even when not, are often run on the same machine. and the location of the acme-client alters the truth of the above how? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
[as an individual] On 9/7/18 6:48 PM, Erica Portnoy wrote: If someone's in a position to watch traffic going *from* a server trying to authenticate, they can certainly watch traffic going *to* that server, and note the various domain names being hosted on that server (since no encrypted sni :( ). And they could almost certainly get that same information from a reverse DNS, as well. There's a lot of "probably" here (which I would cast as "maybe"). The prevalence of shared hosting providers makes SNI correlation significantly less problematic than information gained by trolling ACME servers under the current design. It's also worth noting that the TLS working group is working on approaches to encrypt SNI. I think you're also overestimating the utility of reverse DNS on the Internet today. Just grabbing the first thing I find in a tcpdump on my network: $ dig +short api.ambientweather.com 67.195.197.76 $ dig +short -x 67.195.197.76 p11ats-i.geo.vip.bf1.yahoo.com. You can't use precisely that method for phone numbers and contact email addresses, to be sure. And that's where the most serious damage comes into play. /a ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
> I think you must have > as all this discussion relates to traffic from acme-client to acme-server > thus both https > and obviously 1 known api/name > > you seem to be discussing traffic to an acme-customer's webserver Yes, because the acme client and the client's web server are often the same exact server, and even when not, are often run on the same machine.___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
At 00:48 08/09/2018 Saturday, Erica Portnoy wrote:
>Hello all,
>
>Just read through the discussion, hope I've misunderstood something here! Here
>goes:
I think you must have
as all this discussion relates to traffic from acme-client to acme-server
thus both https
and obviously 1 known api/name
you seem to be discussing traffic to an acme-customer's webserver
>Domains that could be correlated in this way can probably already be
>correlated.
>
>If someone's in a position to watch traffic going *from* a server trying to
>authenticate, they can certainly watch traffic going *to* that server, and
>note the various domain names being hosted on that server (since no encrypted
>sni :( ). And they could almost certainly get that same information from a
>reverse DNS, as well.
>
>You can't use precisely that method for phone numbers and contact email
>addresses, to be sure.
>
>But we might be overestimating the amount of privacy protection we're giving
>here; we don't want to be in a position of trying to protect something that's
>public information.
>
>Best,
>Erica
>
>
>On 09/06/2018 09:03 AM, Eric Rescorla wrote:
>>This is a pretty substantive change and I think this does need to have a
>>short IETF-LC. Why don't you produce a new draft and let me know when you
>>believe the WG has consensus
>>-Ekr
>>
>>
>>On Thu, Sep 6, 2018 at 8:50 AM, Salz, Rich
>><<mailto:rsalz=40akamai@dmarc.ietf.org>rsalz=40akamai@dmarc.ietf.org>
>>wrote:
>>
>>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 <mailto:r...@ipv.sx>
>>Date: Thursday, September 6, 2018 at 11:02 AM
>>To: "<mailto:acme@ietf.org>acme@ietf.org"
>><<mailto:acme@ietf.org>acme@ietf.org>
>>Cc: "<mailto:acme-cha...@ietf.org>"
>><<mailto:acme-cha...@ietf.org>acme-cha...@ietf.org>, Eric Rescorla
>><<mailto:e...@rtfm.com>e...@rtfm.com>, Adam Roach
>><<mailto:a...@nostrum.com>a...@nostrum.com>
>>Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
>>Resent-From: <<mailto:alias-boun...@ietf.org>alias-boun...@ietf.org>
>>Resent-To: Rich Salz <<mailto:rs...@akamai.com>rs...@akamai.com>, Yoav Nir
>><<mailto:ynir.i...@gmail.com>ynir.i...@gmail.com>
>>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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0=>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
>><mailto:r...@ipv.sx> 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.
>>
>>Â
>>
>>===
>>
>>Â
>>
Re: [Acme] ACME breaking change: Most GETs become POSTs
Hello all,
Just read through the discussion, hope I've misunderstood something
here! Here goes:
Domains that could be correlated in this way can probably already be
correlated.
If someone's in a position to watch traffic going *from* a server trying
to authenticate, they can certainly watch traffic going *to* that
server, and note the various domain names being hosted on that server
(since no encrypted sni :( ). And they could almost certainly get that
same information from a reverse DNS, as well.
You can't use precisely that method for phone numbers and contact email
addresses, to be sure.
But we might be overestimating the amount of privacy protection we're
giving here; we don't want to be in a position of trying to protect
something that's public information.
Best,
Erica
On 09/06/2018 09:03 AM, Eric Rescorla wrote:
> This is a pretty substantive change and I think this does need to have
> a short IETF-LC. Why don't you produce a new draft and let me know
> when you believe the WG has consensus
> -Ekr
>
>
> On Thu, Sep 6, 2018 at 8:50 AM, Salz, Rich
> <mailto:rsalz=40akamai@dmarc.ietf.org>> wrote:
>
> 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 <mailto:acme@ietf.org>" <mailto:acme@ietf.org>>
> *Cc: *"" <mailto:acme-cha...@ietf.org>>, Eric Rescorla <mailto:e...@rtfm.com>>, Adam Roach <mailto:a...@nostrum.com>>
> *Subject: *Re: [Acme] ACME breaking change: Most GETs become POSTs
> *Resent-From: * <mailto:alias-boun...@ietf.org>>
> *Resent-To: *Rich Salz <mailto:rs...@akamai.com>>, Yoav Nir <mailto:ynir.i...@gmail.com>>
> *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
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0=>
>
>
>
> 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 us
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0=>
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0=>
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]
https://github.com/letsencrypt/acme-spec/pull/48#issueco
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] ACME breaking change: Most GETs become POSTs
On 08/31/2018 03:08 PM, Richard Barnes wrote: ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy analysis? Agreed we're solved on this. ISSUE 2: How should we signal that POST-as-GET request is different from other POST requests? Started a separate thread on this. ISSUE 3: Should servers be required to allow GET requests for certificate URLs? I'm not convinced this is absolutely necessary for the STAR use case, and I'm still not thrilled about carving out exceptions, but I'm okay leaving this as a MAY GET in the interests of landing the change. 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. This seems like a good plan to me. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
Hi Richard,
I think we're in a good place, even from a STAR perspective (where
certificates must be accessible with a GET, or the whole thing breaks
down). To clarify the behavior further, I suggest to add the following
text after the paragraph that says that "The server MAY allow GET
requests for certificate resources...":
The server MAY choose to allow GET requests to certain certificate
resources but not to others. The server can base this decision on
out-of-band knowledge (e.g., to allow GET requests to certificates owned
by a certain account) or on order-specific information, such as the
extension defined in {{?I-D.ietf-acme-star}}.
Thanks,
Yaron
On 01/09/18 01:08, 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] ACME breaking change: Most GETs become POSTs
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] ACME breaking change: Most GETs become POSTs
Hi Richard, > I was able upgrade the lego client in a pretty short patch (5 files > changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates > with Daniel's branch of pebble. you were faster :) I've adjusted Ansible's acme_certificate module to also work with Daniel's branch in https://github.com/ansible/ansible/pull/44988 Most of the changes are general refactoring to make use of a single URL fetch method which has access to the ACME account data; the main part related to POST-as-GET is only a few lines. Cheers, Felix > > --Richard > > [1] https://github.com/bifurcation/lego/pull/1 > > > > On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney > wrote: > > > I think its an anti-pattern to standardize protocol features that > > haven't been implemented by anyone so here's a PR[0] for the Pebble > > ACME server that implements Richard's proposal[1] to establish > > viability. The proposal seems OK to me given the > > trade-offs/alternatives on the table. > > > > I would encourage other ACME client/server developers to try their > > hand at implementing the changes from [1] as well. I've tested my > > PR with hand-rolled requests but not as part of an automated > > issuance process with a "real" ACME client. Speak now or forever > > hold your bugs. > > > > [0] - https://github.com/letsencrypt/pebble/pull/162 > > [1] - https://github.com/ietf-wg-acme/acme/pull/445/files > > > > On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote: > > > >> No, if a server receives a GET request for a resource other than > >> those specified, then it MUST return 405. But please check out > >> the PR and see if it's clear there. > >> > >> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich > >> wrote: > >>> > >>>- * Servers MUST return a 405 if they get a GET for a resource > >>> other than directory/newNonce/certificate. > >>> > >>> > >>> > >>> They means client? Or there’s a word missing, and “they get a” is > >>> “they do not support” ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 3:30 PM Jacob Hoffman-Andrews wrote: > On 08/31/2018 07:25 AM, Richard Barnes wrote: > > The problem with using POST-as-GET for certificate resources, as > > Felipe I think pointed out, is that the thing that downloads the > > certificate URL is often not an ACME player, doesn't have an account, > > etc. It's a web server or something. (cf. the STAR drafts.) What I'm > > saying is that it's painful to make them integrate with ACME and we > > don't get any benefit. > AFAIK, no current ACME client hands off certificate URLs to > less-privileged processes. > > Keeping GETs for certificates undermines the goal of making the > POST-as-GET change. Certificate resources may be constructed in > enumerable ways, like: > > /account/100/certificate/3438 > /account/201/certificate/3439 > /account/100/certificate/3440* > > While many CAs may not consider correlation of certificates by account > to be sensitive, our goal with this change is to eliminate a footgun for > CAs who do consider it sensitive, by simply ensuring all requests are > authenticated by default. Consistent authentication also has the > potential to simplify by client and server libraries. > > I think it would be a mistake to carve out this exception in the main > ACME spec for use cases that are still speculative. Instead, if there is > a use case that truly requires unauthenticated certificate retrieval, it > should be defined as an extension or an optional feature. > I understand the desire for uniformity; I'm just concerned we're going overboard here. I could live with this being optional, but I would prefer to go ahead and add it (because STAR needs it) and keep the negotiation minimal. I would propose that we just say the server MAY accept GETs for certificate URLs, returning 405 if not. That way a client with a GET-based use case would have to either find out out of band that the server was compatible, or else fail when it tries. But that seems like an acceptable outcome to me. If we need an "I always do cert+GET" signal, we can toss it in the "meta" dictionary later. --Richard > > In short, I think certificates should be POST-as-GET just like the other > resources. > > *Note: I'm aware that certificate serial numbers must be randomized, but > there is no requirement that the certificate serial number be present in > the URL. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 3:30 PM Daniel McCarney wrote:
> here's a PR[0] for the Pebble ACME server that implements Richard's
>> proposal[1] to establish viability. The proposal seems OK to me given
>> the trade-offs/alternatives on the table.
>
>
> One of the changes Richard made in his second iteration of PR #445 was to
> differentiate a POST from a POST-as-GET by sending an empty body "a
> zero-length octet string" in the POST JWS. Talking about the experience of
> implementing this more with Jacob Hoffman-Andrews I think I've come around
> to preferring an alternative design. #445 as described requires server and
> client developers pay careful attention to the differences between `null`
> and `""` in serialization/deserialization and might be bumping into
> differences between languages/JSON parsers. Both myself and Jacob failed to
> get it right on a first-go[0] and if people this close to the specification
> are going to trip on this I think we can be assured others will too.
>
> A proposed alternative: We use `{}` as the body for POST-as-GET (as
> suggested by Jacob[1]) and further specify that challenges can only be
> initiated with a POST and do not support POST-as-GET.
>
> Using `{}` as the body matches the long standing method of authenticating
> access to account information and avoids any null troubles. Removing
> polling of challenges is required to free up POSTing `{}` as the challenge
> initiation message. All of the challenge information is already accessible
> by POST-as-GET polling the associated authorization and it seems sensible
> to remove that redundancy as it can cause bugs when a client developer
> polls a challenge for an authorization not realizing the associated
> authorization has changed to status valid from a different challenge.
>
> Thoughts?
>
The confusion over `null` and `""` is actually part of the motivation for
using a zero-length body -- it's not JSON. That's what makes it a good
signal. If you're doing POST-as-POST, you have a JSON body and you have to
do JSON stuff. If you're doing POST-as-GET, you're not and you don't. It
guarantees clean separation between the two cases, minimizing risk of
confusion.
I think the cleaner answer here is to fix the "account fetch" case to use
POST-as-GET.
--Richard
>
> [0] https://github.com/letsencrypt/pebble/pull/162#discussion_r214446189
> [1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743
>
> On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney
> wrote:
>
>> I think its an anti-pattern to standardize protocol features that haven't
>> been implemented by anyone so here's a PR[0] for the Pebble ACME server
>> that implements Richard's proposal[1] to establish viability. The proposal
>> seems
>> OK to me given the trade-offs/alternatives on the table.
>>
>> I would encourage other ACME client/server developers to try their hand
>> at implementing the changes from [1] as well. I've tested my PR with
>> hand-rolled requests but not as part of an automated issuance process with
>> a "real" ACME client. Speak now or forever hold your bugs.
>>
>> [0] - https://github.com/letsencrypt/pebble/pull/162
>> [1] - https://github.com/ietf-wg-acme/acme/pull/445/files
>>
>> On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote:
>>
>>> No, if a server receives a GET request for a resource other than those
>>> specified, then it MUST return 405. But please check out the PR and see if
>>> it's clear there.
>>>
>>> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote:
>>>
- * Servers MUST return a 405 if they get a GET for a resource
other than directory/newNonce/certificate.
They means client? Or there’s a word missing, and “they get a” is “they
do not support”
>>>
>>> ___
>>> 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] ACME breaking change: Most GETs become POSTs
I was able upgrade the lego client in a pretty short patch (5 files changed, 26 insertions(+), 16 deletions(-)) [0]. It interoperates with Daniel's branch of pebble. --Richard [1] https://github.com/bifurcation/lego/pull/1 On Fri, Aug 31, 2018 at 2:56 PM Daniel McCarney wrote: > I think its an anti-pattern to standardize protocol features that haven't > been implemented by anyone so here's a PR[0] for the Pebble ACME server > that implements Richard's proposal[1] to establish viability. The proposal > seems > OK to me given the trade-offs/alternatives on the table. > > I would encourage other ACME client/server developers to try their hand at > implementing the changes from [1] as well. I've tested my PR with > hand-rolled requests but not as part of an automated issuance process with > a "real" ACME client. Speak now or forever hold your bugs. > > [0] - https://github.com/letsencrypt/pebble/pull/162 > [1] - https://github.com/ietf-wg-acme/acme/pull/445/files > > On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote: > >> No, if a server receives a GET request for a resource other than those >> specified, then it MUST return 405. But please check out the PR and see if >> it's clear there. >> >> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote: >> >>> >>>- * Servers MUST return a 405 if they get a GET for a resource other >>>than directory/newNonce/certificate. >>> >>> >>> >>> They means client? Or there’s a word missing, and “they get a” is “they >>> do not support” >>> >> >> ___ >> 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] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 01:57:06PM -0700, Eric Rescorla wrote: > On Fri, Aug 31, 2018 at 12:43 PM, Nico Williams > wrote: > > > On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote: > > > > How does using POST address this? > > > > > > Please read the draft. We're talking about POSTs authenticated with JWS > > not > > > vanilla HTTP POSTs. > > > > That really should have been an HTTP authentication method :( > > > > Not really, no. First, HTTP is just being used as a transport here. Second, > authentication is by digital signature, and that's not really > well-supported in HTTP. Third, it's way too late now to be having this > discussion. Fair enough. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On 8/31/18 3:58 PM, Jacob Hoffman-Andrews wrote: On 08/31/2018 01:51 PM, Adam Roach wrote: The baseline problem here is that the original analysis that determined that orders, authorizations, challenges, and certificates were "not sensitive" was incorrect. These are all potentially sensitive from a privacy perspective. Perhaps not in isolation, but the problem here is correlation, not isolation. What do you think about the question of preventing correlation of the existence of URLs? Do you think that's in-scope, or should we only prevent correlation of the contents? The latter. Here's another example of a URL scheme where revealing existence would reveal some correlation data: /account/100/certificate/example.com /account/201/certificate/example.net /account/100/certificate/secret.example.com Personally, I think it will be intractable to hide the existence/non-existence of URLs, and we should just mention it as a risk in the security considerations section. That leads me to the conclusion that it's fine to return Unauthorized for resources that exist, by the client does not own. I think that's correct. /a ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews wrote: > On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote: > > /account/100/certificate/3438 > > /account/201/certificate/3439 > > /account/100/certificate/3440* > > Here's an issue that came up during code review: When you POST-as-GET to > a resource you don't own, should you get Not Found or Unauthorized? The > quick answer is Not Found. If we return Unauthorized, that still allows > potentially enumerating the existence of certificates URLs, which > depending on URL schemes might reveal the grouping of certificates by > account id. > > However, if we choose Not Found, that implies we're trying to hide the > existence of certain resources, which means checking for those resources > has to be timing-safe, a very high bar. We wind up hiding one foot-gun > (URL enumeration) under another foot-gun (timing attacks). > > Alternately, we could consider URL enumeration out of scope, and say > "POST-as-GET is only intended to protect the contents of resources, not > their existence or relationship to each other." > > That winds up leaving us pretty close to being back at draft-14: Since > POST-as-GET protects resource bodies, and the currently-specified > resources are already broken down into sensitive (account) and not > (orders, authorizations, challenges, certificates), we could just as > well leave the non-sensitive resources as regular GETs. We might make a > change to define POST-as-GET as a broader mechanism, to be used by > default by future extensions that define new resource types. > > Alternately, we might say that even though orders, authorizations, > challenges, and certificates are all non-sensitive, we should require > POST-as-GET across the board for all ACME requests, because it will > simplify security analysis. > > What do you all think? Should enumeration of the existence of URLs be > considered in-scope? > The correct answer here is Unauthorized. The resource exists, and it's the job of the authentication / authorization system to prevent unauthorized parties from accessing it. I disagree with your assessment that this puts us back at draft-14. It just moves us to the edge of the demarc: The guidance from the HTTP folks says we're not allowed to specify URL plans for server operators, in order to give them deployment flexibility. The flip-side of that is that it is up to operators to use a safe URL plan. So we're doing our part in the protocol; operators need to do their part. I can add some guidance to the security considerations. --Richard On Fri, Aug 31, 2018 at 4:15 PM Jacob Hoffman-Andrews wrote: > On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote: > > /account/100/certificate/3438 > > /account/201/certificate/3439 > > /account/100/certificate/3440* > > Here's an issue that came up during code review: When you POST-as-GET to > a resource you don't own, should you get Not Found or Unauthorized? The > quick answer is Not Found. If we return Unauthorized, that still allows > potentially enumerating the existence of certificates URLs, which > depending on URL schemes might reveal the grouping of certificates by > account id. > > However, if we choose Not Found, that implies we're trying to hide the > existence of certain resources, which means checking for those resources > has to be timing-safe, a very high bar. We wind up hiding one foot-gun > (URL enumeration) under another foot-gun (timing attacks). > > Alternately, we could consider URL enumeration out of scope, and say > "POST-as-GET is only intended to protect the contents of resources, not > their existence or relationship to each other." > > That winds up leaving us pretty close to being back at draft-14: Since > POST-as-GET protects resource bodies, and the currently-specified > resources are already broken down into sensitive (account) and not > (orders, authorizations, challenges, certificates), we could just as > well leave the non-sensitive resources as regular GETs. We might make a > change to define POST-as-GET as a broader mechanism, to be used by > default by future extensions that define new resource types. > > Alternately, we might say that even though orders, authorizations, > challenges, and certificates are all non-sensitive, we should require > POST-as-GET across the board for all ACME requests, because it will > simplify security analysis. > > What do you all think? Should enumeration of the existence of URLs be > considered in-scope? > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 12:43 PM, Nico Williams wrote: > On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote: > > > How does using POST address this? > > > > Please read the draft. We're talking about POSTs authenticated with JWS > not > > vanilla HTTP POSTs. > > That really should have been an HTTP authentication method :( > Not really, no. First, HTTP is just being used as a transport here. Second, authentication is by digital signature, and that's not really well-supported in HTTP. Third, it's way too late now to be having this discussion. -Ekr > ___ > 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] ACME breaking change: Most GETs become POSTs
On 8/31/18 3:14 PM, Jacob Hoffman-Andrews wrote: That winds up leaving us pretty close to being back at draft-14: Since POST-as-GET protects resource bodies, and the currently-specified resources are already broken down into sensitive (account) and not (orders, authorizations, challenges, certificates), we could just as well leave the non-sensitive resources as regular GETs. No. The baseline problem here is that the original analysis that determined that orders, authorizations, challenges, and certificates were "not sensitive" was incorrect. These are all potentially sensitive from a privacy perspective. Perhaps not in isolation, but the problem here is correlation, not isolation. /a ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote: /account/100/certificate/3438 /account/201/certificate/3439 /account/100/certificate/3440* Here's an issue that came up during code review: When you POST-as-GET to a resource you don't own, should you get Not Found or Unauthorized? The quick answer is Not Found. If we return Unauthorized, that still allows potentially enumerating the existence of certificates URLs, which depending on URL schemes might reveal the grouping of certificates by account id. However, if we choose Not Found, that implies we're trying to hide the existence of certain resources, which means checking for those resources has to be timing-safe, a very high bar. We wind up hiding one foot-gun (URL enumeration) under another foot-gun (timing attacks). Alternately, we could consider URL enumeration out of scope, and say "POST-as-GET is only intended to protect the contents of resources, not their existence or relationship to each other." That winds up leaving us pretty close to being back at draft-14: Since POST-as-GET protects resource bodies, and the currently-specified resources are already broken down into sensitive (account) and not (orders, authorizations, challenges, certificates), we could just as well leave the non-sensitive resources as regular GETs. We might make a change to define POST-as-GET as a broader mechanism, to be used by default by future extensions that define new resource types. Alternately, we might say that even though orders, authorizations, challenges, and certificates are all non-sensitive, we should require POST-as-GET across the board for all ACME requests, because it will simplify security analysis. What do you all think? Should enumeration of the existence of URLs be considered in-scope? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On Fri, Aug 31, 2018 at 03:37:01PM -0400, Daniel McCarney wrote: > > How does using POST address this? > > Please read the draft. We're talking about POSTs authenticated with JWS not > vanilla HTTP POSTs. That really should have been an HTTP authentication method :( ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
> How does using POST address this? Please read the draft. We're talking about POSTs authenticated with JWS not vanilla HTTP POSTs. On Fri, Aug 31, 2018 at 3:34 PM, Nico Williams wrote: > On Thu, Aug 30, 2018 at 04:20:41PM -0700, 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. > > This is true, but GET isn't the issue. If you have iterable URI > constructions then POST will let you iterate them just as well as GET. > > > 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. > > How does using POST address this? > > Neither does GET imply unauthenticated, nor does POST imply > authenticated. > > GET vs POST can make a difference in the context of HTML (where you can > get a user-agent to GET a resource without the user taking action), but > I don't think that's relevant here. > > > 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. > > This is wrong. GET vs POST makes no difference as to iteration of > resources. > > Please use HTTP correctly. > > If a resource is read-only or GETs of it would be idempotent anyways, > then use GET. > > Do include normative text about the shape of the URIs to prevent > iteration via monotonic increment of numeric components or query > parameters. > > Do specify what requires authentication and what does not. > > Do not misuse HTTP verbs. > > Nico > -- > > ___ > 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] ACME breaking change: Most GETs become POSTs
On Thu, Aug 30, 2018 at 04:20:41PM -0700, 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. This is true, but GET isn't the issue. If you have iterable URI constructions then POST will let you iterate them just as well as GET. > 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. How does using POST address this? Neither does GET imply unauthenticated, nor does POST imply authenticated. GET vs POST can make a difference in the context of HTML (where you can get a user-agent to GET a resource without the user taking action), but I don't think that's relevant here. > 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. This is wrong. GET vs POST makes no difference as to iteration of resources. Please use HTTP correctly. If a resource is read-only or GETs of it would be idempotent anyways, then use GET. Do include normative text about the shape of the URIs to prevent iteration via monotonic increment of numeric components or query parameters. Do specify what requires authentication and what does not. Do not misuse HTTP verbs. Nico -- ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
> > In short, I think certificates should be POST-as-GET just like the other > resources. +1. If we're replacing the GETs to Orders, Authorizations and Challenges there's no sense in excluding Certificates. I prefer the uniformity over exceptions for use-cases that don't have strong real-world use/implementations. On Fri, Aug 31, 2018 at 3:30 PM, Jacob Hoffman-Andrews wrote: > On 08/31/2018 07:25 AM, Richard Barnes wrote: > >> The problem with using POST-as-GET for certificate resources, as Felipe I >> think pointed out, is that the thing that downloads the certificate URL is >> often not an ACME player, doesn't have an account, etc. It's a web server >> or something. (cf. the STAR drafts.) What I'm saying is that it's painful >> to make them integrate with ACME and we don't get any benefit. >> > AFAIK, no current ACME client hands off certificate URLs to > less-privileged processes. > > Keeping GETs for certificates undermines the goal of making the > POST-as-GET change. Certificate resources may be constructed in enumerable > ways, like: > > /account/100/certificate/3438 > /account/201/certificate/3439 > /account/100/certificate/3440* > > While many CAs may not consider correlation of certificates by account to > be sensitive, our goal with this change is to eliminate a footgun for CAs > who do consider it sensitive, by simply ensuring all requests are > authenticated by default. Consistent authentication also has the potential > to simplify by client and server libraries. > > I think it would be a mistake to carve out this exception in the main ACME > spec for use cases that are still speculative. Instead, if there is a use > case that truly requires unauthenticated certificate retrieval, it should > be defined as an extension or an optional feature. > > In short, I think certificates should be POST-as-GET just like the other > resources. > > *Note: I'm aware that certificate serial numbers must be randomized, but > there is no requirement that the certificate serial number be present in > the URL. > > > ___ > 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] ACME breaking change: Most GETs become POSTs
>
> here's a PR[0] for the Pebble ACME server that implements Richard's
> proposal[1] to establish viability. The proposal seems OK to me given the
> trade-offs/alternatives on the table.
One of the changes Richard made in his second iteration of PR #445 was to
differentiate a POST from a POST-as-GET by sending an empty body "a
zero-length octet string" in the POST JWS. Talking about the experience of
implementing this more with Jacob Hoffman-Andrews I think I've come around
to preferring an alternative design. #445 as described requires server and
client developers pay careful attention to the differences between `null`
and `""` in serialization/deserialization and might be bumping into
differences between languages/JSON parsers. Both myself and Jacob failed to
get it right on a first-go[0] and if people this close to the specification
are going to trip on this I think we can be assured others will too.
A proposed alternative: We use `{}` as the body for POST-as-GET (as
suggested by Jacob[1]) and further specify that challenges can only be
initiated with a POST and do not support POST-as-GET.
Using `{}` as the body matches the long standing method of authenticating
access to account information and avoids any null troubles. Removing
polling of challenges is required to free up POSTing `{}` as the challenge
initiation message. All of the challenge information is already accessible
by POST-as-GET polling the associated authorization and it seems sensible
to remove that redundancy as it can cause bugs when a client developer
polls a challenge for an authorization not realizing the associated
authorization has changed to status valid from a different challenge.
Thoughts?
[0] https://github.com/letsencrypt/pebble/pull/162#discussion_r214446189
[1] https://github.com/ietf-wg-acme/acme/pull/445#issuecomment-417505743
On Fri, Aug 31, 2018 at 2:56 PM, Daniel McCarney
wrote:
> I think its an anti-pattern to standardize protocol features that haven't
> been implemented by anyone so here's a PR[0] for the Pebble ACME server
> that implements Richard's proposal[1] to establish viability. The proposal
> seems
> OK to me given the trade-offs/alternatives on the table.
>
> I would encourage other ACME client/server developers to try their hand at
> implementing the changes from [1] as well. I've tested my PR with
> hand-rolled requests but not as part of an automated issuance process with
> a "real" ACME client. Speak now or forever hold your bugs.
>
> [0] - https://github.com/letsencrypt/pebble/pull/162
> [1] - https://github.com/ietf-wg-acme/acme/pull/445/files
>
> On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote:
>
>> No, if a server receives a GET request for a resource other than those
>> specified, then it MUST return 405. But please check out the PR and see if
>> it's clear there.
>>
>> On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote:
>>
>>>
>>>- * Servers MUST return a 405 if they get a GET for a resource other
>>>than directory/newNonce/certificate.
>>>
>>>
>>>
>>> They means client? Or there’s a word missing, and “they get a” is “they
>>> do not support”
>>>
>>
>> ___
>> 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] ACME breaking change: Most GETs become POSTs
On 08/31/2018 07:25 AM, Richard Barnes wrote: The problem with using POST-as-GET for certificate resources, as Felipe I think pointed out, is that the thing that downloads the certificate URL is often not an ACME player, doesn't have an account, etc. It's a web server or something. (cf. the STAR drafts.) What I'm saying is that it's painful to make them integrate with ACME and we don't get any benefit. AFAIK, no current ACME client hands off certificate URLs to less-privileged processes. Keeping GETs for certificates undermines the goal of making the POST-as-GET change. Certificate resources may be constructed in enumerable ways, like: /account/100/certificate/3438 /account/201/certificate/3439 /account/100/certificate/3440* While many CAs may not consider correlation of certificates by account to be sensitive, our goal with this change is to eliminate a footgun for CAs who do consider it sensitive, by simply ensuring all requests are authenticated by default. Consistent authentication also has the potential to simplify by client and server libraries. I think it would be a mistake to carve out this exception in the main ACME spec for use cases that are still speculative. Instead, if there is a use case that truly requires unauthenticated certificate retrieval, it should be defined as an extension or an optional feature. In short, I think certificates should be POST-as-GET just like the other resources. *Note: I'm aware that certificate serial numbers must be randomized, but there is no requirement that the certificate serial number be present in the URL. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
I think its an anti-pattern to standardize protocol features that haven't been implemented by anyone so here's a PR[0] for the Pebble ACME server that implements Richard's proposal[1] to establish viability. The proposal seems OK to me given the trade-offs/alternatives on the table. I would encourage other ACME client/server developers to try their hand at implementing the changes from [1] as well. I've tested my PR with hand-rolled requests but not as part of an automated issuance process with a "real" ACME client. Speak now or forever hold your bugs. [0] - https://github.com/letsencrypt/pebble/pull/162 [1] - https://github.com/ietf-wg-acme/acme/pull/445/files On Fri, Aug 31, 2018 at 1:21 PM, Richard Barnes wrote: > No, if a server receives a GET request for a resource other than those > specified, then it MUST return 405. But please check out the PR and see if > it's clear there. > > On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote: > >> >>- * Servers MUST return a 405 if they get a GET for a resource other >>than directory/newNonce/certificate. >> >> >> >> They means client? Or there’s a word missing, and “they get a” is “they >> do not support” >> > > ___ > 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] ACME breaking change: Most GETs become POSTs
No, if a server receives a GET request for a resource other than those specified, then it MUST return 405. But please check out the PR and see if it's clear there. On Fri, Aug 31, 2018 at 1:14 PM Salz, Rich wrote: > >- * Servers MUST return a 405 if they get a GET for a resource other >than directory/newNonce/certificate. > > > > They means client? Or there’s a word missing, and “they get a” is “they do > not support” > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
* * Servers MUST return a 405 if they get a GET for a resource other than directory/newNonce/certificate. They means client? Or there’s a word missing, and “they get a” is “they do not support” ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
I have updated the pull request here with a couple of major changes: * Instead of using the "typ" header parameter to signal POST-as-GET, the client signals a POST-as-GET request by sending an empty JWS payload. It seems like all of the actual-POST requests we have send a JSON object, so this should be a reliable distinguisher. * GET requests are now allowed for certificate resources, with a recommendation for CAs to use capability URLs if they want access control. * Servers MUST return a 405 if they get a GET for a resource other than directory/newNonce/certificate. The last change makes this a harder break for current clients/servers. But it's only breaking in the sense that they're not in compliance with the RFC; you can operate a non-RFC-compliant service, no protocol police. And I think it results in a cleaner, more reliable definition here. --Richard 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] ACME breaking change: Most GETs become POSTs
The capability URL stuff introduces a level of complexity that I'd rather not try to analyze at this point. I'm afraid people will rush to implement it and get it wrong in hard to anticipate ways, or that there are consequences we haven't foreseen at this late hour. POSTs seem to be the right long term solution. Why is it necessary that the server MUST allow GETs, and cannot consider them to be a legacy feature that should eventually be deprecated? -Tim > -Original Message- > From: Acme On Behalf Of Nico Williams > Sent: Friday, August 31, 2018 5:16 PM > To: Felipe Gasper > Cc: ACME WG > Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs > > On Thu, Aug 30, 2018 at 08:45:50PM -0400, Felipe Gasper wrote: > > I suppose if I have: > > > > GET /order/123/certificate=> cert for yin.com > > > > GET /order/124/certificate=> cert for yang.com > > > > … then one could surmise (however justifiably) that these two may be > related, so I see the point. > > If these numbers are certificate serial numbers, then by all means they must > be > randomized. Even if not, predictable, serial account-number- like numbers > should not be part of a URL without some other component to make URL > generation unpredictable. > > > > You could make the certificate URLs unpredictable, but then you've > > > introduced a notion of capability URLs[1], which breaks the notion > > > of having a single authentication system for ACME. > > > > I can see that. > > Eh? Just because they are randomized / unpredictable does not mean that > they are capability URLs or confidentiality-sensitive, nor that they must be > one- > time-use only. > > Nico > -- > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme smime.p7s Description: S/MIME cryptographic signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
The problem with using POST-as-GET for certificate resources, as Felipe I think pointed out, is that the thing that downloads the certificate URL is often not an ACME player, doesn't have an account, etc. It's a web server or something. (cf. the STAR drafts.) What I'm saying is that it's painful to make them integrate with ACME and we don't get any benefit. On Fri, Aug 31, 2018 at 10:20 AM Salz, Rich wrote: > >- - If a server is concerned about the privacy of certificate >resources, then they SHOULD assign them capability URLs. > > > > Not a fan of capability URL’s; does get/post handle things well enough? > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
To be clear, I'm proposing that the server MUST allow GET for a certificate resource (as well as POST-as-GET). It can protect those GETs with capability URLs if it wants to. On Fri, Aug 31, 2018 at 10:21 AM Felipe Gasper wrote: > I wonder, then, if it’s worth making it discoverable whether the server > allows a plain GET for a certificate … other than, of course, getting a 405 > back when the client tries to request a certificate via GET. > > -F > > > On Aug 31, 2018, at 10:16 AM, Richard Barnes wrote: > > > > TBH, I'm not averse to allowing GETs for certificate resources. It > seems analogous to allowing them for the directory resource, just on the > opposite side of the process. That is, the directory and certificate > resources are the interfaces between ACME and the outside world, so it > makes sense not to force the outside world into the ACME authentication > model. In the same vein, capability URLs could be sensible here as an > optional protection, since they're an authn model that's easy for the > outside world to use. > > > > In addition, the content of certificate resources is tightly > constrained, so we don't have the problem that we have with the JSON > resources, that a server might add some information that violates privacy > expectations. > > > > So I would propose that we say: > > > > - GETs are allowed for directory, newNonce, and certificate resources > > - Servers MUST still respond to POST-as-GET requests for certificates, > to simplify client logic > > - If a server is concerned about the privacy of certificate resources, > then they SHOULD assign them capability URLs. > > > > I'll be updating the PR to reflect some comments in Github a little > later today, and will incorporate the above unless people think it's awful. > > > > --Richard > > > > On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper > wrote: > > > > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews > wrote: > > > > > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > > > > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > > > Would it work to keep certificate fetches as plain GET? > > > > > > > > In shared hosting environments it’s common for a privileged process > to request certificates on behalf of user accounts. This avoids having > 1,000s of ACME server registrations from a single server. While > certificates are generally made available within seconds, theoretically the > delay between request and issuance could be much longer (e.g., for OV/EV), > such that it might be prudent for that privileged process to give the order > ID to the user and have the user poll for the certificate, e.g., via cron.. > > > > > > This use case makes sense, but I think it is not critical enough to > carve out an exception from the "GETs become POSTs" plan. If the ACME > implementation structures certificate fetches such that they are > enumerable, you would wind up again with the same sort of correlation > problem Adam brought up. You could make the certificate URLs unpredictable, > but then you've introduced a notion of capability URLs[1], which breaks the > notion of having a single authentication system for ACME. > > > > I suppose if I have: > > > > GET /order/123/certificate=> cert for yin.com > > > > GET /order/124/certificate=> cert for yang.com > > > > … then one could surmise (however justifiably) that these two may be > related, so I see the point. > > > > > You could make the certificate URLs unpredictable, but then you've > introduced a notion of capability URLs[1], which breaks the notion of > having a single authentication system for ACME. > > > > I can see that. > > > > > > Thanks for your consideration! > > > > -FG > > ___ > > 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] ACME breaking change: Most GETs become POSTs
I wonder, then, if it’s worth making it discoverable whether the server allows a plain GET for a certificate … other than, of course, getting a 405 back when the client tries to request a certificate via GET. -F > On Aug 31, 2018, at 10:16 AM, Richard Barnes wrote: > > TBH, I'm not averse to allowing GETs for certificate resources. It seems > analogous to allowing them for the directory resource, just on the opposite > side of the process. That is, the directory and certificate resources are > the interfaces between ACME and the outside world, so it makes sense not to > force the outside world into the ACME authentication model. In the same > vein, capability URLs could be sensible here as an optional protection, since > they're an authn model that's easy for the outside world to use. > > In addition, the content of certificate resources is tightly constrained, so > we don't have the problem that we have with the JSON resources, that a server > might add some information that violates privacy expectations. > > So I would propose that we say: > > - GETs are allowed for directory, newNonce, and certificate resources > - Servers MUST still respond to POST-as-GET requests for certificates, to > simplify client logic > - If a server is concerned about the privacy of certificate resources, then > they SHOULD assign them capability URLs. > > I'll be updating the PR to reflect some comments in Github a little later > today, and will incorporate the above unless people think it's awful. > > --Richard > > On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper wrote: > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > > Would it work to keep certificate fetches as plain GET? > > > > > > In shared hosting environments it’s common for a privileged process to > > > request certificates on behalf of user accounts. This avoids having > > > 1,000s of ACME server registrations from a single server. While > > > certificates are generally made available within seconds, theoretically > > > the delay between request and issuance could be much longer (e.g., for > > > OV/EV), such that it might be prudent for that privileged process to give > > > the order ID to the user and have the user poll for the certificate, > > > e.g., via cron. > > > > This use case makes sense, but I think it is not critical enough to carve > > out an exception from the "GETs become POSTs" plan. If the ACME > > implementation structures certificate fetches such that they are > > enumerable, you would wind up again with the same sort of correlation > > problem Adam brought up. You could make the certificate URLs unpredictable, > > but then you've introduced a notion of capability URLs[1], which breaks the > > notion of having a single authentication system for ACME. > > I suppose if I have: > > GET /order/123/certificate=> cert for yin.com > > GET /order/124/certificate=> cert for yang.com > > … then one could surmise (however justifiably) that these two may be related, > so I see the point. > > > You could make the certificate URLs unpredictable, but then you've > > introduced a notion of capability URLs[1], which breaks the notion of > > having a single authentication system for ACME. > > I can see that. > > > Thanks for your consideration! > > -FG > ___ > 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] ACME breaking change: Most GETs become POSTs
* - If a server is concerned about the privacy of certificate resources, then they SHOULD assign them capability URLs. Not a fan of capability URL’s; does get/post handle things well enough? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
TBH, I'm not averse to allowing GETs for certificate resources. It seems analogous to allowing them for the directory resource, just on the opposite side of the process. That is, the directory and certificate resources are the interfaces between ACME and the outside world, so it makes sense not to force the outside world into the ACME authentication model. In the same vein, capability URLs could be sensible here as an optional protection, since they're an authn model that's easy for the outside world to use. In addition, the content of certificate resources is tightly constrained, so we don't have the problem that we have with the JSON resources, that a server might add some information that violates privacy expectations. So I would propose that we say: - GETs are allowed for directory, newNonce, and certificate resources - Servers MUST still respond to POST-as-GET requests for certificates, to simplify client logic - If a server is concerned about the privacy of certificate resources, then they SHOULD assign them capability URLs. I'll be updating the PR to reflect some comments in Github a little later today, and will incorporate the above unless people think it's awful. --Richard On Thu, Aug 30, 2018 at 8:46 PM Felipe Gasper wrote: > > > > On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > > Would it work to keep certificate fetches as plain GET? > > > > > > In shared hosting environments it’s common for a privileged process to > request certificates on behalf of user accounts. This avoids having 1,000s > of ACME server registrations from a single server. While certificates are > generally made available within seconds, theoretically the delay between > request and issuance could be much longer (e.g., for OV/EV), such that it > might be prudent for that privileged process to give the order ID to the > user and have the user poll for the certificate, e.g., via cron. > > > > This use case makes sense, but I think it is not critical enough to > carve out an exception from the "GETs become POSTs" plan. If the ACME > implementation structures certificate fetches such that they are > enumerable, you would wind up again with the same sort of correlation > problem Adam brought up. You could make the certificate URLs unpredictable, > but then you've introduced a notion of capability URLs[1], which breaks the > notion of having a single authentication system for ACME. > > I suppose if I have: > > GET /order/123/certificate=> cert for yin.com > > GET /order/124/certificate=> cert for yang.com > > … then one could surmise (however justifiably) that these two may be > related, so I see the point. > > > You could make the certificate URLs unpredictable, but then you've > introduced a notion of capability URLs[1], which breaks the notion of > having a single authentication system for ACME. > > I can see that. > > > Thanks for your consideration! > > -FG > ___ > 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] ACME breaking change: Most GETs become POSTs
> On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > Would it work to keep certificate fetches as plain GET? > > > > In shared hosting environments it’s common for a privileged process to > > request certificates on behalf of user accounts. This avoids having 1,000s > > of ACME server registrations from a single server. While certificates are > > generally made available within seconds, theoretically the delay between > > request and issuance could be much longer (e.g., for OV/EV), such that it > > might be prudent for that privileged process to give the order ID to the > > user and have the user poll for the certificate, e.g., via cron. > > This use case makes sense, but I think it is not critical enough to carve out > an exception from the "GETs become POSTs" plan. If the ACME implementation > structures certificate fetches such that they are enumerable, you would wind > up again with the same sort of correlation problem Adam brought up. You could > make the certificate URLs unpredictable, but then you've introduced a notion > of capability URLs[1], which breaks the notion of having a single > authentication system for ACME. I suppose if I have: GET /order/123/certificate=> cert for yin.com GET /order/124/certificate=> cert for yang.com … then one could surmise (however justifiably) that these two may be related, so I see the point. > You could make the certificate URLs unpredictable, but then you've introduced > a notion of capability URLs[1], which breaks the notion of having a single > authentication system for ACME. I can see that. Thanks for your consideration! -FG ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On 8/30/18 6: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. To be clear -- and I'm just repeating an observation that Richard made -- servers can continue to accept GET for the resources in question (order lists, orders, and certificates) for the foreseeable future, while also accepting POST for them [1]. Doing so would allow clients to switch from using GET to using POST for these resources at a leisurely pace, and then servers could turn off GET functionality (i.e., start returning 405's) once usage drops to an acceptable level. 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. I think this is the right call also, regardless of how breaking a change it might be. What I'd really like to avoid is a perpetual tax on developing ACME extensions in the form of having to perform extensive privacy analysis on every new endpoint, every new field, and every new identifier type that can be retrieved without authentication; and, as far as I can tell, that's the only other option here. For avoidance of doubt, I'm speaking as an individual in the preceding paragraph. As an AD with a DISCUSS on this document, I want to make it clear that any solution to the privacy issue will satisfy my DISCUSS. But as an individual, I would be sad if the decision taken was one that hamstrings future protocol development. /a [1] This would presumably be coupled with an implementation-specific analysis of whether GET-able information can be correlated, and making adjustments if so. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") On 08/30/2018 11:17 AM, Felipe Gasper wrote: > Would it work to keep certificate fetches as plain GET? > > In shared hosting environments it’s common for a privileged process to request certificates on behalf of user accounts. This avoids having 1,000s of ACME server registrations from a single server. While certificates are generally made available within seconds, theoretically the delay between request and issuance could be much longer (e.g., for OV/EV), such that it might be prudent for that privileged process to give the order ID to the user and have the user poll for the certificate, e.g., via cron. This use case makes sense, but I think it is not critical enough to carve out an exception from the "GETs become POSTs" plan. If the ACME implementation structures certificate fetches such that they are enumerable, you would wind up again with the same sort of correlation problem Adam brought up. You could make the certificate URLs unpredictable, but then you've introduced a notion of capability URLs[1], which breaks the notion of having a single authentication system for ACME. It seems just as possible for the unprivileged process to do the polling for the certificate, and once it's ready, make it available on the filesystem for the unprivileged user. [1] https://www.w3.org/TR/capability-urls/ ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
