Re: [Acme] Want client-defined callback port

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 22 April 2015 04:09 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 505EE1B3173 for <acme@ietfa.amsl.com>; Tue, 21 Apr 2015 21:09:51 -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] 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 KXHEGwtsMT4V for <acme@ietfa.amsl.com>; Tue, 21 Apr 2015 21:09:50 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D67021B315B for <acme@ietf.org>; Tue, 21 Apr 2015 21:09:49 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4DC81283033; Wed, 22 Apr 2015 04:09:47 +0000 (UTC)
Date: Wed, 22 Apr 2015 04:09:47 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: "acme@ietf.org" <acme@ietf.org>
Message-ID: <20150422040947.GJ25758@mournblade.imrryr.org>
References: <352DA5FE-AC6F-49A7-8F9F-70A74889204F@apple.com> <CAK3OfOjey4bk02qC_jj2c0AzZ54qnP=KAJnG=mXnO6A5gZ4m9g@mail.gmail.com> <CAL02cgQ94ijVrCM9SStcodRW+XSG2w5Zwu3+ny8HriDBnxjdtg@mail.gmail.com> <FF21526F-BA8D-4F54-AAE3-047632706668@apple.com> <CAL02cgSDk0TNYusEkXA3onmqF7=kaAWhHjpW8WjbiqxgQMdQwQ@mail.gmail.com> <555F6C74-2416-4893-BDEA-A3C2E55A6D57@apple.com> <16985cf1c8c444c48d328fa766ec5ff8@usma1ex-dag1mb2.msg.corp.akamai.com> <DE264105-7317-4343-BCEE-539A73D42544@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DE264105-7317-4343-BCEE-539A73D42544@apple.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/0gH6ivEQEMTy4hTwKg6Mzy5suPg>
Subject: Re: [Acme] Want client-defined callback port
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: acme@ietf.org
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: Wed, 22 Apr 2015 04:09:51 -0000

On Tue, Apr 21, 2015 at 07:53:25PM -0700, Bruce Gaya wrote:

> The policy of Let's Encrypt Certificate Authority, however, is
> very important!   I also would very much like that CA to allow
> client-defined callback ports below 1024.

That level of diligence would finally expose the security of
certificate issuance for the charade that it is.  If the LE CA
adopted this policy, I would expect its certificates to be worth
exactly the price charged for them.  Relying parties should not
trust such a CA.

Of course relying parties should also not trust certificates based
on many of the other types of "it just works" issuance practices.
For example, certificates issued on the basis of the ability to
respond to an insecure email sent to an "admin" mailbox at the
domain, etc.

However much we pretend otherwise, the only party in position to
make a low (near zero) cost assurance that a particular owner
legitimately controls a given domain is the domain registrar.

The domain owner can attempt to demonstrate such control by injecting
"cookie" records into the DNS, but such demonstrations are subject
to MiTM attacks on the DV certificate issuing CA.

So in my view DV certificates are largely worthless (not significantly
better than unauthenticated TLS, and are used only because HTTPS
insists on an often meaningless CA signature).  The fact that LE
helps to bring the cost, including deployment costs, of meaningless
certificates to $0 is I guess progress.

-- 
	Viktor.