Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted

Mike Bishop <mbishop@evequefou.be> Fri, 24 April 2020 19:16 UTC

Return-Path: <mbishop@evequefou.be>
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 2ED6F3A0860 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 12:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 ICkg3m4ZZG6p for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 12:16:40 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2126.outbound.protection.outlook.com [40.107.243.126]) (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 1EF583A0865 for <add@ietf.org>; Fri, 24 Apr 2020 12:16:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZ1hoxeE4dkNNxAycS+UTTmwJp0PSa+TF8Y2LC2+MLGxReUWOJ5rThQyXFv9mWyOScjBLIJMBS+cprmIaBPsTPKEXggqGLZ6TobVgTGgltVJYIwHmihSVSpwryoM/scQfphms33urHgVekQtwVRBSn4Xv+wDyu+bFOWt0kSjbDSEwtlxavrhhFDNl2KChJWqbWtvrWRILXKMCWC+f2k/KmKyK+PDwttyMLXo6DwF6DnzHrsWH0pycw77wYPjNTavCzUeKv8IGBHblzOWVEvyBxsAY+UjFaDwDRwJyjzW5PzXnBdYSnj9XElhH+GlYy/kQgmMLHbHB0Goj0F1B99J6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6fQyfduq5cRimxwwGrAKqUJ0IWyacZVDZ/GdfNcz1lg=; b=bY92m/g7vw4yrE6goY6Ex4ISVGm3wXWIMQSa3a9So4KUDjT1SHDzsa1Vw+r2AFmNa4sk+sNWo8sEUyYnfoemWINPt7vv2aTQMfWlnd+O23jdn5YNPKFLpENbm5y9RnGuUajJ45amsdDvclvYV4uj2IDqK/1uCle8nQBF0Wr2xzb7FetVziv1RCHbRTv+WSepXWXFDrzsrvCre5GzdHLRrcVgdVJLDODQ3+tYQuFOZDm77Jx/JvQH+/zcQOnZXVQebqEIu1Euz86y+qKnsxvV3PeO78o8/ArmWle7ycjeS5g6KEln1eScnhp/ZftxBP2c4xDY0PNenQcoQMZLUVfKgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6fQyfduq5cRimxwwGrAKqUJ0IWyacZVDZ/GdfNcz1lg=; b=B3MJGPBXNAkeYm9Tq5/qUdjB52mAIEQpQzyuJRMhI5Dce7Yvgh4QdTjarBEb/SlgksmiwW77tc45V8eGatBYLxzQSFiPHgVTZFVE4pjV1L/yWvxrN17EHei5KxjOfPPyF1/pgiLFSJCAkoAIVmaOh6BFs7y80Ebauwe4S9ROoXA=
Received: from CH2PR22MB2086.namprd22.prod.outlook.com (2603:10b6:610:8c::8) by CH2PR22MB1832.namprd22.prod.outlook.com (2603:10b6:610:83::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr 2020 19:16:37 +0000
Received: from CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::5d05:3b25:6510:2a3d]) by CH2PR22MB2086.namprd22.prod.outlook.com ([fe80::5d05:3b25:6510:2a3d%3]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 19:16:37 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Eric Rescorla <ekr@rtfm.com>, Paul Hoffman <paul.hoffman@icann.org>
CC: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>
Thread-Topic: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted
Thread-Index: AQHWGmfVik3Q5xqgsU+By9s+OQW8lKiInpaAgAAEWKA=
Date: Fri, 24 Apr 2020 19:16:37 +0000
Message-ID: <CH2PR22MB208610A6E15C3953EB3EEA58DAD00@CH2PR22MB2086.namprd22.prod.outlook.com>
References: <E1091705-3E44-4284-AFE3-824052FBF5C2@icann.org> <CAHbrMsCdch3XN9r0t1kNGPtQv3ctXBH49QOJOsktHth-2WNEfQ@mail.gmail.com> <57727489-B6E3-40A4-9E72-79EB78AC671C@icann.org> <CABcZeBPwoA9O-sr443Woo3U-HbJGsx5asC8gjwDknxPiT86ZnA@mail.gmail.com>
In-Reply-To: <CABcZeBPwoA9O-sr443Woo3U-HbJGsx5asC8gjwDknxPiT86ZnA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2600:2b00:930c:7701:19c4:8529:2c6c:fb0a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e629ba5e-e444-4d8e-350a-08d7e88402a0
x-ms-traffictypediagnostic: CH2PR22MB1832:
x-microsoft-antispam-prvs: <CH2PR22MB1832A41088B670A64DECD6BEDAD00@CH2PR22MB1832.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03838E948C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR22MB2086.namprd22.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(39830400003)(346002)(376002)(366004)(81156014)(7696005)(53546011)(6506007)(86362001)(8936002)(8676002)(2906002)(52536014)(33656002)(4326008)(9686003)(110136005)(71200400001)(55016002)(316002)(66476007)(66946007)(66446008)(66556008)(64756008)(54906003)(966005)(5660300002)(508600001)(186003)(76116006); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: d9/rgK+v4ImNvNBfeh9e38/kq+g5BEwxckZ87PYppVZ2p8R1VsHLUNCniJtCTUsXtCePnXl7z1nWIHdf0zIMWJBGY1COrnfBAQO5RCqailGLBkjAPl9/gQ0pQoWYga0unx0A7iYn4qC3paDV/K/txoNkqDz2XrwWiK8Z2jqDpm0/P1SRVbMCs99gI9096nSEKf4Uyze12996XE7P/oiIQqO6zhSV9prRyUDjQJh7Shuotea5RuvI8ChwTxeIsWKQLXHr/fio3T38GrKuF7repNItJUnMHf0/cQbbrbuv78pZca8Akfs/7xYGTi/dMT7LzYqhMas+CFUQJuAe9+t0/78+u708o5jT0Fx28zAXq/tlQI1FKd9lTGkWEqHwVBt44Hn4lPE8JXJTjAZ3jQCZph8WkoErNx3LDunZgj3SppYIlSGhiHEqVMNoMzXfnKOSmF/1PFDfdOLrvfZRz1Y8j75+gAd9jWhDlOTTPCphD8zSBaXG08+AVdwghTCwZ/rl77MXeoHFlOnJORoAwY8DfA==
x-ms-exchange-antispam-messagedata: IiuPuBwJ2oJq08RJOmYmmDah6g9NHKTdVj22CYfl7bnUtsf5oc1epJTkW6CLvUsQTPgRpYv7G8e5xdTw52P1ZSlYh/DtkVXqxY1p1ECf/QjFBglhKbCKQdXseDuyjakn5ZkK8MXaXQgX1eWL2g6UnhgFFXNUXCorpi2x671hDULqvzC5XKg1iHHlBwCnq0JgwN4av7kOKTEKwoctF0rvCUjhwJObffukAwKrX2esP/mQmU8nfbAZsZtlvBmErklJguQr2OUKKNrr5UcLRGAs/prSC75V3IV3fGjpUn/ajjlw4SUM1HJYWDcHn/yxsPBap86gztACIKr/2zvLtzyQbgGPWyaVXdsBnfPVBWTRLx5E6yYjHQ7cRboXry8Ukj9AbVfXOGGkEd7lrM3ZSTyJxB/LLZpYz5M1i9KC3thCkZPSe30iZkvlhWPJNhXT6qJak0Kv6ZZn6jqwyEhPEXsjp+3AAxVaWNZIiOkRi3Nb4TesFwALeDzrRSOsjMOLi1ARkGcbeA7PO6LO/DaaIWrwIl0RSJIpy3qauphsj04vitzkvC7QAOYHxMhytsbfFAJ/3sJd0vHtqrHuh1QPhzB5v2UUNvAqHLkVbKoBUcXhCXgXzTEqEe5ZDq0w9JsPI6kjcviMbqcirPBcgoYrGhK9EWuwqso2rnV140jKKftGY2ErzVaKe2EWPWlerTbsTX8Sm7kF6Z8YcgtVI3KEyWClRhrCztP73+rK48z9ziztfux/Sr5O8RLQPdYEFGaSNXXYnIRBuCuT68Pu1aUvVY7kGgSqr93yz9mhQnoOZo9n1mivI0vZxg6npYIMSde4DAevmJI7aKAsjMJROAkEA+QxFLXtmuTPTqI9Yd3AzdyIE7Wwzn0jsLN0lKeL8Y5JJs9e
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR22MB208610A6E15C3953EB3EEA58DAD00CH2PR22MB2086namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: e629ba5e-e444-4d8e-350a-08d7e88402a0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 19:16:37.2281 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mSsxUX4z84rjEG3MmSmnCAL7hK+2F06VUlfAs478ip/9sjDre6oaFSbVV6MdIaZTPkRnyBdJNHdzMZFwfWyIQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB1832
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/BfxUB7F92a5uhCXmtOvXBxPJCHU>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted
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: Fri, 24 Apr 2020 19:16:42 -0000

Hijacking a connection requires being able to subvert connections from that client and spoof the destination IP address.  Getting an IP certificate would require doing that, not from one client’s vantage, but from every vantage the CA chooses to test from.  If the CA tests from multiple vantage points, the IP certificate is a stronger assertion than simply being able to accept your connection.

But let’s say we remove the HTTPS path.  What do we do instead?  Do53 is unencrypted and just as unauthenticated.  Speculative DoT is just as unauthenticated, since either you’ll validate against an IP certificate or take whatever certificate is there.  For the time being, all bootstrapping requires an element of trust.  I don’t dispute the weaknesses you point out; I simply don’t see that we’ve found a better alternative.

From: Add <add-bounces@ietf.org> On Behalf Of Eric Rescorla
Sent: Friday, April 24, 2020 2:54 PM
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>; ADD Mailing list <add@ietf.org>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted



On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <paul.hoffman@icann.org<mailto:paul.hoffman@icann.org>> wrote:
On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>> wrote:
>
> Thanks for the updated drafts.  I think RESINFO is the most promising path for resolver upgrade, and I'd like to see it implemented.
>
> The one major change I suggest is to remove the entire HTTPS mechanism from the RESINFO draft.  This mechanism creates a great deal of complexity, doesn't follow good practices for HTTPS, and doesn't obviously enable any additional use cases.  Having multiple competing mechanisms also makes interoperability less likely.

The additional use case that was brought up in earlier work is that a stub that wants to do DoH.
- It does not need to know how to make requests for a new DNS RRtype
- It can use HTTPS as it knows it
- It can get a response that can be authenticated

I understand the desire not to allow unauthenticated HTTPS because of best practices. We can remove that from the draft, but then implementers will likely go ahead and implement it anyway but without guidance about the results. Note that we are only talking about unauthenticated HTTPS *for this one use*, not in general.

> If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could always be added in a later draft.

Some people said it was insufficient because of inability to authenticate.

But the HTTPS mechanism is unauthenticated as well. And even if people do use IP certs, then they mechanism by which they get the IP is largely unauthenticated.

I agree with Ben; this  mechanism should be removed.

-Ekr


--Paul Hoffman--
Add mailing list
Add@ietf.org<mailto:Add@ietf.org>
https://www.ietf.org/mailman/listinfo/add