Subject: [Acme] On draft-ietf-acme-ip

From: Ben Schwartz <[email-masked]>
Date: Thu, 31 Aug 2017 17:46:43 -0400

Hi all,

This is a very late comment from IETF 99.

I just wanted to speak up in support of draft-ietf-acme-ip, as a potential
user.  My team has developed a product that makes it easy for users to open
an account on a VPS provider and start an instance of a server for personal
use.  Our users are nontechnical, and they don't own a domain name.  They
can barely handle opening one account; opening another one (with a
registrar and/or a certificate authority) would be a nonstarter.

Currently, we can't offer users access to their server in a standard web
browser, because we can't programmatically acquire a certificate for them.
Instead, we generate a self-signed certificate, and pass the fingerprint
through a trusted channel to a special-purpose client.

draft-ietf-acme-ip would allow our users to access their servers with at
least protection from a passive adversary.

--Ben

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Sep 2017 01:25:03 +0100

Hiya,

> This is a very late comment from IETF 99.

Here's an even later and less well-informed comment. (Sorry,
I didn't notice the traffic on this draft before now;-)

I really like the idea that the acme WG aims to figure out a
way to enable people at home to use https with their home n/w
routers.

I'm not at all sure that a DNS-based approach here will cut
the mustard, though it's a not-bad plan to define one in any
case.

I'd love that we chat about this topic involving folks from
the acme and homenet WGs, as it seems those are the sets of
IETF folks who might be most relevant for the discussion.

Lastly, having read the WG mails related to this draft, I
do get that a solution that doesn't muck around CAB forum
policies is needed, (or else that browser should barf the
cert) I'd also argue that it may be easier to work around
CAB forum than the realities of DNS. (That said, I do not
have a concrete suggestion for how to solve this problem,
sorry;-)

Cheers,
S.

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Aug 2017 19:47:30 -0500

On 8/31/17 19:25, Stephen Farrell wrote:
> I really like the idea that the acme WG aims to figure out a way to 
> enable people at home to use https with their home n/w routers.
>
> I'm not at all sure that a DNS-based approach here will cut the 
> mustard, though it's a not-bad plan to define one in any case.
>
> I'd love that we chat about this topic involving folks from the acme 
> and homenet WGs, as it seems those are the sets of IETF folks who 
> might be most relevant for the discussion. 

There was some musing at the W3C TPAC in Lisbon last year on this topic. 
The tricky part is figuring out what kind of model makes sense for the 
certs at all. I suspect we'd need to come to some agreement on that 
issue before trying to work out how ACME can be used to issue them. 
There's some background reading at 
<https://www.w3.org/wiki/TPAC2016/session-https-local-summary>, mostly 
in the form of slide decks.

/a

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Sep 2017 12:58:53 +1000

On Fri, Sep 1, 2017 at 10:47 AM, Adam Roach <[email-masked]> wrote:
>> I really like the idea that the acme WG aims to figure out a way to enable
>> people at home to use https with their home n/w routers.
...
> There was some musing at the W3C TPAC in Lisbon last year on this topic. The
> tricky part is figuring out what kind of model makes sense for the certs at
> all. I suspect we'd need to come to some agreement on that issue before
> trying to work out how ACME can be used to issue them. There's some
> background reading at
> <https://www.w3.org/wiki/TPAC2016/session-https-local-summary>, mostly in
> the form of slide decks.

I don't see acme-ip being the solution here.  Everyone has - or could
have - a 10.0.0.1.  The same applies to .local (see below).  The
movement needs to come from the relying party side.

Thanks for sharing the link Adam, I was not aware of this.  For the
benefit of folks in the galleries, the three talks discuss two
options.

The first two talk about providing *real* names for the devices
(<device-id>.<manufacturer>.com for example).  The nice thing with
that is that that solution already works today.  With ACME, if the
manufacturer is willing to answer the challenges, the device only
needs some way to talk to the manufacturer when it wants a
certificate, not have an actual online presence.  (Insert usual
concerns about the manufacturer going out of business, etc...)

I'm not sure that I fully grok the last one, but it talks about an
ACME-like protocol that is mediated by a browser.  It also talks about
creating certificates for non-unique names on .local, so I'm not sure
that it's feasible.

Not discussed here, but we've talked a bit about using key continuity
for network-local devices and changing the "bad certificate" page we
show on first connection (with a different page when a different key
is presented by the device).