IETF Logo Mail Archive

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

Mikael Nordfeldth <mmn@hethane.se> Wed, 05 December 2012 17:39 UTC

Return-Path: <mmn@hethane.se>
X-Original-To: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4C21F8C3F for <webfinger@ietfa.amsl.com>; Wed, 5 Dec 2012 09:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.505
X-Spam-Level:
X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfq1R85pJH6Q for <webfinger@ietfa.amsl.com>; Wed, 5 Dec 2012 09:39:02 -0800 (PST)
Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 747F521F897C for <webfinger@ietf.org>; Wed, 5 Dec 2012 09:39:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 05 Dec 2012 18:38:58 +0100
From: Mikael Nordfeldth <mmn@hethane.se>
To: webfinger@ietf.org
Message-ID: <6f9d4091bb8a32db5a9234a63bc9d851@hethane.se>
X-Sender: mmn@hethane.se
User-Agent: Roundcube Webmail/0.7.1
Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2012 17:39:03 -0000

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 mmn@hethane.se webfinger put out a rel-me 
with mailto:obama@whitehouse.gov - 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/
mmn@hethane.se
+46705657637

v2.23.0 | Report a Bug | By Email