IETF Logo Mail Archive

Re: [Add] [EXTERNAL] My single use case

Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 14 September 2020 16:56 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 1ACB43A0C62 for <add@ietfa.amsl.com>; Mon, 14 Sep 2020 09:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=open-xchange.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 M1_wj1t-_ulL for <add@ietfa.amsl.com>; Mon, 14 Sep 2020 09:56:00 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 3AFCB3A0BF6 for <add@ietf.org>; Mon, 14 Sep 2020 09:55:59 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (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 ESMTPS id CAC6D6A25F; Mon, 14 Sep 2020 18:55:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1600102557; bh=2BAQ8zjCO4mdaGU9991zvRr6KAL2WLO7CDzREVrQA4w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=9KfA/ADXev9AjUai1odvPAK4Cizi2V4b0J6fA4U/6cDO0VjbTHBX1sC9v574GbYuU w7X2/zpOhBXioRojC8yoXPrZ43oeihojXrvXM/y0SFkE8dUQRIcPF5hX0elnKJzGRi FV2gg5I7VcwnvZ3ye4cbG/1f8IttODqARuC9vRGuY05j63TGncVlSlcQQFoHpm4weX 7XBiDC8eBqrGSMp25/+P5Db2QoJqRgOzvDWMskPSgT03bhmZLyrquVtthquBaQpTvl hWJl8DL85y4OBKI3cMK+DFRGmxP3rSOOzLITQmF7LOFHMVnzC7sVIBDL+dLFd5GzAW Lh3QncQMZj5aQ==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id BBB463C0386; Mon, 14 Sep 2020 18:55:57 +0200 (CEST)
Date: Mon, 14 Sep 2020 18:55:57 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: "add@ietf.org" <add@ietf.org>
Message-ID: <2114958553.1165.1600102557668@appsuite-gw2.open-xchange.com>
In-Reply-To: <CADZyTkmeYXNiL1yt1FUdKRS=mAmde4gkbu7wkn+HBFEPcdV-4g@mail.gmail.com>
References: <d4bd287a-d2ce-40cd-b635-4f74efbc77f6@www.fastmail.com> <DM6PR00MB07815F5B6F43F63DB23485A7FA271@DM6PR00MB0781.namprd00.prod.outlook.com> <CAHbrMsBduVj7fzutp9x7rYpXo6wLUK7-Pe4VvDHaF45dj==PYQ@mail.gmail.com> <CADZyTkmeYXNiL1yt1FUdKRS=mAmde4gkbu7wkn+HBFEPcdV-4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1163_104210992.1600102557637"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev8
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/j4jgZX5L3KaSGYGgLWt09h2Tcpg>
Subject: Re: [Add] [EXTERNAL] My single use case
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 14 Sep 2020 16:56:02 -0000

>     Il 14/09/2020 17:54 Daniel Migault <mglt.ietf@gmail.com> ha scritto:
> 
>     <mglt>
>     You could also validate (cryptographically) the correspondence between the encrypted DNS and the Do53, but in essence the confidence of the authentication will remain with a similar level of the Do53. The discovery could also provide some proofs that the resolver is associated to your ISP or the entity providing you the connectivity with a reasonable level of confidence.   
>     </mglt> 
> 
For the use case of "same-provider auto-upgrade" as currently implemented, being sure that a given DoH resolver really corresponds to the currently active Do53 system resolver would suffice, even if you were not able to authenticate who is actually operating those two resolvers. (This is different from "same-provider auto-upgrade only for selected trusted providers", which requires a hardcoded list of trusted providers in the client, but as far as I understand the objective is to get rid of hardcoded lists altogether.)

For this purpose, we could simply use a TLSA record. The Do53 resolver would provide a TLSA record together with the RESINFO/TXT/whatever response to the discovery query, and when establishing the DoH connection, the client would validate the certificate against the TLSA record. If you add DNSSEC to the Do53 communication, this should be a secure process. Could this work?

(Glenn - perhaps this is a specific topic for discussion tomorrow: authenticating the relationship between a Do53 and a DoH resolver without necessarily identifying their operator, i.e. breaking your #3 topic into two separate parts)

--

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

v2.23.0 | Report a Bug | By Email