Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP

From: Mikael Nordfeldth <[email-masked]>
Date: Wed, 05 Dec 2012 18:38:58 +0100

Pardon if I lose thread metadata in this message.

Salvatore asked about the consensus for HTTPS only vs priority HTTPS 
followed by secondary HTTP.

TL;DR: I support suggested priority for HTTPS followed by an optional 
HTTP fallback.
(not necessarily a MUST on https for first connection, maybe my client 
service entirely relies upon end-user verification anyway - see my 
example of pretending to be Barack Obama further down)

HTTPS only would be a MUCH bigger threat to widespread WF adoption 
than, say XRD support. For the small startup services that just want to 
put out or aggregate data, properly configured HTTPS servers are hard 
and expensive - without a proper configuration there is no practical 
difference from HTTP.

In many languages the HTTPS toolkits are bad at verifying CA 
signatures. Adding to that, CA trust is NOT globally equal. Considering 
that most HTTPS connections are verified blindly through system-default 
CA bundles, most real-world Webfinger HTTPS request will be _equal_ to 
HTTP in trust. (How many of your systems trust Verisign but not 
CAcert.org?)

Clients that authenticate against webfinger servers will likely be 
trustworthier (make actual use of HTTPS) as they should know the remote 
server beforehand, CA chain and all.

Other reasons for my reasoning:

* Webfinger servers generally will serve public data. It is meant to 
support building better user experience by giving trivial metadata about 
various kinds of internet identities. ANY data published without 
authentication should be regarded as PUBLIC and NON-VERIFIED.
Remember that I could have my [email-masked] webfinger put out a rel-me 
with mailto:[email-masked] - not a single connection 
encryption/signing protocol in the world can stop that type of incorrect 
source data. Most WF data will probably be in one way or another 
verified by end-users sooner or later.

* Responsibility for sensitive data retrieval is mostly put on the 
client. Clients that authenticate or fetch data that would be abused are 
well aware of risks when fetching data over non-verified connections.

* Servers that don't support HTTPS reasonably don't have sensitive data 
in the first place (for interception or manipulation).

All-in-all my point is that HTTPS is ONLY benficial when connecting to 
a previously known.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
[email-masked]
+46705657637

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 11:25:08 +0100

+1 HTTPS only

Axel

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Thu, 13 Dec 2012 23:34:22 +0900

+1 HTTPS only

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 14 Dec 2012 01:04:30 +0900

+1 for HTTPS only, please.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en