Re: [Ohttp] Discovery

[Eliot Lear <[e-mail]>]

So... &TLDR;

Change:

The OHTTP working group will include an applicability statement that 
documents the limitations of this design and any usage constraints that 
are necessary to ensure that the protocol is secure.

to (ADD)

+= The working group will consider and address operational matters, so 
that the output does not introduce any substantial negative impact to 
existing deployments.

The rest of the charter I can live with, now that I know what is 
intended.   Note that you do address some of this in the draft already, 
so I don't think the add is much of a stretch.

It would help if you included some use cases in the draft.

On 18.06.21 09:53, Martin Thomson wrote:
> Eliot, this line of argumentation is starting to smell like sealioning.  I know that you don't intend that, but maybe you could make some concrete suggestions for what needs to happen.  I think we're past the point where you don't understand what is being proposed.

It's understandable that advocates would say this, since you live and 
breath your concept (good!).  The rest of us don't, and you didn't 
elaborate how you intended to use this protocol in the draft; and so 
we're all playing catch-up based on this email thread.  The discussion 
seems to be evolving and narrowing based on how you've exposed your 
thinking (good, too!).

> I would also point out that this is going to be quite obvious to a proxy that is able to intercept connections.  That is not substantially different than CONNECT or MASQUE or any of the VPN protocols that exist (both inside and outside of the IETF).

CONNECT is an HTTP method that requires active support, which may well 
be turned off by default or not even present, and when implemented has a 
particular purpose around which enterprise proxies can apply policy.  
MASQUE may well be similar in nature in as much as a TLS proxy would not 
support it by default.  I don't think the same can be said of the POST 
method: it has an existing general use that would require changes to 
deployment denylist patterns.  While that might not be not super hard, 
enterprises not doing so would be in for a surprise.  At least some of 
these proxies are just doing textual scans for information that 
shouldn't leave an environment (customer/patient identity information, 
for instance).  One could reasonably argue that we should use POST just 
to prove the point to enterprises that this exposure exists, regardless 
of the standard, but that would also be viewed a standardized version of 
red teaming without permission, and somewhat paternalistic.

So long as the issue is recognized, how it is addressed is something the 
WG can discuss, develop rough consensus, etc.  You proposed leaving this 
as a configuration option to be used. That's certainly one way to 
address the matter.

To argue the both sides on discovery for just a moment, if we don't have 
a discovery mechanism for when this mechanism is to be used, OHTTP can 
really only be used in very specific ways.  Maybe that's just as well, 
and a good place to start.  A lot of this discussion ties to the 
generality of the mechanism.

I still worry about using this stuff for DOH, and that should be discussed.

Eliot