Subject: secure HTTPS redirect - encoding a new trust anchor?

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Aug 2015 15:33:00 +0000

I'm writing to discover if HTTP already supports the use-case described
below, or if there is a need to extend HTTP in any way.

The use-case regards the automatic bootstrapping of devices, as currently
being discussed by the NETCONF and ANIMA working groups.   One prevailing
idea is for an Internet-based "bootstrap server" (most likely hosted by
the vendor of the device) to redirect devices to their deployment-specific
bootstrap server.  That is, the owner of the device only needs to register
the URL (not all the bootstrapping data for a device), thus resolving a
privacy concern.

The issue regards how to convey the TLS trust-anchor used to verify the
redirected HTTPS connection, specifically when the deployment chooses to
use their own PKIX infrastructure instead of a global certificate
authority (e.g., Verisign).  Thus the HTTP Redirect (e.g., 307) needs to
return both the Location header and also a TLS certificate.  For instance:

                         Trusted
                      Internet-based      Deployment-specific
Device               Bootstrap Server       Bootstrap Server
  |                          |                     |
  |                          |                     |
  | HTTPS using factory      |                     |
  | default trust anchor     |                     |
  |------------------------->|                     |
  |                          |                     |
  |    HTTP redirect, with   |                     |
  |    deployment-specific   |                     |
  |    trust anchor          |                     |
  |<-------------------------|                     |
  |                          |                     |
  |                                                |
  |HTTPS using learned trust anchor                |
  |----------------------------------------------->|
  |                                                |

FWIW, this is considered secure, as the trust anchor is learned through a
trusted connection.

Now back to the original question.   As far as I can tell, a 307 response
may have a message body, so a TLS certificate could be returned in it.  Is
this accurate?  Also, while this specific behavior could be documented in
draft-ietf-netconf-zerotouch, it seems generally useful and may be better
defined in HTTP instead - what do you think?

Thanks,
Kent

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 16:59:15 +0100

Hi Kent,

>   | default trust anchor     |                     |

Eh... considered secure by whom? I would not consider
that "secure" if any widget-vendor from whom I purchase
anything can then pretend to be any web site.

Do you really mean trust-anchor here? Or perhaps you
mean "some kind of special public key only to be used
for the specific URL that is in this 30x response and
only for 1 (really 1?) time"?

And what if that URL is say bigbank.example.com? How
is that to not work?

I guess I'm a bit puzzled.

S.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 Aug 2015 16:56:52 +0000

[CC-ing Max Pritikin]

Hi Stephen,

Comments inlined below.

Thanks,
Kent

>anything can then pretend to be any web site.

Well, both Max and I felt it was OK for the bootstrapping use case.
Admittedly, it has not been thoroughly reviewed yet...though this email
thread is taking it on now  :)

The widget-vendor isn't pretending to be another website - it is
redirecting the client to another website.  For instance:

  Request (assuming device's serial number is "123456")
  -------
  GET https://widget-vendor.com/bootstrap-server:devices/device=123456

  Response
  --------
  HTTP/1.1 200 OK
  Content-Type: application/xrd+xml
  Content-Length: nnn

  Location: 
https://rightful-owner.com/bootstrap-server:devices/device=123456
  <X.509v3 CA certificate for rightful-owner.com here>

>only for 1 (really 1?) time"?

My terminology may be incorrect, but as the above example implies, the
X.509v3 cert returned is expected to be subsequently used to verify the
HTTPS server (rightful-owner.com).   This in lieu of relying a global CA
certificates, such as are distributed by web browsers.

>And what if that URL is say bigbank.example.com? How

I think your question regards the general applicability of this idea by
web browsers, where having the web browser dynamically learn a new trust
anchor certificate, even if over a trusted connection, can lead to misuse.
 Is that right?   - that is, is your concern is for generic use more so
than the specific use of zerotouch bootstrapping?

Thanks again,
Kent

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 21:32:23 +0100

Hiya,

> than the specific use of zerotouch bootstrapping?

Sort of. I'm concerned with generic *ab*use (well also with specific
abuses:-)

The example you gave would appear to allow widget-vendor.com to arrange
that the HTTP client ends up talking to widget-vendor.com but thinking
it is talking to my-os-update.com. I'd say that's a pretty dangerous
implement esp given the 1000's of perhaps not very highly experienced
and universally trusted widget vendors in the universe.

Cheers,
S.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Aug 2015 13:52:03 -0700

Would a narrower solution work?  Rather than looking for something
generic (which is what you do when you ask on this list), you could
design something specific.  None of this needs HTTP work, it is all
over-the-top.  In fact, if it is made generic, that's when things get
super scary.

It could work like this: Widget vendor bakes in a "bootstrap trust
anchor" and a "bootstrap URL" when it builds a widget.  When the
widget first activates, it connects to the "bootstrap URL" and
validates that URL with the "bootstrap trust anchor".  If that all
works, then the widget can install the trust anchors it finds.  (If it
fails, I don't know what, of course).

Stephen, is your objection about the general nature of the query, or
the specific mechanism?  I get the issue with making this general, but
I'm a little less concerned about a specific anchor management feature
in the form of the above.  If I install trust anchors on your device,
or I make the software, or I make the hardware, then you need to trust
me not to be doing things to enable spoofing.

Of course, this adds another potentially weak link (the key bound to
the temporary anchor), but that's not so abnormal.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 22:26:57 +0100

On 12/08/15 21:52, Martin Thomson wrote:
> the specific mechanism?  

Yep it's the general nature of the outlined scheme that's alarming.

I'd not be at all surprised if there are sensible ways to have
device vendors interact with larger purchasers of sets of those
devices where such handovers can be managed safely enough.

I'm less sure there are good answers for a random widget from some
company I've never heard of re-badged by someone I have heard of
when I'm a home user. (And in that latter situation there are a lot
of open-source code and distribution systems involved which can
make things harder or easier, not sure.)

There may be some discussion of this topic at IETF94 including this
work being done in ANIMA. Maybe at saag and maybe some other place
but feel free to ping me if interested.

Cheers,
S.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Aug 2015 14:58:10 +0000

>devices where such handovers can be managed safely enough.

OK, so let's just focus on the narrower solution now (see my response to
Martin)

>but feel free to ping me if interested.

Yeap, and I'm deep involved with both the ANIMA and NETCONF work on this.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 13 Aug 2015 14:57:52 +0000

Hi Martin,

I'm good with an over-the-top solution, but do you think we can cleanly
embed a certificate in the message body of an HTTP redirect message? -
what would the Content-Type be?    If not, then we'd have to define an
explicit resource to get the secure redirect information (both the
hostname and certificate) - this is definitely doable, though it seems a
bit clumsy, what do you think?

Thanks,
Kent

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Aug 2015 09:34:07 -0700

> bit clumsy, what do you think?

I don't think that you want to use a redirect.  How about plain old
JSON with a shiny new content-type of your own invention:

{
   "gohere": "https://url.example...",
   "butfirstusethese": {
     "trustanchors": "a PEM-encoded certificate",
   }
}

That's not generic, but it's not unreasonable for the device to
natively support a little more protocol machinery in order to avoid
having to be manually configured.

p.s., Ted pointed me at:
https://tools.ietf.org/html/draft-ietf-netconf-zerotouch, it seems
like you have most of the infrastructure there already.