Re: [Acme] Want client-defined callback port

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 23 April 2015 17:01 UTC

Return-Path: <hallam@gmail.com>
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 20A9E1ACD35 for <acme@ietfa.amsl.com>; Thu, 23 Apr 2015 10:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.621
X-Spam-Level: *
X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_BACKHAIR_32=1, SPF_PASS=-0.001] autolearn=no
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 uNpt2-DLkVoV for <acme@ietfa.amsl.com>; Thu, 23 Apr 2015 10:01:56 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 88CC91AC437 for <acme@ietf.org>; Thu, 23 Apr 2015 10:01:55 -0700 (PDT)
Received: by lbcga7 with SMTP id ga7so18039104lbc.1 for <acme@ietf.org>; Thu, 23 Apr 2015 10:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=x5Uibry8O/Z9y5qYQjP8ndrjKenDqD6i8y6INjEUL9o=; b=hyfbqCEpGjlUnZV+xLTd3ZuqECP6UyUDyo1j3BJ7cnX6425nOk28XruhSwB6RHwkzN abFHMnexYC3DXn9q+9y5NEXMGecOzUzZmat9gpxRnNh2Wn64tTu5YoJr4QyfVcuYvQLM 7ZOIk9OM9wqltbbXa6vKG9mIkuKxuGPA97buJNCYmn5owQXlOPWt+jezzz/Bw3Q9FhTI UpFpSd9oJxwbf1wFVwStWL4dlRMiZiP5yZg0lK0l91s2v1cU+zQq7chxtYCtlQAoIc3Y FuHd4+DM+HJCZCqs9l95kUJmA/p8S7FTGBtodfT4Xjx5maFJBaI6/U1bI+7/OZ2Fno09 Wx4g==
MIME-Version: 1.0
X-Received: by 10.112.42.233 with SMTP id r9mr1748504lbl.58.1429808514082; Thu, 23 Apr 2015 10:01:54 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Thu, 23 Apr 2015 10:01:53 -0700 (PDT)
In-Reply-To: <02937f42ee274952a44476be019f2864@usma1ex-dag1mb2.msg.corp.akamai.com>
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> <CAL02cgTv5Zi4wP0gJPvcrty6N96pAaLRkCveyvMNfoyjQrrEyw@mail.gmail.com> <0609C348-A6D8-46D5-AF58-5BE69910D261@apple.com> <CAL02cgT_DPY-Bn9A=UtCx+g2FKHON-TXGCWfH-gL8rR4yEFHZg@mail.gmail.com> <CA+9kkMAqte7O0k0KVRLRaEOmJL-wK0ncoruv3yoqKBjZVnc99g@mail.gmail.com> <CABkgnnVP4as97fXe7XTFpC=rw6ETdXY5s=1cRj1Xan1sgDsx3A@mail.gmail.com> <CAMm+Lwg5GiknSceb1Ocs=VxA1cZpmcrmZbPeXpgfAHbOC3CUcw@mail.gmail.com> <CAL02cgReRXAu4QjvsDYYkJN-WKS2bZeWNtZK-AoVndTncMQvag@mail.gmail.com> <CAMm+Lwi97VeE7j72oCXTeqEJWSQ=RTM3VH6hZ_GapbtZ9bmfwQ@mail.gmail.com> <CAL02cgTeztSb2B2pfweQfUL8Ty0XfiBLbtCLTrHwLNZ2LTQPVQ@mail.gmail.com> <CAMm+LwiR2tZVvWYOfKOMKybNNi9f52A_W4QGH6Bxx_haivFz3g@mail.gmail.com> <02937f42ee274952a44476be019f2864@usma1ex-dag1mb2.msg.corp.akamai.com>
Date: Thu, 23 Apr 2015 13:01:53 -0400
X-Google-Sender-Auth: U3tdJ76_siPZVLRpeX4GvQkGzd8
Message-ID: <CAMm+LwjdSzpg_kSwKgTiCkSpV7LXZk_J_UOg06FFp3mrK5OrCg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Uy8PFeEyoiNZnStNXiD2FCtUWd0>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Want client-defined callback port
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: Thu, 23 Apr 2015 17:01:59 -0000

On Thu, Apr 23, 2015 at 11:56 AM, Salz, Rich <rsalz@akamai.com>; wrote:
>> I think we can decide on a mechanism. But getting into long arguments as to
>> whether ports other then 443 should be accepted or if so which ones seems
>> to be unnecessary.
>
> I am fully in favor of mechanism, not policy.  But we would HAVE to change the protocol to allow a port to be specified.

The protocol has to support multiple validation mechanisms, not all of
which are going to be relevant to WebPKI. So one approach would be to
say 'if you are going to use a port other than 443 then its a
different mechanism that is out of scope for now'.


> It's a slippery slope.  Taking your argument only a little bit further, should PKIX have shut down once CABForum spun up?

Some say it should have shut down earlier.

PKIX does not just support the WebPKI. It also has all the peculiar
policy constraint curlicues.


> If you're not a browser or well-established CA, you need special dispensation to join[1].  That leaves a very important community -- users[2], who haven't been well-served by previous efforts in this area -- out.  I am not sympathetic to "just let CABForum do it" arguments.

Well both sides have a veto power as far as the WebPKI goes. So if
IETF wants to say '443 or nothing' it certainly can make it stick.
Alternatively it can leave the choice of port blank and let CABForum
decide if they want to choose one or more for WebPKI. But deciding
other port numbers seems to me to be down in the weeds. Its like
offering fifty options for desert to a child who will only eat mac and
cheese.


Another point to consider here is the framing of the problem. People
are discussing this as validating a certificate request. I think that
is the wrong way to look at it. What we are doing is to validate the
holdership of a DNS name. Which is not the same thing. That may be a
component of a certificate validation process but it is not
necessarily one that would apply to every certificate issue.

Ten years from now, I would expect we will be using short lived certs
that roll every 24 hours, that every service has a separate cert and
the default configuration for systems is load balanced and fault
tolerant.

In that configuration a SOHO configuration using a couple of off the
shelf appliances is going to be consuming two sets of half a dozen
certs every day. I don't think we need to do twelve separate domain
validations every day. In fact I don't think we really need or want to
do validation every day. Or at least I don't want to be using this
particular scheme on a repeat basis.


What I would prefer is to validate the certificate applications under
a device key and push the fingerprint of the two device keys out into
the DNS (It was one of the extended use cases for CAA records). So if
the DNS record changes we can infer that a change of control has
occurred and we want to retest holdership.

Now would such a scheme eliminate the need for a port443 check? Well
it certainly does not support the 'run this one program and go'
scenario so it can't be the only scheme. And I am not even sure that
CAA record validation alone is sufficient for reasons I don't want to
go into right now.

But looking at where we are likely to go with ACME, I think we could
make a good case for 443 validation only right now and punt on the
question of seamless issue for protocols on ports other than 443 where
there isn't a connection to the Web server.

The protocol we are designing right now is the one I think will be the
LRA<->CA protocol long term. I think we want the device<->LRA protocol
to do a bit more. In particular I think stuffing HSTS/HPKP records
into the DNS is a no brainer and we probably want to configure the A,
AAAA, SRV etc records as well.