Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Tue, 01 October 2019 22:08 UTC

Return-Path: <warren@kumari.net>
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 F3C2912026E for <acme@ietfa.amsl.com>; Tue, 1 Oct 2019 15:08:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 BLFAZUN3wSvg for <acme@ietfa.amsl.com>; Tue, 1 Oct 2019 15:08:10 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD57120219 for <acme@ietf.org>; Tue, 1 Oct 2019 15:08:10 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id w2so12903617qkf.2 for <acme@ietf.org>; Tue, 01 Oct 2019 15:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HHuXbfDXhhjeQBllMvzGYmV0kEvRMOdgwmIbWeG96I8=; b=Q+VdMdHautOc22VJupvW/V/gaIHePpFPhtUwk4G49YoZJZ58014E/u9guTKOeNyr9R gExT1fByI/veF+SO0r4Dx6fonHZm2XDkxb4RdlVIjajdrKcSQEzt0fSgL8IfULZLc/wN A+IjdnGDGds1u4CdfFNZHS0dYwjAeaPkMhE0Y8P2LBpFVe+qzYoOwafPJqiTMWjv0xDr HP1Q9hQyilV5Y4EUJVPFb3s6OFiRn1vlBYUHXzeoTBTn5zdL6lWhc5Mf1GSy7Xu2+WrY FybaC7vKywVO/tzaQv8pHua4tC4MJwQSXaq/udoCJwJMkfSvC1FSXaMwyQsIYt//0/gT /5aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HHuXbfDXhhjeQBllMvzGYmV0kEvRMOdgwmIbWeG96I8=; b=FydSogBPi28OwvxtwNDAAiE42WtsOwtjYLlmD4zTu9ZkxoiMs21K+YVmSRTH/DbRjc kZHJPdA/YaPA7pR6RJkEraAaqcdFIj9OH5f5bAM2HpDRtSDWKYi9yLcRqMC7pR5LgE/z B8eVtj4Eq0enlvAHyxoqtUymcXAX7EH/E8tLeywPvk9TMabXlB+MlmX5uQeqVDiXUW0O l/Y2yJQFWY6laMVKLPO51VlPC643FVTMUOzxw4Gwz5MaZwqCF/r4s89C6K8rxXYzbji4 ObENX+GdYxbMnKRSjqO98tNryZ6Y3rmtduFbeO5igo4OUymghZmcZPD91FokX4z7cuex zSug==
X-Gm-Message-State: APjAAAUC6RZDsXLFk7JVfon7RKHHh9Gdogk5hSVuzxuA9D7H7vQeeJSr jiOUx9aDaAVdvTLQlnT1rBN8pghPynbA16ZTaojS/w==
X-Google-Smtp-Source: APXvYqzINypnIDd8inEXxf0MtabqRnDX16MtTVCgI38/ghIIsmwh/B8X3o6Uqh95vt3Zq+z0ebvUK2UtI63ocSwcJtQ=
X-Received: by 2002:a37:6d2:: with SMTP id 201mr456003qkg.106.1569967688747; Tue, 01 Oct 2019 15:08:08 -0700 (PDT)
MIME-Version: 1.0
References: <156994353133.23716.18054738012405816713.idtracker@ietfa.amsl.com> <797CB1A6-2C78-4BF7-A12E-B3B2DE910E9F@letsencrypt.org> <CAHw9_iLqSqLbmnKQsRuyfos4CFWrw4APovMKGXHLjMXPuXQsGQ@mail.gmail.com> <CAErg=HFmozyJiPPXN2+eYYA0e0tYaN1ACKXThn_8Yvr6QBqnQw@mail.gmail.com> <CAHw9_iKzCWQ5dW0TGw3n+LfdsHJ+0eb=Aiif04Zb-KnFUkmpgQ@mail.gmail.com>
In-Reply-To: <CAHw9_iKzCWQ5dW0TGw3n+LfdsHJ+0eb=Aiif04Zb-KnFUkmpgQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 01 Oct 2019 18:07:31 -0400
Message-ID: <CAHw9_i+=CdDALqN6eOnu8aJ69RcB7E2KgxznD+Nhmu=vbFcTLA@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Roland Shoemaker <roland@letsencrypt.org>, draft-ietf-acme-ip@ietf.org, Tim Chown <tim.chown@jisc.ac.uk>, IETF ACME <acme@ietf.org>, Daniel McCarney <cpu@letsencrypt.org>, Joel Jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>, acme-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/tUe4IG9FqtMXudz4pGqGVQgFv9o>
Subject: Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Oct 2019 22:08:13 -0000

On Tue, Oct 1, 2019 at 5:25 PM Warren Kumari <warren@kumari.net> wrote:
>
> On Tue, Oct 1, 2019 at 5:09 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> >
> >
> >
> > On Tue, Oct 1, 2019 at 2:28 PM Warren Kumari <warren@kumari.net> wrote:
> >>
> >> > The second scenario you suggest is also something covered by 8555, if the attacker is able to fully control the network, then they can control ACME. This is not just the case for IP validation, if an attacker is able to hijack BGP routes then they are able to complete validation for both IP and DNS identifiers (there is currently a handful of both academic and industry work happening to try and mitigate these issues) and is also not just the case for ACME, any CA that does network based control validation, automated or not, is susceptible to these kinds of attacks.
> >>
> >> Yup, I've read 8555, but somehow it feels much more scary to have this
> >> happen for IP addresses than for DNS names -- some of this might just
> >> be me being triggered by expectations that addressed get reused (e.g
> >> DHCP), and that e.g someone on the IETF meeting network could iterate
> >> over all addresses, getting certificates for all of the space...
> >>
> >> This still *feels* dangerous to me...
> >
> >
> > What are the things you might be looking for to address the concern here?
> >
> > The trouble with the scenario you've described basically requires one of two things:
> > - Attackers to be proximate on the 'local' network of the validation target (e.g. ARP poisoning)
> > - Attackers being able to control or influence routing tables as seen by the issuing CA (e.g. BGP poisoning)
> >
> > As Roland mentioned, both of these scenarios are no different than dNSName-bearing certificates. dNSName suffers from issues such as DNS spoofing/fragmentation, as we've seen. However, once the DNS has been translated to an IP by the authoritative server, both scenarios you describe here - ARP spoofing and BGP poisoning - are just as viable to asserting possession of the domain name as they are the iPAddress.
> >
>
> Yup, you are right -- it does end up being the same -- and yet,
> somehow it still *feels* wrong...
>
> >
> > It seems that the concern you've expressed here is slightly different than the one you initially raised on the DISCUSS, and that's a question about certificate lifetimes, and how long the assertion between a key and a subjectAltName should be reasonably expected to be valid. The presumption here is that domain names are "long-lived" in some form (e.g. with their annual renewal), while iPAddresses are "short-lived" (e.g. due to DHCP dispatching from pools). Is that a fair expression of the unease you're expressing?
> >
>
> Yes, I *think* so, but I still have a gut "I really don't like this"
> reaction -- and, annoyingly, I cannot figure out what is triggering
> this...  Whatever the case, I understand that this is just my personal
> hangup, and "Ugh, this makes me twitch" is not actually one of the
> DISCUSS criteria -- and so I will either change my position to
> "Abstain" (which is non-blocking) or "No Objection".

... and I've changed my position to NoObjection -- sorry for the
drama, and thanks to all for helping me work though my IP address cert
neurosis...  :-)

W


>
> > In practice, I think the concern you're expressing for IP addresses is actually common for dNSNames too, as discussed on the topic of BygoneSSL ( https://insecure.design ), and that the solutions are largely not in the validation space, but in defining meaningful and sensible profiles. In this respect, an ACME method to support such iPAddress-bearing certificates helps the problem, more than it worsens the problem, by providing coherent and consistent APIs to facilitate shorter certificate lifetimes and clearer management of those certificates.
> >
> > Regardless of the position taken with respect to this draft document, such certificates exist today, are recognized by major Root Stores, and meaningfully help improve security of important services (such as DoH/DoT to the resolver). So, hopefully that suggests it's a net-good to standardize an approach that might be usable, in future policies, to only permit such IP-bearing certificates iff constraints are met, such as reduced lifetimes, automated issuance, etc.
> >
> > Does that help put you at ease, with respect to this document?
>
> Only kinda, but I do acknowledge that this is my issue, not that of
> the document... I'll change to either Abstain ( in the "I oppose this
> document but understand that others differ and am not going to stand
> in the way of the others.") or "No Objection".
>
> W
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf