Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs

From: Yaron Sheffer <[email-masked]>
Date: Sat, 1 Sep 2018 22:11:07 +0300

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 <[email-masked] 
> <mailto:[email-masked]>> 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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/acme
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 4 Sep 2018 10:33:50 -0700

> ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing 
Agreed we're solved on this.
> from other POST requests?
Started a separate thread on this.
> ISSUE 3: Should servers be required to allow GET requests for 
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.
> added some text to the PR for this.
This seems like a good plan to me.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 6 Sep 2018 11:02:07 -0400

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 <[email-masked]> 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?
>
> 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
>
> On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <[email-masked]>
> wrote:
>
>> originally discussed in January 2015[1]. We decided to put all sensitive
>> data in the account resource and consider all GET resources public, with
>> be. For instance, some CAs might consider the grouping of certificates
>> Richard Barnes proposes[2] to change all GETs to POSTs (except directory
>> will not be compatible with a draft that mandates POSTs everywhere. It
>> will be a painful change, since the ecosystem just started switching to
>> 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
>> [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Sep 2018 10:13:32 -0500

> Adam: Is this looking like an approach that would satisfy your DISCUSS?

Yes, it would. Thanks to everyone for moving so quickly on this. (n.b.: 
I glanced at the PR, but did not review it in detail. I leave it to the 
WG, its chairs, and the sponsoring AD to ensure the document is 
consistent and reflects consensus.)

/a

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Sep 2018 15:50:16 +0000

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 <[email-masked]>
Date: Thursday, September 6, 2018 at 11:02 AM
To: "[email-masked]" <[email-masked]>
Cc: "<acme-chairs@ietf. org>" <[email-masked]>, Eric Rescorla <[email-masked]>, Adam Roach <[email-masked]>
Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs
Resent-From: <[email-masked]>
Resent-To: Rich Salz <[email-masked]>, Yoav Nir <[email-masked]>
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&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>

Chairs / EKR: How would you like to proceed on closing this out?  What are the next process steps?

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&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>

On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <[email-masked]<mailto:[email-masked]>> wrote:

[1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_letsencrypt_acme-2Dspec_pull_48-23issuecomment-2D70169712&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4g1lhzE_4QDBMJ-WyE17zBBm61tdp2A-ImhSpqHet4&e=>
[2] https://github.com/ietf-wg-acme/acme/pull/445/files<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445_files&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=LoHY-1DpWoqgeBKRrhoq2l8n4_M01eB2qOjY9yUEaRA&e=>

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4LvMdxd6Cmfi4d1ClEC2VFM8ndqUtWVEkoSNvTrg2M&e=>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Sep 2018 09:03:37 -0700

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 <
rsalz=[email-masked]> 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.
>
>
>
> *From: *Richard Barnes <[email-masked]>
> *Date: *Thursday, September 6, 2018 at 11:02 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"<acme-chairs@ietf. org>" <[email-masked]>, Eric Rescorla <
> [email-masked]>, Adam Roach <[email-masked]>
> *Subject: *Re: [Acme] ACME breaking change: Most GETs become POSTs
> *Resent-From: *<[email-masked]>
> *Resent-To: *Rich Salz <[email-masked]>, Yoav Nir <[email-masked]>
> *Resent-Date: *Thursday, September 6, 2018 at 11:02 AM
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>
>
>
>
> [1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_letsencrypt_acme-2Dspec_pull_48-23issuecomment-2D70169712&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4g1lhzE_4QDBMJ-WyE17zBBm61tdp2A-ImhSpqHet4&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445_files&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=LoHY-1DpWoqgeBKRrhoq2l8n4_M01eB2qOjY9yUEaRA&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4LvMdxd6Cmfi4d1ClEC2VFM8ndqUtWVEkoSNvTrg2M&e=>
>
>

---

From: Erica Portnoy <[email-masked]>
Date: Fri, 7 Sep 2018 16:48:39 -0700

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
> <rsalz=[email-masked]
> <mailto:rsalz=[email-masked]>> 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.
>
>      
>
>     *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"<acme-chairs@ietf. org>" <[email-masked]
>     <mailto:[email-masked]>>, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>>, Adam Roach <[email-masked]
>     <mailto:[email-masked]>>
>     *Resent-From: *<[email-masked]
>     <mailto:[email-masked]>>
>     *Resent-To: *Rich Salz <[email-masked]
>     <mailto:[email-masked]>>, Yoav Nir <[email-masked]
>     <mailto:[email-masked]>>
>     After the weekend's discussions, I've updated the PR to reflect
>     what I understand to be emerging agreement on these topics:
>
>      
>
>     ISSUE 4: How should we address the risk that an attacker can
>     discover URLs by probing for Unauthorized vs. Not Found?
>
>         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.
>
>          
>
>         ===
>
>          
>
>         It seems like there's pretty strong agreement that we should
>         get rid of GET, as the architecturally cleanest option.
>
>          
>
>         ===
>
>          
>
>         (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.
>
>          
>
>         ===
>
>          
>
>         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
>
>          
>
>         On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <https://www.ietf.org/mailman/listinfo/acme>
>
>
>
>

---

From: Alan Doherty <[email-masked]>
Date: Mon, 10 Sep 2018 12:12:29 +0100

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
>
>
>>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=[email-masked]>rsalz=[email-masked]> 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.
>>
>>Â 
>>
>>Â 
>>From: Richard Barnes <mailto:[email-masked]><[email-masked]>
>>To: "<mailto:[email-masked]>[email-masked]" <<mailto:[email-masked]>[email-masked]>
>>Cc: "<mailto:[email-masked]><acme-chairs@ietf. org>" <<mailto:[email-masked]>[email-masked]>, Eric Rescorla <<mailto:[email-masked]>[email-masked]>, Adam Roach <<mailto:[email-masked]>[email-masked]>
>>Resent-From: <<mailto:[email-masked]>[email-masked]>
>>Resent-To: Rich Salz <<mailto:[email-masked]>[email-masked]>, Yoav Nir <<mailto:[email-masked]>[email-masked]>
>>Â 
>>Â 
>>Â 
>>Â 
>>Â 
>>Â 
>><https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>https://github.com/ietf-wg-acme/acme/pull/445
>>
>>Â 
>>
>>Â 
>>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:[email-masked]><[email-masked]> 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.
>>
>>Â 
>>
>>===
>>
>>Â 
>>
>>Â 
>>Â 
>>Â 
>>Â 
>>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.
>>
>>Â 
>>
>>===
>>
>>Â 
>>
>>Â 
>>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.
>>
>>Â 
>>
>>===
>>
>>Â 
>>
>>Â 
>>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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_445&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=ARyNYl3lxrI8cMqtfkMceBinUqRQmbZiPk8NXJWj3O0&e=>https://github.com/ietf-wg-acme/acme/pull/445
>>
>>Â 
>>
>>On Thu, Aug 30, 2018 at 7:20 PM Jacob Hoffman-Andrews <<mailto:[email-masked]>[email-masked]> wrote:
>>
>>when the contents of GET URLs arenâ€™t sensitive, their correlation may 
>>protocol long-term if all requests are authenticated. However, if weâ€™re 
>>[1] <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_letsencrypt_acme-2Dspec_pull_48-23issuecomment-2D70169712&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=0WrTFNH1Dw6ptcTgU6p4wrd1zn3ZVatHDOrx8DbEWUM&s=-4g1lhzE_4QDBMJ-WyE17zBBm61tdp2A-ImhSpqHet4&e=>https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
>><mailto:[email-masked]>[email-masked]
>><mailto:[email-masked]>[email-masked]
>><mailto:[email-masked]>[email-masked]

---

From: Erica Portnoy <[email-masked]>
Date: Mon, 10 Sep 2018 08:03:57 -0700

> 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.

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Sep 2018 10:53:53 -0500

[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.

> email addresses, to be sure.

And that's where the most serious damage comes into play.

/a

---

From: Alan Doherty <[email-masked]>
Date: Mon, 10 Sep 2018 17:12:33 +0100

>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?