Re: [Add] Resolver Information Discussion

Vittorio Bertola <vittorio.bertola@open-xchange.com> Fri, 06 May 2022 10:40 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
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 A3338C1594B1 for <add@ietfa.amsl.com>; Fri, 6 May 2022 03:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhzbRb5mMbDz for <add@ietfa.amsl.com>; Fri, 6 May 2022 03:39:57 -0700 (PDT)
Received: from mx3.open-xchange.com (mx3.open-xchange.com [87.191.57.183]) (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 5CC8FC14F738 for <add@ietf.org>; Fri, 6 May 2022 03:39:57 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 1A2CA6A0DA; Fri, 6 May 2022 12:39:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1651833594; bh=euz3zCEQUPBR3dNR9hWG9Z+7g2IgPOd7Jgh8k0vUEmg=; h=Date:From:To:In-Reply-To:References:Subject:From; b=iVFMf8zbFyVjYHY3xuownpqkXSJxoaquDwpHY0mMXRkS3zCHPei98PWW7sKq94/it JmbgySPI8wvl1CPM2332+NFquhYcm3sZMsDJFMvU6Nk0nQ6tix+I65h7Fe8A4+lUxE CAZ7lnRr6Q7S78IC9zSkrCa6U2H73crmmVhQ849bW69G3jilwZD5/zwLlJEoMcTjrS wPbOgb1r98U+lOS+yHosJ2XWeRwhRYAmvtobXd1SnQ4N350im+TvnT4fIQ0MZzUIwh AOGhwaqfvLszsKcZgNQOohrqWh1moI1yGzVd9JPvj2apru77YlKeGnIfMuGsbAIjAG tUqT0AOc6LHfw==
Received: from appsuite-gw2.open-xchange.com ([10.20.28.82]) by imap.open-xchange.com with ESMTPSA id kkRYBPr6dGL7JgAA3c6Kzw (envelope-from <vittorio.bertola@open-xchange.com>); Fri, 06 May 2022 12:39:54 +0200
Date: Fri, 06 May 2022 12:39:54 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Message-ID: <4116490.55759.1651833594019@appsuite-gw2.open-xchange.com>
In-Reply-To: <BYAPR11MB3111AFACE8277DF5C60782AEEAC29@BYAPR11MB3111.namprd11.prod.outlook.com>
References: <BYAPR11MB3111AFACE8277DF5C60782AEEAC29@BYAPR11MB3111.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_55757_185214127.1651833594007"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev14
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/JQbyeSCxNX90SIa6x5xKrhb2qSM>
Subject: Re: [Add] Resolver Information Discussion
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2022 10:40:01 -0000

> Il 05/05/2022 20:32 Deen, Glenn <glenn_deen=40comcast.com@dmarc.ietf.org> ha scritto:
> 
> 
> Has the base design gone in a different direction than originally considered to the point where extended information about resolvers is no longer of interest to clients? 
> 
> Is Resolver Information an area that is still of interest to the group?
> 
The desire to address this topic was prompted by the fact that early implementations of encrypted DNS put policy requirements on a resolver's behaviour before accepting to use it, so it would be necessary for the local resolver to state its policy to the browser so that it could make a decision. Later implementations indeed went in a different direction, i.e. using DDR to upgrade the existing resolver no matter which policies were in place, and perhaps in the future using DNR to get the local encrypted resolver from the network.

However the original approach is still there in at least one browser (Firefox) and it is unclear what they plan for the future. It seems to me that they would be the primary consumers of this information, but I have no idea if they would be interested in evolving their TRR model to an open, discovery-based mechanism or not. Indeed, they'd have the problem of deciding how much one can trust a resolver's self declaration of policies.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy