>i wonder if everyone here knows that TLS 1.3 and encrypted headers is
>going to push a SOCKS agenda onto enterprises that had not previously
>needed one

I have, ahem, some familiarity with the enterprises and TLS1.3 issue.
(These
past few years have aged me terribly!)  I frankly feel that we have at the
IETF
a problem with the how we do conflict resolution and the process of
consensus
itself.  In fact, I co-authored a draft on this topic:

https://tools.ietf.org/html/draft-elkschul-conflict-problem-00

I feel that until we fix these fundamental issues, we will find ourselves
in this
place again and again.   The next time will be with QUIC (as Paul points out
in his mention of encrypted headers).  I actually have some suggestions as
to how we might better work with each other.  But, I do not want to
sidetrack
into a much larger issue.

At a minimum, I think that some relatively neutral arbiter, say CERT, might
provide an after the fact impact assessment that certain changes such as
DoH and TLS1.3 will have on enterprises, the home user, and so on.   Of
course, it would be better if such a neutral assessment were done BEFORE
the draft becomes final.

This is similar to what is done in California on ballot initiatives.  When
we get our
voting pamphlet, it tells us for each issue, what impact a pro or con vote
will have
on various aspects such as increased taxes, and so forth.

Nalini

On Mon, Mar 11, 2019 at 11:42 PM Paul Vixie <p...@redbarn.org> wrote:

>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one, and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to