Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)

Vittorio Bertola <vittorio.bertola@open-xchange.com> Tue, 15 September 2020 12:43 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 E25253A0F7C for <add@ietfa.amsl.com>; Tue, 15 Sep 2020 05:43:38 -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=unavailable 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 CoFhzt3rX6mz for <add@ietfa.amsl.com>; Tue, 15 Sep 2020 05:43:37 -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 9E4BC3A0FDE for <add@ietf.org>; Tue, 15 Sep 2020 05:43:33 -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 065F96A275; Tue, 15 Sep 2020 14:43:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1600173810; bh=p6+COnPbDCyFXOdrMOtZPkxgo5IQR41lY/SZB1FbKxA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ZNJ2Cd+uc9n39+5noBo1bif7Y1T7h9JyQ4CMAj9KqebWfzSGIeTd1+wGM0rBFrlBK mendQOocKhCxvNoH5eez29DE9DO1KCImtZX2o50+7IQExxUDeVBRRU6C/0rXggLktX GdNtSmeKR7f8sotmryrBiLE9XPaN2wA2aA5+DukAfPvBD4LcYLLBsvfw5hW4U0lnYE vVgsSusuJY+b2b9LdRkZx+oxSu4vP9Q5S+CtIUudD/vpgspxlZNXDYTrGR5+cl7juC ypkrjoCWCGEF5ptbm+DP45vncRr285LNvEZAoAA5XtOB8uqpZIQEo9RnDubl3D/w4t tTTnAgqFh6RzA==
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 EC24E3C03E3; Tue, 15 Sep 2020 14:43:29 +0200 (CEST)
Date: Tue, 15 Sep 2020 14:43:29 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>
Cc: ADD Mailing list <add@ietf.org>, "Deen, Glenn" <Glenn_Deen@comcast.com>
Message-ID: <1557871922.1625.1600173809868@appsuite-gw2.open-xchange.com>
In-Reply-To: <A332081D-69AE-45F8-9E61-6ACA3D071C1E@apple.com>
References: <CABcZeBPuq86Fj0VYQ+1j8ZWo+4BT1bDJGfnRmi82oUc8Xns=PQ@mail.gmail.com> <A332081D-69AE-45F8-9E61-6ACA3D071C1E@apple.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1623_748789170.1600173809824"
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/CgaU3Ll8AkZrYxS-bt3xUp10rWE>
Subject: Re: [Add] Authentication Sub-topics for Tuesday Interim (homework for Tuesday's meeting)
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: Tue, 15 Sep 2020 12:43:39 -0000

>     Il 15/09/2020 04:48 Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> ha scritto:
> 
>     What might not be possible, on the other hand, is to usefully authenticate a deployment model where the resolver or forwarder is some private/local address that’s running on a router itself–unless this is a managed network or managed device that has some out of band mechanism to trust or configure resolvers (at which point we don’t need discovery mechanisms). I think the case of trying to find an equivalent and trusted resolver to the one running on 10.0.0.1 on my router ends up being indistinguishable from an attack scenario.
> 
What would be the security problem if 10.0.0.1 via Do53 received a "resolver discovery" query, forwarded it to the main resolver, received a DNSSEC-signed response, forwarded you the response, and the response included both a DoH URI and a TLSA record that the DoH resolver's certificate has to match?

>     But these scenarios likely aren’t worth solving this way anyhow—if the DoH server isn’t on my router itself, but hosted in the ISP network, the network would do better to provision the address of that ISP server instead of a local address;
> 
It has been explained that this would as a minimum require firmware/configuration upgrades on millions of CPEs, and as a maximum be impossible because CPEs have the forwarding configuration hardwired or are out of support by the manufacturer. Perhaps in 5-10 years, not now.

>     and if I really have a DoH server running locally, the router would presumably be able to upgrade to be able to provision the DoH information directly in DHCP/RA/PvD.  
> 
A DHCP extension to advertise a DoH URI was proposed at an IETF meeting over a year ago. It was rejected as too insecure, but if that assessment changes, of course it could be considered.

--

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