Re: [Acme] Threat model for claiming domains

Richard Barnes <rlb@ipv.sx> Mon, 22 December 2014 14:29 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF231A8F4D for <acme@ietfa.amsl.com>; Mon, 22 Dec 2014 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 PoIYHByY4E82 for <acme@ietfa.amsl.com>; Mon, 22 Dec 2014 06:29:25 -0800 (PST)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA821A8F50 for <acme@ietf.org>; Mon, 22 Dec 2014 06:29:24 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id hs14so4123416lab.11 for <acme@ietf.org>; Mon, 22 Dec 2014 06:29:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U43w3cTIf1xwLbcLl538xs1dp6nkxLT8YvhR80AilB4=; b=glLArIvEDQRy7vuU0N3+zZgfa+Jwk8WrDPES45FO3MXPK9lL+wsz9u/A/R43tFuCly YiWh30U/PQpgtjp/N88T/bRsXtZt1e1laC7bW0kIDOBNPThd4uEhNG+oPFluslhT2uU5 sDzMtjPexB7qN01J9TDOYHd9O+mW0dwr5y7SkKssLzxznkL7XcVVFsVtz0GkF+cfYDfP sSrQxirnxpjkxZuilPa2dyCkSHilEMfpd8agvVp2EN3v7h1mWYV0maEUgPAjRFZUXxan +HGkF3dXITDVLWQ06mXPK9bD+UGsz2ZL5YyrA5hZbdAAT02q8TFqSpqMn79U5nPWMQop WWLg==
X-Gm-Message-State: ALoCoQkcT63UuUV9ICn3nNZZxwa9Jdnsqdt2ZxvZcjOJzx8Y/B5UofgJKT8vm3qJu4kVKcg9sN1X
MIME-Version: 1.0
X-Received: by 10.152.29.129 with SMTP id k1mr22601472lah.10.1419258563423; Mon, 22 Dec 2014 06:29:23 -0800 (PST)
Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 06:29:23 -0800 (PST)
In-Reply-To: <5497F5BB.9030002@comodo.com>
References: <CAHOTMVJdf8mQ-8_-ocHpfUA+N9v-S5VsBWgOVp1aFwDaWp3d0Q@mail.gmail.com> <CAL02cgSvc1sO-iH3J_c4f=A2CspKwG686DaSUC1JKLD4GRy__w@mail.gmail.com> <5497F5BB.9030002@comodo.com>
Date: Mon, 22 Dec 2014 09:29:23 -0500
Message-ID: <CAL02cgSLtiN0Q-KEWZLcG_YjrW0gtdrwJHF9e6W_FdkHR92aig@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: multipart/alternative; boundary="089e0160b7da848433050acee22f"
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/gN1NxR4kmB3c9RT4ZIvZo1SBHKo
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Threat model for claiming domains
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 22 Dec 2014 14:29:28 -0000

Hey Rob,

Thanks for this.  The HTTP one looks more or less as I would have
expected.  We should probably tighten up the ACME one to look more like it.

With regard to the DNS validation:
1. Is there a reason you guys use CNAME instead of TXT?
2. W.r.t. using a subdomain vs. the name itself: When we wrote the current
ACME spec, the thinking was that it might be possible for an applicant to
provision a subdomain without being able to provision a record under the
name itself.  For example, with my Dreamhost hosting account, I can
register any records I want under "<md5>.dreamhosters.com", but I can't
provision under "dreamhosters.com".  Are you accounting for this risk
somehow?

I notice that there are mentions of an API in that document.  If you have
other API documentation you could share, that could be useful.  In
particular, it would make it easier to make ACME something that you guys
could transition to :)

--Richard



On Mon, Dec 22, 2014 at 5:43 AM, Rob Stradling <rob.stradling@comodo.com>
wrote:
>
> Hi Richard.  This pdf has some more details on Comodo's other domain
> validation methods...
>
> https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
>
> On 20/12/14 00:25, Richard Barnes wrote:
>
>> Hey Tony,
>>
>> I just got around to thinking about this for a moment.  Obviously, our
>> baseline here should be whatever the CAs are doing today, since we have
>> empirical evidence that those methods are more or less OK.  I did a
>> quick and dirty empirical survey of the top few CAs this afternoon:
>>
>> https://docs.google.com/a/ipv.sx/document/d/1KVKIS6abA2KL-
>> yHvFsMql6U3qUjVhgO6p19Hzci0vQo/edit?usp=sharing
>>
>> For the most part, they rely on sending an email to either the
>> registered WHOIS contact, or something like admin@domain.  GlobalSign
>> supports validation based on a DNS record or a <meta> tag in index.html.
>>
>> With regard to your concern about services colocated on the same IP
>> (presumably for simpleHttps and DVSNI validation): This seems to mostly
>> be addressed by not allowing the ACME client to specify the port that
>> the ACME server connects to.  That means that the attacker has to
>> control not only something on the box, but the default port for HTTP or
>> HTTPS.  If that's not the case, normal routing based on the Host header
>> or SNI should ensure that the validation request goes to the right place.
>>
>> Nonetheless, I agree that more analysis would be useful, across all the
>> validation methods.
>>
>> --Richard
>>
>>
>> On Mon, Dec 1, 2014 at 7:33 PM, Tony Arcieri <bascule@gmail.com
>> <mailto:bascule@gmail.com>> wrote:
>>
>>     Is there a published threat model for claiming domains? I haven't
>>     been able to find it, but I'd certainly like to read it!
>>
>>     If we simply accept a service running on the same IP that a given
>>     DNS name points to, there seems ample opportunity to register
>>     certificates for services colocated on the same IP.
>>
>>     --
>>     Tony Arcieri
>>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>