IETF Logo Mail Archive

Re: [dns-privacy] [Ext] Fwd: Opportunistic encryption between recursive and authoritative servers

Paul Hoffman <paul.hoffman@icann.org> Sat, 12 September 2020 16:33 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 B521A3A0C38 for <dns-privacy@ietfa.amsl.com>; Sat, 12 Sep 2020 09:33:53 -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_HELO_NONE=0.001, SPF_PASS=-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 lqwXmbRwdzAo for <dns-privacy@ietfa.amsl.com>; Sat, 12 Sep 2020 09:33:52 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.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 460543A0C31 for <dns-privacy@ietf.org>; Sat, 12 Sep 2020 09:33:52 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08CGXopx025725 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Sep 2020 16:33:50 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.659.4; Sat, 12 Sep 2020 09:33:49 -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.0659.006; Sat, 12 Sep 2020 09:33:49 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: James <james.ietf@gmail.com>
CC: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Fwd: Opportunistic encryption between recursive and authoritative servers
Thread-Index: AQHWiQdjIq8bxabjBEikBM5DuHJTFallqEQA
Date: Sat, 12 Sep 2020 16:33:48 +0000
Message-ID: <BB6B0FE5-E623-4100-9EFF-A4883403B1B8@icann.org>
References: <BBA7E731-34C9-47C8-B584-7781DD7F4A59@icann.org> <CAO+dDx=Ey=EXU3TWOF6Xydh7y-7okjSGpciWRgHUjdyYauGz0A@mail.gmail.com> <CAO+dDxktjyT6_R-vBkR4rPD6Yb=Tg0ci3wTur0gz7n9FovfHKQ@mail.gmail.com>
In-Reply-To: <CAO+dDxktjyT6_R-vBkR4rPD6Yb=Tg0ci3wTur0gz7n9FovfHKQ@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=_26290C64-0B1E-4287-BF83-DE5A437E914D"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-12_08:2020-09-10, 2020-09-12 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/iNMe-eMvn4_mgpmz1c9rbHdZXg8>
Subject: Re: [dns-privacy] [Ext] Fwd: Opportunistic encryption between recursive and authoritative servers
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Sat, 12 Sep 2020 16:34:02 -0000

On Sep 12, 2020, at 6:19 AM, James <james.ietf@gmail.com> wrote:
> 
> 1. The absence of protocol agility bothers me - whilst I do not think the use case described in this document lends to DoH in particular being suitable, DoQUIC and not-yet-existent protocols could also be applicable.

There is nothing in the current proposal that specifies the protocol that the two sides use. Additional protocol discovery methods can be added; we just didn't have any other desired protocols at this time.

> Is there any reason besides simplicity you didn't consider using the ALPN as identifier?

Simplicity counts. :-) However, if you want to use an ALPN method, this document certainly does nothing to prevent that.

> 2. I disagree on the points around authentication and section 2 could be updated to better encourage adopters to implement matching TLSA records for the certificate they present during the TLS handshake - with a clear statement that recursives are not required to query this record type before TLS negotiation, nor explicitly fail if it mismatches. 

There is no value in opportunistic encryption to use DANE or any other way of authenticating the TLS server. Paul Wouters has said that he does not support encrypting more DNS traffic using opportunistic encryption, but so far has not written up his use case for regular (authenticated) encryption where some DNS lookups would be blocked due to inability to authenticate. Maybe you could write up such a use case and send it to this WG so they can compare use cases?

--Paul Hoffman

v2.23.0 | Report a Bug | By Email