- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 12 Aug 2015 13:52:03 -0700
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: Kent Watsen <kwatsen@juniper.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Max Pritikin (pritikin)" <pritikin@cisco.com>
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. On 12 August 2015 at 13:32, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hiya, > > On 12/08/15 17:56, Kent Watsen wrote: >> 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? > > 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. > >
Received on Wednesday, 12 August 2015 20:52:32 UTC