Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B32C3A13E7 for ; Mon, 6 Jul 2020 05:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA4HWLQQD_6g for ; Mon, 6 Jul 2020 05:18:20 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B143A13E3 for ; Mon, 6 Jul 2020 05:18:20 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id o5so38963548iow.8 for ; Mon, 06 Jul 2020 05:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bZyaUZ7fhsxcbXNVtXgcO7XryW9i2QssXg48dwnQ86U=; b=ckgs1Th+48Tr03iBF5nmYcBvxIICo5R5L2H+PdW/nzDJbHAISZ3gO6Mr3riknT1yNC 58ogeF6hNW6m3zPXvZRRtLLjf4pUB9Y3PYMRsTY9p8947gQR4SiqQ8mLynknY8yX1VCm S//HI4Y062K/KPbFbNuBjPDkaiHiB9/n2gFv4tKOjUXxsNN8wbR282H3m9cMwVs52IOn l5ihXUzZ+KlDu6l2Po+DlcbFWtfETa2ekaa6iuExKmY8jTGqM1rt6y6R1GtDQ/NR0Zho /44m4SoLPcse/I398Lv+ykhZWJRhjCqh/lkm5PeHFS4FRSijTGjA4hpGwwy3T/Rh7yWy mpjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bZyaUZ7fhsxcbXNVtXgcO7XryW9i2QssXg48dwnQ86U=; b=oibdpeuwRPUmm4SC8XOzrE9lSSUS5NVpr0w7bTHCAyANayH9V2wKmPvPKX5NHcHDsb d+NaAVwAK+fmgzsrKJzIzLnbMmqwIduDD0pz0OkIyd3CkXQ7civQhtY9VDwU4a6wXXQL qXHIahWiRd5RqhHdihSre0XRNY9Mhm4/du+nWVpHpBogHUwaPWIucTOKE67Nl6JknJiw 9+DRxaZhnYcogLEgSLfX/ZIcN+Kuai2ijM0HPC0qRid5vpY5kb7RbBp2tSNgWT4opDzC 1cOx/N3BNaXl9m7nDTXiDddwKrMKfAmZE3SViNwFgXoMqPelBSWeEvJc7sK29C6FyRXB KtkQ== X-Gm-Message-State: AOAM533JjUQRCWJFBgcXTs+tBEp8xrvc3oq2vzIokpqldfO5nSKBqjMb pDHAJ5m2TOfJT9BVFnR3TxfORKMhHzqvE6qGYMle7ytR X-Google-Smtp-Source: ABdhPJzptm554pU12MHAe1uoZfg3lv8Afo6nTc+AUL9s3bl4D71mEv10VJO8Xh09hyYMljq/8pag1VNMP1l6qHpXNjs= X-Received: by 2002:a02:5443:: with SMTP id t64mr53433200jaa.100.1594037899856; Mon, 06 Jul 2020 05:18:19 -0700 (PDT) MIME-Version: 1.0 References: <1AB2782B-87C0-4991-8703-AE2C98411AFC@apple.com> <2013869.BjYadG0qc2@linux-9daj> In-Reply-To: From: tirumal reddy Date: Mon, 6 Jul 2020 17:48:07 +0530 Message-ID: To: Puneet Sood Cc: Eric Rescorla , ADD Mailing list , Paul Vixie , Tommy Pauly Content-Type: multipart/alternative; boundary="000000000000c7910e05a9c4def5" Archived-At: Subject: Re: [Add] Draft Posting: CNAME Discovery of Local DoH Resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 12:18:24 -0000 --000000000000c7910e05a9c4def5 Content-Type: text/plain; charset="UTF-8" On Sat, 4 Jul 2020 at 06:09, Puneet Sood wrote: > On Fri, Jun 26, 2020 at 8:48 PM Eric Rescorla wrote: > > > > > > > > On Fri, Jun 26, 2020 at 5:04 PM Paul Vixie wrote: > >> > >> On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote: > >> > ... Other than inelegance, what's problematic about the CNAME > approach? > >> > >> inelegance is permanent, accretive, and earns compound interest. we > ought not > >> dismiss inelegance as the basis for reluctance. inelegance is not > inevitable > >> nor is it automatically acceptable. > >> > >> > ... > >> > > >> > The scenario you seem to be interested in is one in which the user > joins > >> > the network and then learns that the associated Do53 resolver > supports DoH > >> > and then connects to it with whatever coordinates that resolver (or > DHCP or > >> > whatever) provides. That clearly is not useful in the 3552 threat > model > >> > which assumes that the attacker entirely controls the network because > the > >> > attacker can just send their own resolver coordinates. That isn't to > say > >> > that there aren't more limited but still realistic threat models > where this > >> > would be useful, but I think you should start by describing those. > >> > >> as we describe them, we should also describe their scale, their age, > and their > >> likely lifespan. the 3552 threat model, while it does use the term > >> 'pervasive', is nowhere near as common as the SASE (secure access > service > >> edge) operations model, nor will it ever be. if apps who want to do > their own > >> DNS treat any DoH failure as an attack, and start an arms race of > spy-vs-spy > >> bypass along the lines of Tor, that's going to feel problematic to any > of us > >> whose privately owned securely operated edge networks have a local-only > DNS > >> policy. > >> > >> RESINFO could probably get better results by using TXT, because of long > tail > >> problems. but ultimately we have to pick a default assumption that we > can act > >> on when secure resolver discovery fails. "OMG it's a 3552 attack" is > not the > >> only interpretation we could think of for this. it's entirely possible > that > >> the most engineering solution to the discovery problem is to fail hard > when > >> the middlebox prevents authenticated policy negotiation, to force > middlebox > >> upgrades. i know that "tough love" is a hard sell, but "assume 3552 > attack" is > >> also a form of tough love. > > > > > > Hi Paul, > > > > I think this response perhaps conflates two somewhat different issues, > > namely CNAME versus authenticated policy propagation. > > > > Ignoring the question of CNAME for the moment, if a device joins a > > network and gets its configuration from that network (e.g., via DHCP), > > then it is trusting that network to provide the configuration. So, the > > question then becomes what benefit is obtained if that network > > supplies a Do[TH] server rather than a Do53 server. In the 3552 model, > > we assume the attacker has complete control of the network and can > > therefore supply its own server, so it's not clear what the security > > benefit is. Conversely, if the network is totally secure and trusted, > > then it's *also* not clear what the security benefit is. > > > > So, if we are to have unauthenticated discovery of Do[TH] servers, > > then we must have some other threat model. For instance we might > > think that the attacker can read all packets but for some reason > > can't impersonate the DHCP server. What I'm saying is that we should > > start by laying out what that threat model is and then we can define > > what, if any, technical measures add security benefit in that threat > > model. That would be true even if we knew that there weren't > > middleboxes which tampered with new record types. > > >From RFC 3552, the threat model for unauthenticated discovery would be > passive attacks described in section 3.2. There is benefit to > upgrading from Do53 to Do[TH] even if the network between the client > and the DHCP server is secure - specifically when the DNS resolver is > further away on the network. This could be because the network > operator is running the DNS resolver further away (e.g. DHCP could be > on the home router for a typical home user) or the DNS resolver > specified by the ISP is operated by a third-party on a different > network. > Home networks are susceptible to both internal (ARP spoofing/poisoning) and external attacks (Evil twin, Dragonblood, Krack). Unfortunately typical home networks use shared WPA-PSK and both WPA2/WPA3 are susceptible to attacks. The attacker can be active or passive. -Tiru > > -Puneet > > > > > > > Two more points, if I may: > > > > 1. Where this interfaces with the question of CNAME versus RESINFO > > is that RESINFO is much more flexible, but (as above) it's not > > clear we can securely make use of this flexibility. > > > > 2. It's worth nothing that there are scenarios where the device > > can get authenticated network configuration (for instance, if > > the device is managed and has had some sort of authentication key > > installed). The comments above do not apply to this scenario > > but rather to the scenario where you have a naive device joining > > a network. > > > > -Ekr > > -- > > 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 > --000000000000c7910e05a9c4def5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 4 Jul 2020 at 06:09, Puneet Sood = <puneets=3D40google.com@d= marc.ietf.org> wrote:
On Fri, Jun 26, 2020 at 8:48 PM Eri= c Rescorla <ekr@rtfm.c= om> wrote:
>
>
>
> On Fri, Jun 26, 2020 at 5:04 PM Paul Vixie <paul@redbarn.org> wrote:
>>
>> On Friday, 26 June 2020 22:08:05 UTC Eric Rescorla wrote:
>> > ... Other than inelegance, what's problematic about the C= NAME approach?
>>
>> inelegance is permanent, accretive, and earns compound interest. w= e ought not
>> dismiss inelegance as the basis for reluctance. inelegance is not = inevitable
>> nor is it automatically acceptable.
>>
>> > ...
>> >
>> > The scenario you seem to be interested in is one in which the= user joins
>> > the network and then learns that the associated Do53 resolver= supports DoH
>> > and then connects to it with whatever coordinates that resolv= er (or DHCP or
>> > whatever) provides. That clearly is not useful in the 3552 th= reat model
>> > which assumes that the attacker entirely controls the network= because the
>> > attacker can just send their own resolver coordinates. That i= sn't to say
>> > that there aren't more limited but still realistic threat= models where this
>> > would be useful, but I think you should start by describing t= hose.
>>
>> as we describe them, we should also describe their scale, their ag= e, and their
>> likely lifespan. the 3552 threat model, while it does use the term=
>> 'pervasive', is nowhere near as common as the SASE (secure= access service
>> edge) operations model, nor will it ever be. if apps who want to d= o their own
>> DNS treat any DoH failure as an attack, and start an arms race of = spy-vs-spy
>> bypass along the lines of Tor, that's going to feel problemati= c to any of us
>> whose privately owned securely operated edge networks have a local= -only DNS
>> policy.
>>
>> RESINFO could probably get better results by using TXT, because of= long tail
>> problems. but ultimately we have to pick a default assumption that= we can act
>> on when secure resolver discovery fails. "OMG it's a 3552= attack" is not the
>> only interpretation we could think of for this. it's entirely = possible that
>> the most engineering solution to the discovery problem is to fail = hard when
>> the middlebox prevents authenticated policy negotiation, to force = middlebox
>> upgrades. i know that "tough love" is a hard sell, but &= quot;assume 3552 attack" is
>> also a form of tough love.
>
>
> Hi Paul,
>
> I think this response perhaps conflates two somewhat different issues,=
> namely CNAME versus authenticated policy propagation.
>
> Ignoring the question of CNAME for the moment, if a device joins a
> network and gets its configuration from that network (e.g., via DHCP),=
> then it is trusting that network to provide the configuration. So, the=
> question then becomes what benefit is obtained if that network
> supplies a Do[TH] server rather than a Do53 server. In the 3552 model,=
> we assume the attacker has complete control of the network and can
> therefore supply its own server, so it's not clear what the securi= ty
> benefit is. Conversely, if the network is totally secure and trusted,<= br> > then it's *also* not clear what the security benefit is.
>
> So, if we are to have unauthenticated discovery of Do[TH] servers,
> then we must have some other threat model. For instance we might
> think that the attacker can read all packets but for some reason
> can't impersonate the DHCP server. What I'm saying is that we = should
> start by laying out what that threat model is and then we can define > what, if any, technical measures add security benefit in that threat > model. That would be true even if we knew that there weren't
> middleboxes which tampered with new record types.

>From RFC 3552, the threat model for unauthenticated discovery would be<= br> passive attacks described in section 3.2. There is benefit to
upgrading from Do53 to Do[TH] even if the network between the client
and the DHCP server is secure - specifically when the DNS resolver is
further away on the network. This could be because the network
operator is running the DNS resolver further away (e.g. DHCP could be
on the home router for a typical home user) or the DNS resolver
specified by the ISP is operated by a third-party on a different
network.

Home networks are susceptible = to both internal (ARP spoofing/poisoning) and external attacks (Evil twin,= =C2=A0Dragonblood, Krack). Unfortunately typical=C2=A0home = networks use shared WPA-PSK and both WPA2/WPA3 are susceptible to attacks. = The attacker can be active or passive.=C2=A0

-Tiru=
=C2=A0

-Puneet

>
>
> Two more points, if I may:
>
> 1. Where this interfaces with the question of CNAME versus RESINFO
> is that RESINFO is much more flexible, but (as above) it's not
> clear we can securely make use of this flexibility.
>
> 2. It's worth nothing that there are scenarios where the device > can get authenticated network configuration (for instance, if
> the device is managed and has had some sort of authentication key
> installed). The comments above do not apply to this scenario
> but rather to the scenario where you have a naive device joining
> a network.
>
> -Ekr
> --
> 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
--000000000000c7910e05a9c4def5--