Re: [Acme] Assisted-DNS challenge type

Zach Shepherd <shepherdz@vmware.com> Tue, 23 January 2018 04:36 UTC

Return-Path: <shepherdz@vmware.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3312D949 for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 20:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.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 6GKXsmosISqy for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 20:36:52 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0073.outbound.protection.outlook.com [104.47.41.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F2B12D951 for <acme@ietf.org>; Mon, 22 Jan 2018 20:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xHrpJRkGvGkwwUGy9g9RNN724SBZJy/XioiZT1z4W0w=; b=Ngulrtl1N5TvNd2Vzx17t7UUjY24RNXQmR3QxSQcMOU/3wePmE4OjDV+1TmBMkU9nEl+No8QFp3IOADPA1Or7+piU//Us3d7IKcuztP91Xy4nLZX5GbnSgawDN9TqvqfFTjg9zqd8QD84VkwSbTpnbXr0yr7NexJNvUgkdOxPd8=
Received: from CO2PR05MB2518.namprd05.prod.outlook.com (10.166.95.152) by CO2PR05MB2645.namprd05.prod.outlook.com (10.166.95.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Tue, 23 Jan 2018 04:36:36 +0000
Received: from CO2PR05MB2518.namprd05.prod.outlook.com ([10.166.95.152]) by CO2PR05MB2518.namprd05.prod.outlook.com ([10.166.95.152]) with mapi id 15.20.0444.012; Tue, 23 Jan 2018 04:36:37 +0000
From: Zach Shepherd <shepherdz@vmware.com>
To: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: [Acme] Assisted-DNS challenge type
Thread-Index: AQHTk+bmfHjmOHT2U02bvrxz/T9Ys6OAuOyAgAAlXB0=
Date: Tue, 23 Jan 2018 04:36:37 +0000
Message-ID: <CO2PR05MB2518CC644BE8EC6BCBFA2FABC0E30@CO2PR05MB2518.namprd05.prod.outlook.com>
References: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>, <1516673869.2514073.1244589216.6E1138EC@webmail.messagingengine.com>
In-Reply-To: <1516673869.2514073.1244589216.6E1138EC@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [12.161.88.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR05MB2645; 7:rlk0uObs92b51TUhDY8bmGHXytBIV821ebHQa4SaV2dGCKBLkolmbxq1n7NCOVrX433IGQzJtnTFIocX7G9NW6WM18XrPVr1luO65hUR4O9M7cUOHlOtc16NCrSUBdeBH9aZRNz+aXp/ztxSAvvvsKx9Xy8FKKZDhgsd7gylYFLH3LOUnasjpL+vMeRfBaZBQJ9drMs2Kd2vob7vDFXWMXZWbZ93FwW1RfRtx1ob2EI+VDFCR0evglckZYneHnof; 20:L/aCexEVK9WC7dJXojfQdGUjMGE4AEP4LsQl8chAUNHRFad3ce5m5ejDYY/styvz5XehaGZd2xmcmX7JNpkV36UZOOroqyNI/7R+WFK1pmReDznwXnuPACzaNSMVQzBOJ8a8ahnne4ctSCiP//rscv+PULIui7E3NrgSCxmm00c=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 317ce1d5-9214-4ac6-0f35-08d5621ae3be
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534145)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CO2PR05MB2645;
x-ms-traffictypediagnostic: CO2PR05MB2645:
x-microsoft-antispam-prvs: <CO2PR05MB264530AAC79C0F2FC57760C7C0E30@CO2PR05MB2645.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(60795455431006);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231046)(2400081)(944501161)(93006095)(93001095)(10201501046)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CO2PR05MB2645; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:CO2PR05MB2645;
x-forefront-prvs: 05610E64EE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(39380400002)(366004)(189003)(199004)(81156014)(76176011)(33656002)(102836004)(7736002)(99286004)(106356001)(316002)(105586002)(6506007)(3660700001)(66066001)(3280700002)(3846002)(74316002)(86362001)(6116002)(8676002)(53336002)(25786009)(1730700003)(2906002)(2501003)(6246003)(81166006)(2900100001)(8936002)(5660300001)(97736004)(5640700003)(9686003)(53936002)(229853002)(59450400001)(54896002)(7696005)(55016002)(2351001)(478600001)(19627405001)(6346003)(2950100002)(6436002)(68736007)(26005)(14454004)(6916009)(6606003)(77096007); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB2645; H:CO2PR05MB2518.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shepherdz@vmware.com;
x-microsoft-antispam-message-info: XiICaGTC0TleGN5geTqfA/fUUFTKo1BGkLCBaMVz+E1uc9Q9FRIk8DjPLERwPw+5ThX3raDmflw6x5XiUiBL+w==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR05MB2518CC644BE8EC6BCBFA2FABC0E30CO2PR05MB2518namp_"
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 317ce1d5-9214-4ac6-0f35-08d5621ae3be
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 04:36:37.1098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2645
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/FCcCMO8ylyRlk9EqT-8qUvjBIVI>
Subject: Re: [Acme] Assisted-DNS challenge type
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2018 04:36:55 -0000

> > In effect, the CNAME record would act like a long-term delegation

> > permitting the CA to issue continuously for the base domain.
>
> I can imagine that this introduces a new risk of domain
> administrators "forgetting" about having made a long-term delegation
> of  _acme-challenge to the CA and unwittingly authorize an account
> key to issue certificates for any name longer than intended. Any need
> to mitigate this?

It seems like each existing challenge type requires a user to prove
continued ownership of the identifier to receive authorization.

This challenge, however, is different: an action serves as proof of
ownership until it is un-done.

Hypothetical: how would we feel about an assisted-http-01 challenge
that, analogously, provides users with an address to use in an HTTP
redirect for resources under /.well-known/acme-challenge?

The CA instruct subscribers to delegate the /.well-known/acme-challenge
directory to a subdomain of the CA's hosted DNS domain.

The assisted-http-01 challenge would then be validated like http-01,
except: As the first step in validation, the CA would deploy the
expected resource at 1234.challenges.ca.example.net.

Then the CA would continue to perform a GET operation on the usual
resource "GET example.com/.well-known/acme-challenge/...", which
would redirect to 1234.challenges.ca.example.net/...

In a way, fetching final resource would also be a formality: the CA
could in theory stop once it saw the redirect pointed at the right
location, though most likely abiding by the terms of the BRs would
likewise require following the formal lookup steps.

I think this hypothetical assisted-http-01 is a fair analog, but does
not seem like something we would want to support. And given that, I'm
not convinced the added complexity of automation or difficulty of
protecting DNS credentials are sufficient to justify assisted-dns-01.

Zach