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

[Felix Fontein <[e-mail]>]

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.

Cheers,
Felix



> > , but right on the underlying point that the document doesn't
> > really provide any guidance as to which resources a server should
> > consider sensitive.  I agree that it would be good to say more, and
> > I've started up a PR for this.
> >
> > https://github.com/ietf-wg-acme/acme/pull/443  
> 
> 
> Thanks -- that fixes the text I cite.
> 
> 
> >
> > I don't agree that sensitivity entails a need for non-guessable
> > URLs. If accessing the URL requires authentication, then it doesn't
> > matter if someone can guess it; unauthorized people can't access it
> > even if they can guess it.  I guess you could argue that if you
> > made a random URL and only distributed it in authenticated
> > channels, then you could allow GETs to it, using the URL itself as
> > an authenticator.  But that seems super brittle; I would rather
> > just have all the authentication be based on signing.  So at best,
> > random URLs are a backstop against a CA making the wrong decision
> > about GETs.  
> 
> 
> Yup, that seems better.
> 
> 
> >
> > You're also correct to note that some resources might be sensitive 
> > that we now instruct clients to poll with GETs. For example, the 
> > client is supposed to poll an authorization resource to see when it 
> > validates, but if the authz has a TN in it and so is considered 
> > sensitive, you won't be able to do a GET.  I think the right answer 
> > here is to have the server return 405 Method Not Allowed if it gets
> > a GET and have the client fall back to an authenticated "POST {}",
> > which should be equivalent to a GET in all cases.  
> 
> 
> That seems like a good clarification. The one remaining issue is the 
> table at the bottom of §7.1, which shows GETs for resources that the
> new text says CAs might consider sensitive. I catch the "might" in
> that sentence, but it seems that identification correlation is a
> pretty powerful privacy leak, and would strongly suggest that the
> table be revised to show POSTs for retrieval of order resources.
> Whether you take this suggestion is up to you -- I'll clear my
> DISCUSS either way.
> 
> /a