Re: [art] On BCP 190

[Mark Nottingham <[e-mail]>]

> On 24 Jul 2019, at 1:49 pm, Jacob Hoffman-Andrews <[e-mail]> wrote:
> 
> On Wed, Jul 24, 2019 at 10:24 AM Mark Nottingham <[e-mail]> wrote:
> > It's this part of BCP 190 Section 2.3 that is causing the issue:
> > 
> > >  Specifying a fixed path relative to another (e.g., {whatever}/myapp)
> > >  is also bad practice (even if "whatever" is discovered as suggested
> > >   in Section 3); while doing so might prevent collisions, it does not
> > >   avoid the potential for operational difficulties (for example, an
> > >   implementation that prefers to use query processing instead, because
> > >   of implementation constraints).
> > 
> > To be clear, the "whatever" in this case is referred to as <log server> in CT, and is discovered via the known logs list (https://www.certificate-transparency.org/known-logs) and browser CT programs.
> 
> Yes -- and this text should definitely be considered when revising 190. Like I said, we've moved on a fair amount since then (although we still have a ways to go). 
> 
> One thing I'd like to see in a revision is a clearer separation between "you're potentially harming others by doing this; don't do it" and "you're potentially harming yourself by doing this; think carefully before proceeding."
> 
> Which category to you think that paragraph of Section 2.3 (call it 2.3b) belongs to? It sounds like it belongs to the "harming yourself" category, which means that it's not actually protecting a commons.

Probably the latter. That's just my opinion, though -- which is why if you want to go down the exception path, the best thing to do would be to coordinate with the AD and figure out what that's going to take.

> And to be clear, even though 2.3b sounds advisory-only, it's this clause at the top of Section 2.3 that has broader normative language:
> 
> > specifications MUST NOT constrain,
> >   or define the structure or the semantics for any path component.

Yep.

> a) that some people don't have access to .well-known on their servers -- but this seems like a very poor argument for this particular use case.
> 
> Andrew Ayer presented one concrete case where the use of .well-known presented implementation difficulties for Google, a company that presumably has full control over its servers. I don't know the details of why, but I can guess: .well-known is dangerous. As a hosting provider, allowing users to upload abritrary files to /.well-known/acme-challenge means the users can get certificates for the hosted domain name. Probably there are other security-relevant things under /.well-known/. The safe and reasonable thing is to just block access to /.well-known/. I would guess that Google's security team has set a policy: All access to .well-known is blocked at the frontends unless it's gone through a detailed review.

Having a local policy for control of the name space of a web server seems like a good thing. I'm not finding that a particularly convincing reason -- especially when the review will likely amount to "consult the RFC."  Shrug.

> So we have advice in BCP 190 meant to ensure that protocols allow implementers to implement any way they want (e.g. with query parameters to represent semantics). But instead, the advice to require /.well-known/ is creating practical barriers for implementers to implement things in the way they want.

Going from "google has a policy for their web servers" to "practical barriers" for the entire protocol seems like a long bow to draw. 


Cheers,

--
Mark Nottingham   https://www.mnot.net/