On 21.8.2018 04:38, Tom Pusateri wrote:
> Come to think of it, DNSSEC validation in the stub resolver or browser
> is really a place DoH could shine. Instead of all the round trips
> required for validating up (down) the chain, the webserver could package
> up all those validated records and push t
On 08/20/2018 06:11 PM, Paul Hoffman wrote:
DHCP options are easy and cheap. However #2 was vexing. The proposal
that an OS say "oh look, there is a DoH server, I'll use that because it
is more secure than Do53" was what was controversial because of the
utter lack of DHCP security. Some of the
On 08/20/2018 09:22 PM, Bill Woodcock wrote:
On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote:
pusateri> There was general
pusateri> agreement in the room that you only should use DHCP in IPv4
pusateri> for address/router info and then use trusted sources for
pusateri> everything else. In I
I sort of agree. The addressing, a naming function and routing are the
three legs. If you do naming right, you can drop addressing and use
ephemeral addresses, and if you do routing right you can drop
addresses and do ad-hoc. But you need addresses and routing if you
want to do without names, so I
> On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote:
>
>> pusateri> There was general
>> pusateri> agreement in the room that you only should use DHCP in IPv4
>> pusateri> for address/router info and then use trusted sources for
>> pusateri> everything else. In IPv6, SLAAC generally provides thi
George Michaelson wrote:
I am less sure the UDP/TCP thing reduces to "no"
I see no reason any more to assume session cost is too high for a
globally deployed DNS.
I suspect what DNSOPS and a hypothetical directorate thinks about DNS
is less impactful (sorry, hate that word) than what embeds
In article <5b7b7e3b.3060...@redbarn.org> you write:
>if you write down trust assumptions you'll be enumerating disjoint sets
>of same as actually practiced by different users and different operators
>whose reasons should be treated as valid rather than challenged.
We seem to have one group who
I am less sure the UDP/TCP thing reduces to "no"
I see no reason any more to assume session cost is too high for a
globally deployed DNS.
I suspect what DNSOPS and a hypothetical directorate thinks about DNS
is less impactful (sorry, hate that word) than what embeds in Android
devices.
de-facto,
I think we've gone way off track here. DoH exists, and you can't undo
that. Maybe it was a mistake, maybe it wasn't, but that ship has sailed.
I think you're implicitly arguing that the IETF should have done a better
job of modeling the threats before advancing the protocol, and if we had
done
Ted Lemon wrote:
We have no privacy expectations from DNS. We may have privacy
expectations from DoH.
i have excellent privacy expectations from DoT, which is in fact DNS.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/ma
We have no privacy expectations from DNS. We may have privacy
expectations from DoH.
On Mon, Aug 20, 2018 at 10:36 PM, Paul Ebersman
wrote:
> mellon> The rest of what you said is nice, but "we have to balance
> mellon> theoretical risk versus sane and widespread deployment" is a
> mellon> stat
Marek Vavruša wrote:
...
I'm still not sure that IETF should define the provider of trust, as
the trust is relative. But you're right Ted, it should definitely be
at written down andformalized if we want to move forward.
I have to compose my thoughts on this first. I'll try next weekend if I
On Mon, Aug 20, 2018 at 7:31 PM, Ted Lemon wrote:
> This is why we need to actually think about trust and not just handwave.
> There are a number of serious misconceptions in what you've said, Paul.
I'm still not sure that IETF should define the provider of trust, as
the trust is relative.
But yo
Tom Pusateri wrote:
Come to think of it, DNSSEC validation in the stub resolver or browser
is really a place DoH could shine. Instead of all the round trips
required for validating up (down) the chain, the webserver could package
up all those validated records and push them so the client/stub
pusateri> Come to think of it, DNSSEC validation in the stub resolver or
pusateri> browser is really a place DoH could shine. Instead of all the
pusateri> round trips required for validating up (down) the chain, the
pusateri> webserver could package up all those validated records and
pusateri> push
Tom Pusateri wrote:
On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote:
if DOH is widely used by criminals, botnets, and malware to bypass
perimeter security policy, then there will be a big problem and we
will be solving it for many years to come, even if the browser is
the only thing using it
Ted Lemon wrote:
You're talking about devices over which you have no control. So how
does it make a difference where the attack vector is on the device?
Why is DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS?
i'm glad you asked. operating systems, web browsers, and endpoint
secu
Come to think of it, DNSSEC validation in the stub resolver or browser is
really a place DoH could shine. Instead of all the round trips required for
validating up (down) the chain, the webserver could package up all those
validated records and push them so the client/stub could do the validatio
I agree. We should write down the advice that we think users and
implementors of DoH need. :)
On Mon, Aug 20, 2018 at 10:31 PM, Tom Pusateri wrote:
> Sure. My point was that there could be legitimate uses of DoH.
>
> You have to move DNSSEC validation from the resolver to the client in
> orde
Sure. My point was that there could be legitimate uses of DoH.
You have to move DNSSEC validation from the resolver to the client in order to
really validate the answers if you can’t trust the resolver.
Tom
> On Aug 20, 2018, at 10:28 PM, Ted Lemon wrote:
>
> Of course, the question is, how
This is why we need to actually think about trust and not just handwave.
There are a number of serious misconceptions in what you've said, Paul.
DHCP _is_ worse than TOFU, because there is an opportunity for attack at
every lease renewal, not just the first time you ever talk to a particular
DHCP
Of course, the question is, how does the consumer of that data decide what
is okay and what's not? We can't just say that the server has to behave
correctly: someone has to enforce it.
On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri wrote:
>
>
> > On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote
ebersman> That may be the consensus at the IETF but it's not even close
ebersman> the consensus with ISPs, nor large enterprise. That seems to
ebersman> cover most of the eyeball/consumer... DHCP is still how much
ebersman> of the world gets connected and that hasn't changed in decades.
pusateri>
You're talking about devices over which you have no control. So how does
it make a difference where the attack vector is on the device? Why is
DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS?
On Mon, Aug 20, 2018 at 7:47 PM Paul Vixie wrote:
>
>
> Ted Lemon wrote:
> > I think that
> On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote:
>
>
>
> Tom Pusateri wrote:
>> ... I don’t know if it’s generally accepted that DoH will replace
>> UDP/53 or DoT in the stub resolver or DoH will just end up in the
>> browsers as a way to speed up web pages. But if DoH stays in the
>> browse
Tom Pusateri wrote:
... I don’t know if it’s generally accepted that DoH will replace
UDP/53 or DoT in the stub resolver or DoH will just end up in the
browsers as a way to speed up web pages. But if DoH stays in the
browser and DoT is tried and used on all DNS servers, there’s not a
problem t
> On Aug 20, 2018, at 9:40 PM, Paul Ebersman wrote:
>
> pusateri> Another point I remember most clearly is that DHCP has fallen
> pusateri> out of favor for communicating all but the most minimal
> pusateri> network bootstrap configuration information. There was general
> pusateri> agreement in
On Mon, Aug 20, 2018 at 6:58 PM, Paul Vixie wrote:
>
>
> Tom Pusateri wrote:
>
>>
>> One more point (from the Android crowd) was that they are going to try
>> to connect to the DNS server’s IP address using port 853 using DoT at
>> the same time they are trying to resolve names over port 53 w
Paul Ebersman wrote:
pusateri> Another point I remember most clearly is that DHCP has fallen
pusateri> out of favor for communicating all but the most minimal
pusateri> network bootstrap configuration information. There was general
pusateri> agreement in the room that you only should use D
Tom Pusateri wrote:
One more point (from the Android crowd) was that they are going to try
to connect to the DNS server’s IP address using port 853 using DoT at
the same time they are trying to resolve names over port 53 with UDP. If
they’re able to make a DoT connection, they’ll use it.
pusateri> Another point I remember most clearly is that DHCP has fallen
pusateri> out of favor for communicating all but the most minimal
pusateri> network bootstrap configuration information. There was general
pusateri> agreement in the room that you only should use DHCP in IPv4
pusateri> for addr
> On Aug 20, 2018, at 9:11 PM, Paul Hoffman wrote:
>
> On 20 Aug 2018, at 17:47, Tom Pusateri wrote:
>
>>> On Aug 20, 2018, at 12:42 PM, Tony Finch wrote:
>>>
>>> Marek Vavruša wrote:
https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt
>>>
>>> This is
On 20 Aug 2018, at 17:47, Tom Pusateri wrote:
On Aug 20, 2018, at 12:42 PM, Tony Finch wrote:
Marek Vavruša wrote:
https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
This is interesting to me because I want to support DoTH on my campus
resolvers.
Regarding DoH
> On Aug 20, 2018, at 12:42 PM, Tony Finch wrote:
>
> Marek Vavruša wrote:
>>
>> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt
>
> This is interesting to me because I want to support DoTH on my campus
> resolvers.
>
> Regarding DoH, the DHCP option ought to
Ted Lemon wrote:
I think that you are whistling past the graveyard. If your firewall
allows HTTPS without a proxy, then everything that DoH allows is already
possible, and is probably already being done, because it's so obvious.
nope. the control plane stops at my doorstep, and there is no
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Terminology
Authors : Paul Hoffman
Andrew Sullivan
On 8/20/18 11:22 AM, Adam Roach wrote:
On 8/20/18 6:39 AM, Sebastiaan Deckers wrote:
> Action: Adam Roach will set up a mailing list.
Where? (With apologies for the cross post.)
Apologies -- this fell between the cracks. I have a request in to
create the list now, and will respond to this
I think that you are whistling past the graveyard. If your firewall
allows HTTPS without a proxy, then everything that DoH allows is already
possible, and is probably already being done, because it's so obvious.
If you disagree with me about this (and I can think of a few reasons why
you might) t
Ted Lemon wrote:
I think HTTPS was pretty hostile to local network policy. Indeed,
there was a big argument about that in the TLS working group over the
past few IETFs. If you don't want people to use DoH, there's an easy
solution, which you already need to use regardless: you have to
Andrew Sullivan wrote:
I guess, therefore, I want to ask whether long-standing assumptions
about the DNS are still true:
• Is the stub::full-service resolver::auth server model just over?
no.
• Do we think resolution context needs signal? If so, how?
yes. DTLS or DOT or
On Mon, Aug 20, 2018 at 1:53 PM, Paul Vixie wrote:
>
> Preventing user behavior tracking seems like a pretty valid use case.
>>
>
> it would be, if it was cheap to block. that is, on my network, under my
> rules, user behavior tracking may be my policy. a user who wants to avoid
> that tracking sh
Ted Lemon wrote:
On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie mailto:p...@redbarn.org>> wrote:
so, their network, but not their rules? when spammers used to tell
me that sending spam wasn't illegal and i had to accept it, i
blackholed them and said, my network, my rules. who has w
Dear colleagues,
Several meetings ago, I was at the mic complaining about various
incremental changes to the DNS architecture and how we didn't seem to
be thinking holistically about the matter. I think it was in response
to something Ray Bellis said, and Ray quite correctly challenged me to
put
On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie wrote:
>
> Il 20 agosto 2018 alle 17.55 Ted Lemon ha
>>> scritto:
>>>
>>> I am entirely within my rights to use DoH whether the network
>>> operator likes it or not.
>>>
>>
> so, their network, but not their rules? when spammers used to tell me that
>
Il 20 agosto 2018 alle 17.55 Ted Lemon ha
scritto:
I am entirely within my rights to use DoH whether the network
operator likes it or not.
so, their network, but not their rules? when spammers used to tell me
that sending spam wasn't illegal and i had to accept it, i blackholed
them and s
On Mon, Aug 20, 2018 at 12:41 PM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
> Can you substantiate this statement with data / details? Because I only
> know cases in which:
> a) ISPs filter out content on behalf of the local government due to legal
> requirements/court orders;
>
I am going to echo my original comment on the draft as it may have been
lost in this long thread and it will make sense to keep this close to
related convo.
```
As for feedback on the draft options.
- Section 2.3: Why DoH has no option data? The IP from the DNS recursive
name server option merely
Marek Vavruša wrote:
>
> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
This is interesting to me because I want to support DoTH on my campus
resolvers.
Regarding DoT, it seems to me that a super simple way for the client to
be able to authenticate the server woul
> Il 20 agosto 2018 alle 17.55 Ted Lemon ha scritto:
>
> I am entirely within my rights to use DoH whether the network operator likes
> it or not. It is not illegal for me to do so, and if I did so, it would not
> be so that I could violate the law—it would be so that I could protect my
>
In article you write:
>What ZONEMD would provide is a method of validation of the non-authoritative
>A/ (glue) for the TLD itself.
No, assuming that the ZONEMD is signed, it just tells you that your
copy of the zone has the same glue as the one the zone's publisher
signed. As others have no
On 8/20/18 6:39 AM, Sebastiaan Deckers wrote:
> Action: Adam Roach will set up a mailing list.
Where? (With apologies for the cross post.)
Apologies -- this fell between the cracks. I have a request in to create
the list now, and will respond to this message with further information
when i
On Mon, 20 Aug 2018, Paul Vixie wrote:
Joe Abley wrote:
These are the same use-case, just viewed with different bias.
so, DoH's use cases all involve either violating the law, or violating the
network operator's security policy? egads, i hope not. the ietf can't be seen
backing someth
Paul, it's really not helpful to do this kind of reductio ad absurdum.
You are assuming that all networks operators have a security policy which
they have a right to enforce on the end user. In some cases this is
true. In most cases it is false. E.g., the network to which I am
currently conn
On Aug 20, 2018, at 11:49, Paul Vixie wrote:
> Joe Abley wrote:
> ...
>>
>> These are the same use-case, just viewed with different bias.
>>
>
> so, DoH's use cases all involve either violating the law, or violating the
> network operator's security policy?
I don't know how you managed to re
Joe Abley wrote:
These are the same use-case, just viewed with different bias.
so, DoH's use cases all involve either violating the law, or violating
the network operator's security policy? egads, i hope not. the ietf
can't be seen backing something that has _no_ legitimate purpose.
On Aug 20, 2018, at 07:48, Vittorio Bertola
wrote:
>> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto:
>> And Jason, you missed a threat model, which is users who want to bypass
>> their ISP's resolver.
>
> I think that there should be a lot more attention to this "use case" in this
> di
On Mon, 20 Aug 2018, Brian Dickson wrote:
Those zones would have a signed ZONEMD but no DS record leading to a
validated path anyway, so those are lost without an external (from
DNSSEC) PKI which falls very far outside the scope of ZONEMD.
Paul
What Shumon was referring to is the actual TLD z
Sent from my iPhone
> On Aug 20, 2018, at 10:57 AM, Paul Wouters wrote:
>
>> On Mon, 20 Aug 2018, Shumon Huque wrote:
>>
>> On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters wrote:
>>
>> When using DNSSEC, the resolver should follow the glue and then perform
>> a query at the child zon
On Mon, 20 Aug 2018, Shumon Huque wrote:
On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters wrote:
When using DNSSEC, the resolver should follow the glue and then perform
a query at the child zone to confirm the glue data. In unbound.conf
terms this is called harden-glue: yes
I h
On Mon, Aug 20, 2018 at 9:53 AM Bob Harold wrote:
>
> On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters wrote:
>
>>
>> When using DNSSEC, the resolver should follow the glue and then perform
>> a query at the child zone to confirm the glue data. In unbound.conf
>> terms this is called harden-glue: ye
On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters wrote:
> On Mon, 13 Aug 2018, Brian Dickson wrote:
>
> > Subject: Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02
>
> > IF (big if, with the how/when/where etc kept as a separate discussion)
> an attacker manages to modify glue (for example, p
> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto:
> And Jason, you missed a threat model, which is users who want to bypass their
> ISP's resolver.
I think that there should be a lot more attention to this "use case" in this
discussion. It seems to me that the designers of DoH have in thei
Thank you for sharing these notes.
> Action: Adam Roach will set up a mailing list.
Where? (With apologies for the cross post.)
On Wed, Jul 18, 2018 at 7:43 AM Shane Kerr
wrote:
> All,
>
> I took some random notes at the meeting. Apologies for any errors or
> misstatements.
>
> Cheers,
>
> --
63 matches
Mail list logo
