IETF Logo Mail Archive

Re: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)

Paul Hoffman <paul.hoffman@icann.org> Tue, 03 August 2021 21:20 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2993A3351 for <dns-privacy@ietfa.amsl.com>; Tue, 3 Aug 2021 14:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 PbmabjuL1p9z for <dns-privacy@ietfa.amsl.com>; Tue, 3 Aug 2021 14:20:04 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DE33A3354 for <dns-privacy@ietf.org>; Tue, 3 Aug 2021 14:20:04 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 173LK0mB010317 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Aug 2021 21:20:00 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.15; Tue, 3 Aug 2021 14:19:59 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.015; Tue, 3 Aug 2021 14:19:59 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc@google.com>
CC: DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)
Thread-Index: AQHXiKt31pbit0kKK0qWM0bK4Y868ativqEA
Date: Tue, 03 Aug 2021 21:19:59 +0000
Message-ID: <66A4FCE3-A07A-4177-A596-17B660FB3535@icann.org>
References: <CABcZeBNRZsyjd-M_hKOwxdqY=Y7oZs5-d4waqPHb9gO-GJNV+Q@mail.gmail.com> <8b2ac283-614e-40d2-b6bf-5e67d5324aaa@www.fastmail.com> <CABcZeBM+rBLgUs+xzyhTOjCFuPdjUDPDMeFL6CAXanDaicC+Pg@mail.gmail.com> <CAHbrMsA3ROoeeDXm_HpXP73uFjVrEQUycQ0OR0e6JE0hCoS1sw@mail.gmail.com> <5EEBC284-71B3-4308-B5C6-AF3847A6ED36@icann.org> <CAHbrMsCN9N=sV2xtc5b9QFeSSCsr65wXEEZ+d6DSTNbRxRt8GQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCN9N=sV2xtc5b9QFeSSCsr65wXEEZ+d6DSTNbRxRt8GQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_05FDB80D-6DA5-4DDD-8726-462CB1965C48"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-03_05:2021-08-03, 2021-08-03 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/F3Q3kCxV3lntozsvHteMLhQ-MPE>
Subject: Re: [dns-privacy] [Ext] Intermediate proposal (what I was saying at the mic)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Aug 2021 21:20:10 -0000

On Aug 3, 2021, at 2:06 PM, Ben Schwartz <bemasc@google.com> wrote:
> 
> On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
>> If the WG is going to go to DS in the parent to have a signed signaling response, it would make sense that the signal in the child have an identical format. If we go with that, I'd rather see CDS be used in the child instead of SVCB.
>> 
> I disagree.  CDS is explicitly a signal from the Child to the Parent.  

Yes, exactly. This is the best way to get those DS records in the parent.

> It's literally in the name of the RR type.  I would not want all the resolvers in the world to be reading CDS records as part of the iterative resolution process.

Why is "all the resolvers in the world to be reading" an SVCB record better?

--Paul Hoffman

v2.23.0 | Report a Bug | By Email