Re: [DNSOP] [Ext] draft-sah-resolver-information-01 and draft-sah-resinfo-doh-00

Paul Hoffman <paul.hoffman@icann.org> Fri, 24 May 2019 01:11 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C271201D0 for <dnsop@ietfa.amsl.com>; Thu, 23 May 2019 18:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 zh3Hi04fgV85 for <dnsop@ietfa.amsl.com>; Thu, 23 May 2019 18:11:08 -0700 (PDT)
Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583C1120157 for <dnsop@ietf.org>; Thu, 23 May 2019 18:11:08 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 23 May 2019 18:11:06 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 23 May 2019 18:11:06 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: John Levine <johnl@taugh.com>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] draft-sah-resolver-information-01 and draft-sah-resinfo-doh-00
Thread-Index: AQHVEc2PNfhaShCERE+7LkIU0urKBw==
Date: Fri, 24 May 2019 01:11:05 +0000
Message-ID: <126BA26C-A0AF-438B-8D72-8D0CDFA56FB6@icann.org>
References: <20190523022101.27EE520146D68D@ary.qy>
In-Reply-To: <20190523022101.27EE520146D68D@ary.qy>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0FA3FC8A05655F43A342CFFD22927A9D@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lolM-ixODTJu-LRQX5nfqLrh2k4>
Subject: Re: [DNSOP] [Ext] draft-sah-resolver-information-01 and draft-sah-resinfo-doh-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2019 01:11:10 -0000

On May 22, 2019, at 7:21 PM, John Levine <johnl@taugh.com> wrote:

> As a passive-aggressive DNS manager, I can put RESINFO records
> anywhere I want, including in my rDNS zones.  I can even sign them.
> If a stub does a RESINFO lookup for a record that actually exists,
> what's the cache supposed to do?  

Cache them. They're no different than any other DNS record.

> How can a stub tell a RESINFO
> generated by a RESINFO-aware cache from one passed through a non-aware
> cache?

They cannot.

>  Does it matter?  

No.

> Presumably if I can put records in the rDNS I
> have some connection with whoever is using the address space.

Exactly.

> Bonus question: what is the stub supposed to do about DNSSEC?  The
> record passed through the non-aware is more likely to have valid
> DNSSEC than one inserted by the aware cache.

A validating stub would, well, validate. Again, these are no different than any other DNS record.

> For the issue of validating the certificate on a DoT or DoH server, how
> about this kludge: the client contacts the server by IP address, the
> server returns a certificate.  If it has an IP address and it matches,
> swell, you're done. If it has a domain name, do a DNSSEC validated A
> or AAAA lookup, and if you get an answer with the IP of the server,
> it's OK.  If it has multiple domain names, maybe look them all up
> or maybe don't do that.

That is possible, but outside the scope of this document. That is, the same would be true for *any* HTTPS client that gets a certificate with an IP address in the certificate but not a name that it likes.

> This can work even for servers in RFC 1918 space, since the IP address
> isn't used to contact the cache, only to confirm it's the right one.
> We Let's Encrypt fans can use DNS validation for the certificate, no
> need for the CA to contact the cache either.  This potentially leaks
> info about the location of the cache to anyone who can observe the
> traffic, but usually if there's an observer. it is in the cache itself
> so how much of a problem would that be?

Agree.

> After two minutes of thought I don't see any obvious security holes,
> but it's possible I'm missing something.  It works for DoH and DoT on
> 8.8.8.8 and 8.8.4.4 now.  It almost works on 9.9.9.9 except that the
> cert says *.quad9.net and the hostname is dns.quad9.net.

Those are implementation issues.

--Paul Hoffman