On Tue, 26 Mar 2019 at 10:48, Paul Vixie wrote:
>
>
> Ian Swett wrote on 2019-03-25 01:28:
> > One way DoH may be faster than DoT in the near future is that DoH can go
> > over HTTP/3 via QUIC and avoid head of line blocking like Do53.
> Do53/UDP has no HoL prolem.
>
> nor does Do853/TCP.
>
TCP
On Mon, 25 Mar 2019 at 16:05, Tony Finch wrote:
> Ted Lemon wrote:
>
> > This is equally an argument for doing DNS over DTLS. This would give
> > similar performance to DoH over QUIC.
>
> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> application protocol. The DNS
Ian Swett wrote on 2019-03-25 01:28:
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Do53/UDP has no HoL prolem.
nor does Do853/TCP.
only Do53/TCP had an HoL problem, so, it was never widely used, and
It seems like SACK would make the problem less bad in theory, but wouldn’t
eliminate the problem. With DNS-over-DTLS, if a packet is lost, the next
packet still gets an immediate answer, because DTLS is a datagram protocol, not
a stream protocol. The retry strategy for DNS-over-DTLS would
Ted Lemon wrote:
> On Mar 25, 2019, at 4:04 PM, Tony Finch wrote:
> > If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> > application protocol. The DNS has horrible packet size problems, so it
> > needs a lot more help than DTLS provides. QUIC is much better.
>
>
On Mar 25, 2019, at 4:04 PM, Tony Finch wrote:
> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> application protocol. The DNS has horrible packet size problems, so it
> needs a lot more help than DTLS provides. QUIC is much better.
Indeed. My point was simply that
Ted Lemon wrote:
> This is equally an argument for doing DNS over DTLS. This would give
> similar performance to DoH over QUIC.
If I understand it correctly, DTLS leaves MTU and fragmentation up to the
application protocol. The DNS has horrible packet size problems, so it
needs a lot more help
Ian Swett wrote:
> One way DoH may be faster than DoT in the near future is that DoH can go
> over HTTP/3 via QUIC and avoid head of line blocking like Do53.
It ought to be better to have native DoQ to eliminate the overhead of the
http layer. Dunno whether this should use yet another port (all
On 25/03/2019 10:41, Patrick McManus wrote:
I've seen this confusion before, so I can clear it up!
Ray is (I believe) referring to the flexible re-ordering of DNS
request-reply pairs of a TCP channel.. similar to HTTP/2 (though with
less flexibility in granularity iirc). That addresses
This is equally an argument for doing DNS over DTLS. This would give
similar performance to DoH over QUIC.
On Mon, Mar 25, 2019 at 10:43 Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <
>>
On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus
wrote:
>
>
> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>>>
>>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
>> not believe anyone has proposed explicit downgrade
On Mon, Mar 25, 2019 at 9:58 AM Ray Bellis wrote:
>
>
> On 25/03/2019 09:28, Ian Swett wrote:
> > One way DoH may be faster than DoT in the near future is that DoH can go
> > over HTTP/3 via QUIC and avoid head of line blocking like Do53.
>
> Head of line blocking shouldn't happen on a modern
On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson
wrote:
>
>
>>
>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
> not believe anyone has proposed explicit downgrade triggers.
>
that's the downgrade I am referring to
> Or do you mean, when a DoT connection is blocked by
On 25 Mar 2019, at 10:25, Stephen Farrell wrote:
> I see a problem with the above argument. DNS means nothing to
> most people, so I can't see how they can ever make the informed
> decision you mention.
I view that as a research question (I don’t accept your assertion, but neither
can I
Hiya,
On 25/03/2019 09:13, Eliot Lear wrote:
> Putting aside legal language, but Brian’s basic notion is that the
> user can make an informed decision and the network can express its
> policies, with which the user can agree or not agree (and go
> elsewhere). Having the protocol elements to
Hi,
> On 24 Mar 2019, at 23:25, Paul Wouters wrote:
>
>> The blocking of DoT to a given provider should be interpreted as an explicit
>> policy. Users should be informed
>> that they may, and very likely will, be violating someone’s policy, if they
>> choose to use DoH in that
>>
On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu
wrote:
> On Mon, 25 Mar 2019 at 09:15, Brian Dickson
> wrote:
>
>>
>>
>> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
>> wrote:
>>
>>> I'm not pushing against DoT per se in this thread, I am pushing against
>>> the notion that a client has an
On 25/03/2019 09:28, Ian Swett wrote:
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Head of line blocking shouldn't happen on a modern Do53 server.
See RFC 7766 §6.2.1.1
Ray
On Mon, 25 Mar 2019 at 09:15, Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se in this thread, I am pushing against
>> the notion that a client has an obligation to the network to provide a
>> clear channel for traffic
> The DoH operators who have made public statements (google and cloudflare
> are two I am aware of), have specifically indicated that NO OTHER HTTPS
> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.
I have seen such a public statement from Google. Where have you seen a
similar
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
I think it would be better to
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
On Mon, Mar 25, 2019 at 4:15 AM Brian Dickson
wrote:
>
>
> On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
> wrote:
>
>> I'm not pushing against DoT per se
On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
> fwiw - there are lots of
I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an
> On 25 Mar 2019, at 6:06 pm, Daniel Stenberg wrote:
>
> On Sun, 24 Mar 2019, Vittorio Bertola wrote:
>
>> In today's "plain DNS" world, I choose a DNS resolver that provides that
>> kind of filters for me, I set it up on my router, and my router pushes it to
>> my smart TV via DHCP. What
On Sun, 24 Mar 2019, Vittorio Bertola wrote:
In today's "plain DNS" world, I choose a DNS resolver that provides that
kind of filters for me, I set it up on my router, and my router pushes it to
my smart TV via DHCP. What is the "existing configuration mechanism" that
allows me to set this
Sent from my iPhone
> On Mar 24, 2019, at 10:42 PM, Patrick McManus wrote:
>
>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson
>> wrote:
>>
>> This is important for network operators in identifying encrypted DNS traffic,
>
> not all clients acknowledge a network's right to do such
On Sun, Mar 24, 2019 at 11:25 PM Paul Wouters wrote:
> On Sun, 24 Mar 2019, Brian Dickson wrote:
>
> > There is one important difference, which is that DoT uses a unique port
> number. This is important for network
> > operators in identifying encrypted DNS traffic, in order to ensure that
>
On Sun, Mar 24, 2019 at 11:14 PM Vittorio Bertola
wrote:
>
> In today's "plain DNS" world, I choose a DNS resolver that provides that kind
> of filters for me, I set it up on my router, and my router pushes it to my
> smart TV via DHCP. What is the "existing configuration mechanism" that allows
On Sun, 24 Mar 2019, Brian Dickson wrote:
There is one important difference, which is that DoT uses a unique port number.
This is important for network
operators in identifying encrypted DNS traffic, in order to ensure that
implementation of security policies for
DNS don’t conflict with any
> Il 24 marzo 2019 alle 22.42 Patrick McManus ha scritto:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com mailto:brian.peter.dick...@gmail.com > wrote:
>
> > >
> >
> > This is important for network operators in identifying
On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
> This is important for network operators in identifying encrypted DNS
> traffic,
>
not all clients acknowledge a network's right to do such things at all
times. And of course it would be useful to tell the
Sent from my iPhone
>> On Mar 24, 2019, at 9:43 PM, Patrick McManus wrote:
>>
>>
>
>> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister
>> wrote:
>>
>> Don't overplay the privacy provided by DoH it has no effect on the DNS
>> provider
>
> The major effect of the transport security on
I want to add one thought to the general argument that goes along the lines
of "I need to enforce a policy on my network, and doh will just encourage
more https interception - we have gotten nowhere."
This argument assumes a scenario where the network is trusted by the
application and can
On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister wrote:
>
> Don't overplay the privacy provided by DoH it has no effect on the DNS
> provider
The major effect of the transport security on the privacy practices of the
provider is that it allows the client to authenticate the provider. Trust
35 matches
Mail list logo
