Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

On Tue, 30 Jun 2020 at 18:28, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Tue, Jun 30, 2020 at 2:19 AM Paul Vixie <paul@redbarn.org> wrote:
>
>> On Tuesday, 30 June 2020 09:07:43 UTC Martin Thomson wrote:
>> > Hi Paul,
>> >
>> > On Tue, Jun 30, 2020, at 17:51, Paul Vixie wrote:
>> > > Eric Rescorla wrote on 2020-06-29 20:08:
>> > > > On Mon, Jun 29, 2020 at 8:05 PM Daniel Migault <mglt.ietf@gmail.com
>> > > >
>> > > > <mailto:mglt.ietf@gmail.com>> wrote:
>> > > >     If the lookup takes as input the IP addresses or something
>> provided
>> > > >     by the ISP (like the local resolver IP address), the resulting
>> chain
>> > > >     is likely to be from the ISP. DNSSEC is needed to assert it.
>> > > >
>> > > > Why do you assume that the IP is delivered securely?
>> > >
>> > > because dnssec allows me to verify end-to-end authenticity of
>> > > name/address bindings (and other dns content.)
>> >
>> > DNSSEC allows you to be sure of the veracity of what comes from DNSSEC,
>> but
>> > in this case the IP address didn't come from DNSSEC.  It's not DNS
>> content.
>>
>> i have badly misunderstood.
>>
>> the way i know that the ip address provided by the isp was delivered
>> securely
>> today is because off-net DHCP forgery is hard,
>
>
> Let's start here:
> I agree that off-net DHCP forgery is hard. However, once you assume that
> you are off-path, then Do53 interception is *also* hard. So for this to be
> useful you need an environment in which the attacker is able to attack Do53
> but *not* to attack DHCP. What I'm asking for is for someone to define that
> threat model precisely so that we can design protocols that match it.
>

The various possible attacks in a home network are discussed in
https://tools.ietf.org/html/draft-btw-add-home-06#section-9

-Tiru

>
>
> moving on, what i'd love to have is SDNCP rather than DHCP. S=secure,
>> N=network. because i want to know i'm getting what the operator of the
>> network
>> wants me to get, and because there are other parameters besides RDNS that
>> i
>> care about, such as whether there's a mandatory HTTPS or HTTP/3 proxy i
>> will
>> have to talk to. because, IoT. if DHCP isn't useful because it's not
>> secure,
>> we should stop using it. but before we could do that, we'd have to meet
>> its
>> functionality in another way.
>>
>
>> i realize that i've identified an unmarketable general case which has got
>> to
>> sound like i want to boil the ocean, or boil frogs, or something. but i
>> figure
>> if i don't say something, then after we've consensed around a secure RDNS
>> discovery protocol, and somebody says what about all these other
>> parameters
>> that also have to be set by the network operator and have to be
>> authenticated,
>> we won't know how we got there.
>>
>> i'd like setting up an IoT device to be like bluetooth pairing, only,
>> secure.
>> like, enter a four-digit PIN or something. getting secure RDNS
>> configuration
>> should be like that. right now it's a welcome letter printed by my ISP,
>> and
>> that seems outdated.
>>
>
> This all sounds great. And when it was available, we could also use it to
> indicate which Do[HT] server you ought to use.
>
> The question I am addressing is what we ought to do in the interim.
>
> -Ekr
>
>
>> --
>> Paul
>>
>>
>> --
>> Add mailing list
>> Add@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>