Subject: [Ohttp] Discovery (no)

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Jun 2021 11:35:24 +1000

Since discovery is coming up in a lot of the chartering comments, I want to point out that HTTP proxies in general have no standard discovery mechanism; the most we have is proxy.pac + WPAD, which are widely seen as actively harmful (especially the latter).

HTTP proxying nevertheless does just fine, because the primary models -- client-selected and server-selected intermediation -- work just fine, and don't require any discovery mechanism.

I think the same applies here, and would go as far as to say that requiring the specification of a discovery mechanism adds a lot of risk.

Cheers,

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

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Jun 2021 12:03:56 +1000

Thanks Mark,

Clearly I agree with this (for similar reasons and more).

On the positive side, I believe that the charter text is fairly clear on this point:

> The working group will not define any methods for discovering proxy or server endpoints; specific uses of the protocol will need to describe discovery methods or rely on configuration.

On Fri, Jun 18, 2021, at 11:35, Mark Nottingham wrote:
> Since discovery is coming up in a lot of the chartering comments, I 
> want to point out that HTTP proxies in general have no standard 
> discovery mechanism; the most we have is proxy.pac + WPAD, which are 
> widely seen as actively harmful (especially the latter).
> 
> HTTP proxying nevertheless does just fine, because the primary models 
> -- client-selected and server-selected intermediation -- work just 
> fine, and don't require any discovery mechanism.
> 
> I think the same applies here, and would go as far as to say that 
> requiring the specification of a discovery mechanism adds a lot of risk.
> 
> Cheers,
> 
> --
> Ohttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ohttp
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Jun 2021 08:26:32 +0200

Hi Mark,

> HTTP proxying nevertheless does just fine, because the primary models -- client-selected and server-selected intermediation -- work just fine, and don't require any discovery mechanism.

If we were to run a survey of enterprise network managers, asking what 
they thought about the complexity of managing proxies, I'm quite 
confident that you would hear a woeful tale.  None of that is relevant 
here for a variety of reasons, the first of which is that the history of 
HTTP is both long and twisted around the evolving nature of the network 
and what was carried over it.  The second issue is that the proxy.pac 
file was created in the first place to answer one question: what's 
local?  That question isn't at issue here.

To me, the primary issue here is about trust and agency.  In the cases 
you mentioned, there is at least *some* relationship between the 
individual using the proxy and the proxy itself.  Here that's at least 
not clearly the case.

The use cases that have been discussed talk about O&M to manufacturers.  
That at least is concrete, where discovery isn't. It does raise issues 
about exfiltration over the top of TLS proxies.  Yes, that happens 
today, but maybe we shouldn't condone that practice.  But maybe there's 
also a way to address the O&M needs in a way that doesn't risk 
exfiltration.  In any case, understanding all the actors here is important.

The second potential use case is for DOH.  Either that is in scope and 
should be discussed, or it isn't.  That use case could present 
substantial abuse risks, particularly around botnet C&Cs, and then this 
work would be interacting with ADD.

> I think the same applies here, and would go as far as to say that requiring the specification of a discovery mechanism adds a lot of risk.

Risk to whom and why?  Seems like there are plenty of risks to discuss.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Jun 2021 17:21:05 +1000

Eliot,

> On 18 Jun 2021, at 4:26 pm, Eliot Lear <[email-masked]> wrote:
> If we were to run a survey of enterprise network managers, asking what they thought about the complexity of managing proxies, I'm quite confident that you would hear a woeful tale.  

I'm a bit familiar with that; for example, I designed and ran a global proxy deployment for a Fortune 25 company. That company no longer exists as an independent entity, but the experience was enlightening.

> None of that is relevant here for a variety of reasons, the first of which is that the history of HTTP is both long and twisted around the evolving nature of the network and what was carried over it.  The second issue is that the proxy.pac file was created in the first place to answer one question: what's local?  That question isn't at issue here.
> 
> To me, the primary issue here is about trust and agency.  In the cases you mentioned, there is at least some relationship between the individual using the proxy and the proxy itself.  Here that's at least not clearly the case.
> 
> The use cases that have been discussed talk about O&M to manufacturers.  That at least is concrete, where discovery isn't.  It does raise issues about exfiltration over the top of TLS proxies.  Yes, that happens today, but maybe we shouldn't condone that practice.  But maybe there's also a way to address the O&M needs in a way that doesn't risk exfiltration.  In any case, understanding all the actors here is important.

To be clear, you're talking about exfiltration across MITM TLS proxies -- i.e., those that have a CA pre-configured on the client so that the network operator can intercept, read, and potentially change traffic as they see fit, correct?

If we're going to talk about what we shouldn't condone, I'd start there...

In any case, a similar approach can be taken. If someone has access to the machine to install a MITM cert, they can configure the machine to stop or re-route this mechanism. You may be worried that some vendors may demur from making that easy to do, but that's a problem for the market to solve, not the IETF. This should not affect the design of the protocol.

> The second potential use case is for DOH.  Either that is in scope and should be discussed, or it isn't.  That use case could present substantial abuse risks, particularly around botnet C&Cs, and then this work would be interacting with ADD.

Those risks are present with or without proxies of any sort. What it sounds like you're concerned about is the effectiveness of 'solutions' (e.g., DLP, other forms of monitoring) which rely on all DNS going through the resolver advertised via DHCP, and/or ones that envision all TLS traffic being subject to MITM through a configured CA.

The approach above covers that.

So I don't see how any of this is relevant to the Subject of this thread. Do you have a use case which requires discovery? Or is it just that you wish it possible to force obligatory use of a discovery mechanism upon others?

> Risk to whom and why?  Seems like there are plenty of risks to discuss.

Search for 'WPAD vulnerability' and then let's talk.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Jun 2021 17:53:29 +1000

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 OK if you want to say "don't standardize this".  That's a valid opinion.  We can then disagree.  But it sounds like you think that there is something we (collectively) need to be doing and it would really help to have that stated clearly.

On Fri, Jun 18, 2021, at 17:21, Mark Nottingham wrote:
> In any case, a similar approach can be taken. If someone has access to 
> the machine to install a MITM cert, they can configure the machine to 
> stop or re-route this mechanism. You may be worried that some vendors 
> may demur from making that easy to do, but that's a problem for the 
> market to solve, not the IETF. This should not affect the design of the 
> protocol.

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

As for endpoint-level controls, I'm guessing that we would probably rely on OHTTP being turned off entirely, rather than enable some sort of interception control, but we haven't gotten that far in terms of detailed planning.  That applies to DoH and telemetry both.  A lot of our enterprise deployments disable both already.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Jun 2021 16:25:15 +0200

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.

> 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'…

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 protoco…

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

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 23 Jun 2021 16:31:06 +0200 (CEST)

> Il 18/06/2021 16:25 Eliot Lear <[email-masked]> ha scritto:
> 
>  
> So... &TLDR;
> 
> Change:
> 

I would support this addition, but I would also mention some of the other concerns that have been expressed, at least in terms of documenting possible unintended consequences and ways to deal with them. So I would then add:

"The working group will also consider and address the possible effects of a generalized deployment of the protocol outside of the applicability statement, in terms of possible impacts on Internet security and privacy, centralisation trends and issues around jurisdiction and law enforcement."

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Jun 2021 07:40:50 -0700

On Wed, Jun 23, 2021 at 7:31 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> I would support this addition, but I would also mention some of the other
> concerns that have been expressed, at least in terms of documenting
> possible unintended consequences and ways to deal with them. So I would
> then add:
>
> "The working group will also consider and address the possible effects of
> a generalized deployment of the protocol outside of the applicability
> statement, in terms of possible impacts on Internet security and privacy,
> centralisation trends and issues around jurisdiction and law enforcement."
>

I do not believe we should do this work. It is not necessary for defining
the protocol and seems to mostly an opportunity for argument.

Finally, "issues around... law enforcement" seems to conflict with the
intent of RFC 2804.

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 25 Jun 2021 10:29:06 +1000

On Thu, Jun 24, 2021, at 00:40, Eric Rescorla wrote:
> I do not believe we should do this work. It is not necessary for 
> defining the protocol and seems to mostly an opportunity for argument.

This I agree with.  I think that Eliot was asking for something more targeted in his request, which was to consider the implications to operational practices.  His suggest was specifically:

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

The first clause "will consider and address operational matters" is almost motherhood and apple pie.  I would hope that this is something every protocol design effort includes.  The latter requires a commitment that we not break existing deployments.  I have to push back on that.

I understand that there are important use cases that might be affected by the widespread deployment of new security protocols.  That's commonplace.  But we don't agree not to design a protocol solely on the basis that it affects practices.  We do things like consider whether there are alternative ways in which the same goals might be met, or whether the practices are worth protecting.  If a use case is important and there are no good alternatives as a result of the new design, that is grounds for rejecting a protocol.

My counter-proposal:

> The working group will consider the operational impact as part of the protocol design and document operational considerations.
-- https://github.com/unicorn-wg/ohttp-charter/pull/2

That's a bit broader, as it also relates to how clients and servers might operate (and the client piece might be related to Zahed's ask).  I think that does partially cover Vittorio's ask as well, at least from the angles that are in scope for IETF work.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Jun 2021 09:03:06 +0200

Hi Martin,

On 25.06.21 02:29, Martin Thomson wrote
> I understand that there are important use cases that might be affected by the widespread deployment of new security protocols.  That's commonplace.  But we don't agree not to design a protocol sole…

While I do believe the IETF should have a broader discussion about 
rfc2804 and societal implications of our work, now that I understand the 
use case, we needn't have that conversation now. You're right: I am 

>> The working group will consider the operational impact as part of the protocol design and document operational considerations.

There are two issues that we should specifically address:

  * Enterprise controls should not be subverted, especially when it's
    unnecessary to do so in this particular case.  Mark accurately
    described what I was referring to.
  * The risks of use of the mechanism need to be understood as part of
    its applicability, particularly as relates to DNS and similar and
    the masking of C&C networks.  That harms the Internet, and so is in
    scope.

Let's all agree that these conversations will happen, relating to the 
protocol design, and I can live with the above words.

The broader conversation about the evolving Internet Threat Model needs 
to once again be rebooted, but that doesn't need to happen in this WG.  
It really does need to happen.

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Jun 2021 17:38:55 +1000

Eliot,

On 19 Jun 2021, at 12:25 am, Eliot Lear <[email-masked]> wrote:
> 
> += The working group will consider and address operational matters, so that the output does not introduce any substantial negative impact to existing deployments.

This is a very Russell's Teapot kind of requirement; quantifying that there is no 'substantial negative impact to existing deployments' is a massive undertaking, considering the size of the Internet.

It's also loading a lot into 'operational matters'; the language seems to automatically prioritise them over any other concern engaged by the work. That seems deeply problematic to me; if we're going to prioritise anything, it should not be that. 

Lastly, it is effectively applying the Precautionary Principle to our work. While I strongly support the idea of being more careful and thoughtful in our actions, this is a 180 degree turn for the IETF, and I don't believe it's got the balance right to say that we must be certain there's no harm to a specific constituency to proceed.

Martin's proposal is much more reasonable. 

Cheers,

---

From: Andrew Campling <[email-masked]>
Date: Fri, 25 Jun 2021 08:22:01 +0000

>Lastly, it is effectively applying the Precautionary Principle to our work. While I strongly support the idea of being more careful and thoughtful in our actions, this is a 180 degree turn for the I…

Noting RFC8890, if the Internet really is for end users then it seems perfectly valid that, at a minimum, consideration should be given to the operational impact of new protocols.  One way to address this would be to undertake some multi-stakeholder engagement to find out whether there are significant operational downsides that should be taken into account.  Whilst I understand that such an undertaking will not be attractive to everyone, it is a reasonable expectation that this is done before a new protocol is introduced if we are to avoid or at least minimise any harmful effects.  

Andrew

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Jun 2021 18:24:48 +1000

> Noting RFC8890, if the Internet really is for end users then it seems perfectly valid that, at a minimum, consideration should be given to the operational impact of new protocols.  One way to addre…

Yes - but there's a difference between doing that work and achieving certainty that there aren't any substantial negative effects on operations.

---

From: Andrew Campling <[email-masked]>
Date: Fri, 25 Jun 2021 08:49:59 +0000

>Yes - but there's a difference between doing that work and achieving certainty that there aren't any substantial negative effects on operations.

Achieving certainty may not be possible but that shouldn't prevent us from making the effort.  By engaging with a multistakeholder group, it should be possible to ascertain relatively quickly whether there are likely to be widespread negative effects caused by the introduction of OHTTP.  To be clear, I don't believe that the working group can undertake anything other than a relatively superficial review of the effects without involving a broader group of stakeholders even though it would be much easier that way.   

Moving back to the topic of discovery, experience with DoH highlights the dangers of a working group only completing part of the work where the lack of a discovery mechanism has impaired take up.  There was a delay of around 18 months before the ADD working group could be chartered and work started on discovery; repeating that approach here seems both unnecessary and inefficient.  Why not include discovery in the scope of the charter so that the working group can consider whether a mechanism is required and, if so, provide a suitable solution?  

Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 25 Jun 2021 10:58:22 +0200 (CEST)

> Il 25/06/2021 10:24 Mark Nottingham <[email-masked]> ha scritto:
> 

Indeed, innovation often disrupts pre-existing operations and even entire industries, and this in itself is not a good reason to stop it (some would say it is actually a good reason not to stop it). However, the point is whether the change in its entirety will lead the Internet to a state which is better or worse than the current one, especially when judged from the viewpoint of the end-users. If something benefits one industry, damages another, but makes things better for end-users, let's bring it forth. If however the change benefits the industry but damages many of the end-users, then it is not in line with the IETF's declared priority of stakeholders.

Then, the question is who would make that evaluation, as it clearly requires non-technical input from non-technical stakeholders. While I concur that this is a more general discussion that cannot be addressed as part of the chartering of a specific WG, it's also true that it cannot be deferred forever because it is too complex to discuss it here and now.

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Jun 2021 13:56:08 +0000

This is an interesting discussion over whether the WG charter should permit the WG to delve into operational implications in some manner.  In my mind these are as much operational implications as they are design choices or tradeoffs in the design - so putting aside the "operational implication" label I don't know why we'd not directly address what problems OHTTP is meant to solve and what the implications of the design choices may mean without making a judgement on whether the implications or tradeoffs are "good" or "bad".

In my reading of the discussion & charter, it seems like if the design is intended to prevent revealing client source IP addresses to destination HTTP servers then that might mean some of the existing mechanisms for content localization (e.g. based on geolocation & network) would not work or would be less effective - and this may be totally fine for some use cases & threat models. And perhaps new mechanisms will arise to solve this, that provides some sense of geographic and network location but not at too specific a level. But in using OHTTP, ISTM the user or user-agent is making a tradeoff between the pros & cons of sharing that source information (e.g. CDN performance) vs. the privacy pros & cons of that source information being available to a web app platform. So why not explain that?

As well, is it worth including somewhere an explanation that within HTTP content exchange & user agents that cookies or authentication can also be used for user tracking and that OHTTP would not protect against tracking via those mechanisms? Those mechanisms may even be more central to how user tracking occurs.

Jason

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jun 2021 07:40:14 -0700

On Fri, Jun 25, 2021 at 1:22 AM Andrew Campling
<[email-masked]> wrote:

> >This is a very Russell's Teapot kind of requirement; quantifying that
> there is no 'substantial negative impact to existing deployments' is a
> massive undertaking, considering the size of the Internet.
> >
> >It's also loading a lot into 'operational matters'; the language seems to
> automatically prioritise them over any other concern engaged by the work.
> That seems deeply problematic to me; if we're going to prioritise anything,
> it should not be that.
> >
> >Lastly, it is effectively applying the Precautionary Principle to our
> work. While I strongly support the idea of being more careful and
> thoughtful in our actions, this is a 180 degree turn for the IETF, and I
> don't believe it's got the balance right to say that we must be certain
> there's no harm to a specific constituency to proceed.
>
> Noting RFC8890, if the Internet really is for end users then it seems
> perfectly valid that, at a minimum, consideration should be given to the
> operational impact of new protocols.  One way to address this would be to
> undertake some multi-stakeholder engagement

I believe that engagement is called "an IETF WG".

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jun 2021 07:50:55 -0700

On Fri, Jun 25, 2021 at 1:50 AM Andrew Campling
<[email-masked]> wrote:

>
> Moving back to the topic of discovery, experience with DoH highlights the
> dangers of a working group only completing part of the work where the lack
> of a discovery mechanism has impaired take up.  There was a delay of around
> 18 months before the ADD working group could be chartered and work started
> on discovery; repeating that approach here seems both unnecessary and
> inefficient.

At the risk of relitigating a discussion which has already been discussed
ad nauseum. I do not agree with this assessment.

To the contrary, I think the ADD process ought to lead one to the
conclusion that in the current setting discovery for DoH is of relatively
limited applicability. Having attempted to solve it before standardizing
the transport would have delayed the fairly substantial amount of
deployment we are already seeing.

Why not include discovery in the scope of the charter so that the working
> group can consider whether a mechanism is required and, if so, provide a
> suitable solution?
>

There are two kinds of discovery that one might imagine being in scope:

1. Discovery of proxies.
2. Discovery that a server is O-HTTP capable

The former is extremely difficult, for many of the same trust reasons that
DoX discovery is difficult, but even moreso. The second is cleanly
separable. Given that there is real value in the protocol with neither form
of discovery, I don't think it's useful to charter them, especially in the
absence of any real proposals. If someone comes up with such a proposal, we
can consider a recharter then.

-Ekr

---

From: Andrew Campling <[email-masked]>
Date: Fri, 25 Jun 2021 15:31:23 +0000

On Fri, Jun 25, 2021 at 15:40, Eric Rescorla <[email-masked]> wrote:
>
> On Fri, Jun 25, 2021 at 1:22 AM Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:
>> Noting RFC8890, if the Internet really is for end users then it seems perfectly valid that, at a minimum, consideration should be given to the operational impact of new protocols.  One way to address this would be to undertake some multi-stakeholder engagement
>

I disagree.  If IETF WGs were able to function effectively in multi-stakeholder engagement then it would not have been necessary to issue RFC 8890 and reference the need to undertake such engagement.  The reality is that most WGs are drawn from a relatively narrow pool of people, hence discussions on other lists about the need to improve diversity etc.

We could either guess what, to use Jason’s phrasing, the implications of the design choices may mean for different groups or we could actually ask them.  The latter approach would seem to me to be consistent with RFC 8890 and ought to lead to better design choices.

Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 25 Jun 2021 18:33:49 +0200 (CEST)

>     Il 25/06/2021 17:31 Andrew Campling <[email-masked]> ha scritto:
> 
> 
>     > On Fri, Jun 25, 2021 at 1:22 AM Andrew Campling <[email-masked] mailto:[email-masked] > wrote:
Speaking of a different limb of the same elephant in the room, I'd like to share Mark's excellent post on the increasingly difficult relationship between global technical standards and national public policy needs:

https://www.mnot.net/blog/2021/06/21/standards-competition-governance

I know this is off topic for this list, as it is a much more general issue than the charter of a specific working group. Yet, we'd really need to have that general discussion somewhere, as the problem of potential conflicts between new standards and the expectations of non-technical stakeholders will pop up in many attempts to start new work.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Jun 2021 18:23:33 +0000

> The former is extremely difficult, for many of the same trust reasons that DoX discovery is difficult, but even moreso. The second is cleanly separable. Given that there is real value in the protocol with neither form of discovery, I don't think it's useful to charter them, especially in the absence of any real proposals. If someone comes up with such a proposal, we can consider a recharter then.

Just throwing out ideas to see if there's common ground... Another way to approach it might be to say in the charter that discovery is not an initial priority but the WG may address it later on, or at a lower priority, or in parallel. That could enable those folks interested in that problem to feel like they have a productive outlet for doing so. Of course the challenge for the WG chairs would be to ensure that did not detract from dev of the core protocol.

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Jun 2021 18:29:31 +0000

> To the contrary, I think the ADD process ought to lead one to the conclusion that in the current setting discovery for DoH is of relatively limited applicability. Having attempted to solve it before standardizing the transport would have delayed the fairly substantial amount of deployment we are already seeing.

This seems a fair point. There's always this sort of tension (in the productive sense of that word, as much as it can feel difficult in the moment) in many WGs. Do you perfect something end to end before standardizing fully or try a bunch of stuff out in the real world and standardize bits and pieces as you figure things out? Both approaches are used and there are pros and cons to each.

I think I've now succeeded in saying exactly nothing of value, which is fine because today is Friday. ;-)

JL

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jun 2021 11:30:04 -0700

On Fri, Jun 25, 2021 at 11:23 AM Livingood, Jason <Jason_Livingood=
[email-masked]> wrote:

> > The former is extremely difficult, for many of the same trust reasons
> that DoX discovery is difficult, but even moreso. The second is cleanly
> Just throwing out ideas to see if there's common ground... Another way to
> approach it might be to say in the charter that discovery is not an initial
> priority but the WG may address it later on, or at a lower priority, or in
> parallel. That could enable those folks interested in that problem to feel
> like they have a productive outlet for doing so. Of course the challenge
> for the WG chairs would be to ensure that did not detract from dev of the
> core protocol.
>

This seems reasonable to me, as long as it's not a gating factor for
publishing the main document.

-Ekr

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Jun 2021 18:52:16 +0000

> This seems reasonable to me, as long as it's not a gating factor for publishing the main document.

+1 (not gating)