Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 8/30/18 8:48 AM, Felix Fontein wrote:
> Hello,
>
>> On 8/30/18 7:55 AM, Richard Barnes wrote:
>>> Focusing on DISCUSS comment for now, will pick up COMMENTs later.
>>>
>>> On your DISCUSS, I think you're off on a couple of small things
>>
>> Yeah, I woke up with the sudden realization that I'd had the wrong
>> model in my head when I talked through the cert endpoint. All that's
>> there is a signed public cert rather than a public/private pair, so
>> it's not sensitive.
> what happens if the cert URL is not
> https://example.com/acme/cert/somerandomlookingidentifier, but
> https://example.com/acme/acct/2/order/1/cert? Then someone can still do
> identification correlation when the certificate can be downloaded
> without authentication.


That's a good point as well.

After some further discussion, I think there are two potential paths 
forward:

 1. Remove all uses of GET from the specification (except for retrieving
    the directory), which causes all requests to be authenticated, or
 2. Scrub all of the ACME documents to ensure that the resources that
    can be retrieved without authentication cannot be correlated with
    each other.

Approach 1 (which is a stronger form of what Richard proposed in his PR) 
has the advantage of closing all privacy holes, even the ones that we 
can't identify at the moment. It has the disadvantage of differing from 
current deployed implementations.

Approach 2 has the advantage of being consistent with today's 
deployments, but has the drawback that it it requires significant new 
work to identify and address means of correlating resources with each 
other. It's worth noting that the extensibility of the protocol makes it 
necessary to perform this analysis every time a new field is added to a 
structure and every time a new HTTP endpoint type is defined, which 
makes this approach extremely fragile. In particular, the fact that 
individual implementations can include arbitrary JSON fields for 
debugging and/or proprietary behavior means that we're going to require 
implementations to independently perform this analysis for every 
nonstandard field they add to the structure as well.

/a