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

From: Salvatore Loreto <[email-masked]>
Date: Wed, 5 Dec 2012 16:58:53 +0200

During the last couple of weeks there has been a lot of mail discussing 
whether
WebFinger MUST support HTTPS only or instead it should be allowed for 
WebFinger
fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or 
the other,
but also people that are more flexible and also having a preference 
could live with the other.

However the discussion so far has not produced any clear consensus the 
editor can include in the
next version of the wg draft.

So as chairs I want explicitly to check where the wg consensus is

1) HTTPS only

versus

2) HTTPS + HTTP but only as fallback

So please provide your preference and if you want also the reason why 
you think WebFinger should
adopt that particular solution.

This consensus call will run until December Thursday 13th, 2012

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: James M Snell <[email-masked]>
Date: Wed, 5 Dec 2012 09:04:22 -0800

On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <
[email-masked]> wrote:

> There are people with a clear preference (sometime strong) one way or the
> other,
> but also people that are more flexible and also having a preference could
> live with the other.
>
> So please provide your preference and if you want also the reason why you
> think WebFinger should
I'm +0 on both of these. There is a third option that I prefer..

3) HTTPS or HTTP... leave the decision up to the server and client
depending on their own specific needs. Servers can enforce the use of https
if that server deems it necessary. Likewise, clients can choose to use
https or http if it deems it necessary.

- James

> ______________________________**_________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/webfinger<https://www.ietf.org/mailman/listinfo/webfinger>
>

---

From: Tim Bray <[email-masked]>
Date: Wed, 5 Dec 2012 09:07:17 -0800

+1 on #1

-1 on #2, I’d be OK with fallback if it were a way to have it explicitly
allowed/disallowed by the caller.

 -T

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Dec 2012 14:45:53 -0300

+1 for 1

Http fallback increases client complexity.    It also makes it hard for upper level applications to know what is going on in the underlying WF library.

On 2012-12-05, at 2:04 PM, James M Snell <[email-masked]> wrote:

> 
> On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto <[email-masked]> wrote:
> 
> During the last couple of weeks there has been a lot of mail discussing whether
> WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger
> There are people with a clear preference (sometime strong) one way or the other,
> but also people that are more flexible and also having a preference could live with the other.
> 
> However the discussion so far has not produced any clear consensus the editor can include in the
> So please provide your preference and if you want also the reason why you think WebFinger should
> 3) HTTPS or HTTP... leave the decision up to the server and client depending on their own specific needs. Servers can enforce the use of https if that server deems it necessary. Likewise, clients can choose to use https or http if it deems it necessary.
>  
> - James
> 
> 
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger
> 
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

---

From: Mike Jones <[email-masked]>
Date: Wed, 5 Dec 2012 18:05:29 +0000

1) HTTPS only

It prevents the downgrade attacks that would otherwise certainly happen.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: Wednesday, December 05, 2012 6:59 AM
To: [email-masked]
Cc: Murray S. Kucherawy
Subject: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP

During the last couple of weeks there has been a lot of mail discussing whether WebFinger MUST support HTTPS only or instead it should be allowed for WebFinger fallback from HTTPS to HTTP.
There are people with a clear preference (sometime strong) one way or the other, but also people that are more flexible and also having a preference could live with the other.

However the discussion so far has not produced any clear consensus the editor can include in the next version of the wg draft.

1) HTTPS only

versus

So please provide your preference and if you want also the reason why you think WebFinger should adopt that particular solution.

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 05 Dec 2012 14:45:27 -0500

2)

The attacks that have people concerned are only important for a certain 
class of applications, which can easily specify HTTPS-only separately.

Explicitly supporting HTTP allows for experimentation and low-security 
applications. HTTPS can cause increased costs for small community and 
individual Web sites -- not only for the cert, but also for additional 
infrastructure. HTTPS is rarely supported for shared-hosting systems.

As a Webfinger library developer for node.js, I appreciate the security 
concern and will be happy to include configuration flags to prevent 
fallback to HTTP if needed by the client.

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [email-masked] P: +1-514-554-3826

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 05 Dec 2012 14:49:10 -0500

I also think there's a logical inconsistency in the argument that a) 
nobody needs plain-old HTTP but b) if plain-old HTTP fallback is 
allowed, it will be so popular that high-security applications will have 
no choice but to use libraries that default to fallback.

-Evan

On 2012-12-05 14:45, Evan Prodromou wrote:
> 2)
>
> The attacks that have people concerned are only important for a 
> certain class of applications, which can easily specify HTTPS-only 
> separately.
>
> As a Webfinger library developer for node.js, I appreciate the 
> security concern and will be happy to include configuration flags to 
> prevent fallback to HTTP if needed by the client.
>
> -Evan
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 11:59:16 -0800

I don't believe that's the security argument.

I understand it more as:  If we mandate complexity (in the spec), we will
get complexity (in clients, per the spec), and in complexity lies security
problems (clients not having HTTPS-only modes).

Whereas if we say "HTTPS-only" in the spec, it will lead to simpler clients
lacking options which are then secure-by-default.

On Wed, Dec 5, 2012 at 11:49 AM, Evan Prodromou <[email-masked]> wrote:

> nobody needs plain-old HTTP but b) if plain-old HTTP fallback is allowed,
> it will be so popular that high-security applications will have no choice
> but to use libraries that default to fallback.
>
> -Evan
>
>

---

From: John Panzer <[email-masked]>
Date: Wed, 5 Dec 2012 13:29:39 -0800

+1 on #1

-1 on #2

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 00:02:53 +0100

> lacking options which are then secure-by-default.

Except that the clients are _not_ secure just because they use HTTPS. 
Especially if they're of the "simpler" kind.

Anyone supporting the HTTPS-only alternative because it's 
"secure-by-default" or similar, PLEASE explain how I as a CAcert.org 
user would be able to serve any data at all to the majority of WF 
clients "secure-by-default", if they do not have the CAcert root 
certificate installed.

Are the posters here supporting https-only of the opinion that any 
non-verifiable HTTPS connection should ABORT and return an error?! Then 
what should my clients do, that don't have have any Verisign, GoDaddy or 
Comodo certificates to validate against?

The "complexity" problem that some say arises is easily solved in 
libraries by serving metadata in returned objects with some kind of 
"verified"/"secure" flag that is either true or false. Something which 
should be part of best practice response handling anyway 
(certificate/validity assertion).

So if we were to suddenly ignore unverifiable certificate signatures, 
there's no reason to use HTTPS at all. It's better to let the server 
decide whether to allow non-HTTPS connections for its specific data - 
and have the client _prefer_ HTTPS and allow use of HTTP for 
non-sensitive data.

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

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 15:12:14 -0800

On Wed, Dec 5, 2012 at 3:02 PM, Mikael Nordfeldth <[email-masked]> wrote:

> "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user
> would be able to serve any data at all to the majority of WF clients
> "secure-by-default", if they do not have the CAcert root certificate
> installed.
>

They wouldn't. Your clients would need to trust CAcert.org.

It's obvious that you don't like the Root CAs, and you're not alone. Nobody
loves the current situation, but they're basically all we've got right now,
considering the continuing sorry state of DNS.

> non-verifiable HTTPS connection should ABORT and return an error?!

Yes.

> Then what should my clients do, that don't have have any Verisign, GoDaddy
> or Comodo certificates to validate against?
>

What do your HTTPS clients currently do?

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 00:48:04 +0100

06.12.2012 00:12 skrev Brad Fitzpatrick:
>> user

So it can also be referred to as the alternative effectively cutting 
off the majority of the internet from using Webfinger properly? How's 
that for hindering adoption. We might as well get XRD back in the game 
or require that only mobile devices produced by fruit-named IT companies 
may use the Webfinger protocol according the specification.

> considering the continuing sorry state of DNS.

So why would we go further down the rabbit hole? HTTP Webfinger 
requests may be fully verifiable via simple methods like GPG signatures 
or any other arbitrary out-of-band communication that users can apply if 
they can't rely on HTTPS automation.

Avoiding the issue of HTTPS/CA design vulnerabilities and restricting 
alternative uses only worsens the situation and does not provide any 
additional security.

> What do your HTTPS clients currently do?

They're StatusNet RFC 6415 clients/servers that work more along the 
lines of a TOFU/POP style of verification ("Trust On First 
Use/Persistence of Pseudonym"). And a somewhat basic user interaction to 
verify the data on first retrieval (accepting subscription).

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

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 16:04:47 -0800

On Wed, Dec 5, 2012 at 3:48 PM, Mikael Nordfeldth <[email-masked]> wrote:

> So it can also be referred to as the alternative effectively cutting off
> the majority of the internet from using Webfinger properly? How's that for
> hindering adoption. We might as well get XRD back in the game or require
> that only mobile devices produced by fruit-named IT companies may use the
> Webfinger protocol according the specification.
>
>
> So why would we go further down the rabbit hole? HTTP Webfinger requests
> may be fully verifiable via simple methods like GPG signatures or any other
> arbitrary out-of-band communication that users can apply if they can't rely
> on HTTPS automation.
>
> They're StatusNet RFC 6415 clients/servers that work more along the lines
> of a TOFU/POP style of verification ("Trust On First Use/Persistence of
> Pseudonym"). And a somewhat basic user interaction to verify the data on
> first retrieval (accepting subscription).

Well, actually, the latest draft didn't specify which Root CAs were
consulted. It just says to verify the certs. Perhaps an HTTPS-only+TOFU
WebFinger client is a conforming client.

I agree that many things are still possible to do securely over HTTP if you
have signing or content-addressability + security elsewhere.  The concern
is that those are all very dorky, theoretical, and seldom-used, and
mandating them would be complicate the spec.  Not specifying HTTPS-only
leaves a lot of people uncomfortable about not knowing how clients (clients
not under their control) will be implemented.

Nothing's perfect... it's always about making trade-offs.  I'm thinking
HTTPS-only is a trade-off, but the one that best maximizes applicability,
simplicity and security, while not grossly harming any of those three.

At the end of the day I've voting +1 for HTTPS-only out of simplicity: one
request for clients.  I don't personally own stock in any Root CA company,
and I'm not a fan of the cert system, but it's better than HTTP to on top
of.

---

From: John Bradley <[email-masked]>
Date: Wed, 5 Dec 2012 21:05:24 -0300

Yes that is exactly what we are proposing.   A client that cannot verify the cert from the WF server should abort.

The use of TLS is mostly to prevent DNS attacks where a client would be tricked into accessing a fake WF server controlled by an attacker,  the transport integrity/encryption is a secondary benefit.

A self signed cert provides no protection for DNS, so is not appropriate, unless the client has the vert configured through some out of band method.

I understand this is not the answer you and others want.

My concern about fallback is that it will be inconsistently interpreted by libraries so common shared libraries are going to be more of a challenge, especially if the spec is precluded from talking about anything other than the wire format.

John B.

On 2012-12-05, at 8:02 PM, Mikael Nordfeldth <[email-masked]> wrote:

> Except that the clients are _not_ secure just because they use HTTPS. Especially if they're of the "simpler" kind.
> 
> Anyone supporting the HTTPS-only alternative because it's "secure-by-default" or similar, PLEASE explain how I as a CAcert.org user would be able to serve any data at all to the majority of WF clients "secure-by-default", if they do not have the CAcert root certificate installed.
> 
> Are the posters here supporting https-only of the opinion that any non-verifiable HTTPS connection should ABORT and return an error?! Then what should my clients do, that don't have have any Verisign, GoDaddy or Comodo certificates to validate against?
> 
> 
> The "complexity" problem that some say arises is easily solved in libraries by serving metadata in returned objects with some kind of "verified"/"secure" flag that is either true or false. Something which should be part of best practice response handling anyway (certificate/validity assertion).
> 
> 
> So if we were to suddenly ignore unverifiable certificate signatures, there's no reason to use HTTPS at all. It's better to let the server decide whether to allow non-HTTPS connections for its specific data - and have the client _prefer_ HTTPS and allow use of HTTP for non-sensitive data.
> 
> -- 
> Mikael Nordfeldth
> http://blog.mmn-o.se/
> [email-masked]
> +46705657637

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 16:07:37 -0800

+1 to #1 (HTTPS-only)

It keeps clients simpler (just one HTTP request), and provides better
security than none (even if it's not ideal).

---

From: John Panzer <[email-masked]>
Date: Wed, 5 Dec 2012 16:08:37 -0800

This is outside the scope of Webfinger, but:  Add
/.well-known/host_public_key to your servers,read it at first retrieval for
that host and add to trust chain for that host before your first Web finger
call, and then use https-only web finger.  Its a tiny bit more work and not
the most secure thing in the world but it separates the PKI from the
protocol...

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 01:17:46 +0100

> WebFinger client is a conforming client.

Yes, but my server would be out of reach for anyone else.

> mandating them would be complicate the spec.

I understand what you're getting at, but as I wrote in a previous 
message on this thread, I think it should be stressed that Webfinger 
generally carries public, user-defined data that may be incorrect at the 
source. So the data _itself_ is not necessarily trustworthy. 
http://www.ietf.org/mail-archive/web/webfinger/current/msg00017.html

The (cut-up) quote: "* 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. [...] Most 
WF data will probably be in one way or another verified by end-users 
sooner or later."

Any non-public data transfers will of course implement every single bit 
of verifiable security feasible.

Thus I think my stance is pretty clear on the post linked above 
(msg00017.html), so I probably won't be discussing this specific issue 
anymore. I simply believe the downsides regarding adoptability outweigh 
the trivial issues with voluntary data integrity.

 From what I can see, most people +1 the https-only and I suppose it's 
my democratic duty to sit back and accept that I'm a minority after 
having said my part.

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

---

From: Nick Jennings <[email-masked]>
Date: Thu, 6 Dec 2012 01:25:22 +0100

No one is taking CPU cycles, network latency, and plain old "get me an
avatar as fast as possible" libraries into account here and it's a
little worrying that we only have 2 options, both of which require at
least a first attempt at HTTPS.

I gave a few good reasons why a developer may want to just use HTTP,
and I don't think it's necessary to mandate that a client needs to
first make an HTTPS call in order to be compliant.

If you want to make some mandate on client behavior, make it that they
have to provide configuration options to allow for HTTP, HTTPS and
both (with HTTPS first, then fallback to HTTP). You can make HTTPS ->
HTTP the default even. But I think developers should be able to use
HTTP only if they want to, and I think there's good reason for them to
want to in many cases.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 16:29:28 -0800

On Wed, Dec 5, 2012 at 4:17 PM, Mikael Nordfeldth <[email-masked]> wrote:

> I understand what you're getting at, but as I wrote in a previous message
> on this thread, I think it should be stressed that Webfinger generally
> carries public, user-defined data that may be incorrect at the source. So
> the data _itself_ is not necessarily trustworthy.
> http://www.ietf.org/mail-**archive/web/webfinger/current/**msg00017.html<http://www.ietf.org/mail-archive/web/webfinger/current/msg00017.html>
>
> The (cut-up) quote: "* 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. [...] Most WF data
> will probably be in one way or another verified by end-users sooner or
> later."
>

That's one use case.  But here's another:  what if the server wants to
advertise the user's OpenID end-point?  The existence of WebFinger clients
in the world that may be trying HTTP after HTTPS' failure means that the
server (say, doing both WebFinger and OpenID on HTTPS-only) has little
confidence that its users aren't getting impersonated around the web by
unknown third-parties on unknown third-party websites (using said
HTTP-permitting WebFinger client), and getting MITMed by somebody breaking
port 443, forcing a downgrade to HTTP, confusing the third-party site, and
then pointing at their rogue OpenID server instead asserting whatever they
want.  Meanwhile the good HTTPS-only host never saw a single packet.

That's why people want HTTPS-only end-to-end, despite the additional
annoyance it'll cause to some servers for some use cases.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 16:32:45 -0800

> least a first attempt at HTTPS.

FWIW, CPUs are remarkably faster and HTTPS involves fewer round-trips than
when these WebFinger conversations started in ~2006.

The "HTTPS is slow" argument is a little dated.

---

From: Nick Jennings <[email-masked]>
Date: Thu, 6 Dec 2012 01:42:55 +0100

> The "HTTPS is slow" argument is a little dated.

I wasn't actually making the "HTTPS is slow" argument. If you read my
posts you'd see I was actually talking about CPU cycles more in
relation to battery drainage on mobile devices, as well as network
latency in non-metro areas (I have trouble with HTTPS on my android
phone here in Prague, which has decent service overall, it can simply
not work in other parts of the country).

I was also talking about page with hundreds or thousands of posts -
using HTTPS could make a difference.

Why not give the option for client sites to decide how they want to
load their data? If I'm a developer and I want to load a bunch of
avatars, and that's it, I'd much rather do an HTTP -> HTTPS fallback
rather than the other way around.

So not only are we saying "everyone needs to buy SSL certs" we're
saying "everyone needs to be in first world countries", "that's too
bad about your battery-life drainage", and the one I really don't
understand: "we're worried you (the potential future developer) are
going to make a crappy WF client that we'll somehow be forced to use"

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 01:49:11 +0100

06.12.2012 01:29 skrev Brad Fitzpatrick:
> advertise the user's OpenID end-point?
>
> [description of how https server may never be queried and clients get 
> tricked]
>

The said client is obviously a badly programmed client. My 
recommendation to anyone in this situation is to stop using services 
that trust non-verified data for user identification.

There will be TONS of badly programmed webfinger clients anyway that 
simply don't verify the connection. Not verifying HTTPS connections is 
the default behaviour in many url/http[s] libraries. I don't see how 
some words in a specification would make these insecurely developed 
applications disappear.

I believe the recommended behaviour in a situation like the one above 
is quite strongly defined with the wording in section 9 of draft 07:

    While Section 5.1 allows for clients that fail to establish an HTTPS
    connection to attempt a query using HTTP, a client and any 
underlying
    client libraries are not required to re-issue queries using HTTP and
    SHOULD NOT when security for a given application that uses WebFinger
    is paramount.

Maybe it can be refined to say something about not ever doing anything 
that will be used as anything security or privacy related. But honestly 
I think it would not have an effect on the ones who end up doing these 
bad security designs at all. The only way to stop them is to stop using 
their services.

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

---

From: John Panzer <[email-masked]>
Date: Wed, 5 Dec 2012 16:53:23 -0800

Apropos: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

On Wed, Dec 5, 2012 at 4:32 PM, Brad Fitzpatrick <[email-masked]>wrote:

> On Wed, Dec 5, 2012 at 4:25 PM, Nick Jennings <[email-masked]>wrote:
>

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 01:58:41 +0100

> least a first attempt at HTTPS.

I for one "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)"

as posted in 

Just wanted to let you know you're not alone in trusting the clients to 
do the right thing - and simply stop using clients (as an end-user) that 
don't respect your privacy in cases of sensitive data transfers.

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 06 Dec 2012 10:01:57 +0900

I strongly prefer 2), for very similar reasons as those outlined below.

Regards,   Martin.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 17:05:50 -0800

On Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth <[email-masked]> wrote:

> The said client is obviously a badly programmed client. My recommendation
> to anyone in this situation is to stop using services that trust
> non-verified data for user identification.
>
> simply don't verify the connection. Not verifying HTTPS connections is the
> default behaviour in many url/http[s] libraries. I don't see how some words
> in a specification would make these insecurely developed applications
> disappear.
>
>
> I believe the recommended behaviour in a situation like the one above is
> quite strongly defined with the wording in section 9 of draft 07:
>
>    connection to attempt a query using HTTP, a client and any underlying
> that will be used as anything security or privacy related. But honestly I
> think it would not have an effect on the ones who end up doing these bad
> security designs at all. The only way to stop them is to stop using their
> services.

Agreed.  But sometimes it's hard to know who sucks until it's too late.
(e.g. all these leaked password databases in plain text or with unsalted
hashes....)

Ignoring security, though, the thing I like most about HTTPS-only is that
it's one request instead of two.

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 05 Dec 2012 20:07:51 -0500

If it's as easy to implement HTTPS as everyone seems to think, then even 
with fallback it will always be just one request.

-Evan

On 12-12-05 08:05 PM, Brad Fitzpatrick wrote:
> On Wed, Dec 5, 2012 at 4:49 PM, Mikael Nordfeldth <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         [description of how https server may never be queried and
>         clients get tricked]
>
>
>     recommendation to anyone in this situation is to stop using
>     services that trust non-verified data for user identification.
>
>     There will be TONS of badly programmed webfinger clients anyway
>     that simply don't verify the connection. Not verifying HTTPS
>     connections is the default behaviour in many url/http[s]
>     libraries. I don't see how some words in a specification would
>     make these insecurely developed applications disappear.
>
>
>     I believe the recommended behaviour in a situation like the one
>     above is quite strongly defined with the wording in section 9 of
>     draft 07:
>
>     Maybe it can be refined to say something about not ever doing
>     anything that will be used as anything security or privacy
>     related. But honestly I think it would not have an effect on the
>     ones who end up doing these bad security designs at all. The only
>     way to stop them is to stop using their services.
>
>
> Agreed.  But sometimes it's hard to know who sucks until it's too 
> late. (e.g. all these leaked password databases in plain text or with 
> unsalted hashes....)
>
> Ignoring security, though, the thing I like most about HTTPS-only is 
> that it's one request instead of two.
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 5 Dec 2012 17:16:34 -0800

> not work in other parts of the country).

Is your provider blocking HTTPS?

> using HTTPS could make a difference.

Presumably many of requests will re-use cached connections.

> rather than the other way around.

I'd prefer no fallback in either direction.

> So not only are we saying "everyone needs to buy SSL certs"

I've never bought one... the free StartCom ones have always worked for me.

> we're
> saying "everyone needs to be in first world countries",

That's a stretch.  How?

> "that's too
> bad about your battery-life drainage",

The screen and the radio staying in one of the lower-power RRC states tends
to be way more important than CPU on mobile devices.  Doing any sort of
fallback in either direction means keeping the radio on for longer.

> and the one I really don't

Discussed in the other threads about people not wanting to be build secure
protocols atop insecure ones.

---

From: Nick Jennings <[email-masked]>
Date: Thu, 6 Dec 2012 02:48:28 +0100

> Is your provider blocking HTTPS?

No, I think it's a latency issue.

> Presumably many of requests will re-use cached connections.

OK, fair enough - though I think the idea of why you may want to just
use HTTP when you can still stands.

> I'd prefer no fallback in either direction.

I totally agree with you here, except that I think it would be easier
for the developer of the client library to go ahead and implement the
fallback (optional) rather than having developers who use the library
have to implement their own fallback for the cases where they need to
do so. Unless we require HTTPS only, it's a fact that some providers
will only offer one or the other for various reasons.

That said, should we really get into whether or not a client library
should implement fallback? You say you'd prefer not, so you'd probably
use a client library that allows you to turn it off.

I could see a reason to make it HTTPS with no fallback by default.
With the option to enable HTTP fallback, or HTTP only, depending on
your use-case. I would imagine most of the time people would configure
their client library to be HTTPS with HTTP fallback, to try to ensure
they'll get a successful callback with some data they can use.

> I've never bought one... the free StartCom ones have always worked for me.

Thanks for that link (last week?), I got one and set it up on my
server after you mentioned it. This is great, as far as I know it's
the only one out there providing free certs.

Still, I think most people will feel they have to buy a cert and so
not bother to implement WF because SSL is required and they don't want
to drop $60+/year just to be able to participate.

>> saying "everyone needs to be in first world countries",

I meant in reference to poor network coverage on mobile networks, or
rural areas, underdeveloped countries. But yeah, you're right, it is a
stretch.

> fallback in either direction means keeping the radio on for longer.

Good point. Unless the client is using WF for some security related
process, auth or whatever, then it would make sense for them to only
use HTTP.

> protocols atop insecure ones.

Yeah, I think I'm missing the point here. I don't know why there seems
to be a concern about people writing poor clients that they are
somehow forced to use (or don't know better). If you're writing an
authentication library you better know what you're doing, and if you
make use of someone else's WF library, you better know what it's
doing.

---

From: Randall Leeds <[email-masked]>
Date: Wed, 5 Dec 2012 20:00:26 -0800

> https or http if it deems it necessary.

I'll +1 this third option.

It seems abundantly clear that some strongly want HTTP to be supported
while some strongly want to ensure that their use will never use HTTP (as a
fallback, or at all), but I just don't see the value in specifying that
behavior. Implementors and users of WF will sort it all out.

Public, "trivial" metadata server? Accept HTTP requests.

Writing an authentication flow into your application? Use HTTPS when
connecting.

If I were to design a library tomorrow, I would probably require the user
to specify which should be used. If I were feeling strongly that things
should be as simple as possible to play with, I might make it optional and
default to HTTP (no hassle, no certs, and one can play with client
libraries and IdP code locally, etc). I probably wouldn't implement any
fallback at all! The application can simple call my library again and
change the parameter.

The point is that the least surprising thing to me would be to pick one,
but give the user an option. That's what any caring library author should
do, IMO. Automatic fallback is useless magic. I suspect many authors trying
to craft a general-use WF library would come to a similar conclusion.

In the end we will have libraries that are as flexible or strict as their
users need them to be, but the spec doesn't need to go there.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 06 Dec 2012 14:12:35 +0900

On 2012/12/06 13:00, Randall Leeds wrote:
> On Wed, Dec 5, 2012 at 9:04 AM, James M Snell<[email-masked]>  wrote:

>> On Wed, Dec 5, 2012 at 6:58 AM, Salvatore Loreto<

> I'll +1 this third option.

That option would be fine with me, too.

Regards,   Martin.

---

From: William Mills <[email-masked]>
Date: Wed, 5 Dec 2012 21:51:53 -0800 (PST)

I'm in the  #1 or #3 but not #2 camp.

>________________________________
> From: ""Martin J. Dürst"" <[email-masked]>
>To: Randall Leeds <[email-masked]> 
>Cc: Salvatore Loreto <[email-masked]>; [email-masked]; James M Snell <[email-masked]>; Murray S. Kucherawy <[email-masked]> 
>Sent: Wednesday, December 5, 2012 9:12 PM
>Subject: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP
>

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 06 Dec 2012 10:31:14 +0100

On tor   6 dec 2012 06:12:35, "Martin J. Dürst" <[email-masked]> wrote:

> > > depending on their own specific needs. Servers can enforce the use
> > > of https if that server deems it necessary. Likewise, clients can
> > > choose to use https or http if it deems it necessary.
> > > 
> > 

Yes. The third option is my favorite.
It does not assume developers can be fixed by just giving them a more restrictive toolkit.

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Thu, 06 Dec 2012 09:38:11 +0000

> Yes, but my server would be out of reach for anyone else.
how about keeping it HTTPS only just to cut off very basic threats and at the same time make a informative reference to work done on supporting CAcert and other autonomous CAs? i would expect that for now people would use *mainstream* CAs and just get certs from StartSSL which don't require payment with money, but in a long run we can start facing this issue in a systematic way. one day we need to fix this CA problem anyhow :)

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Thu, 06 Dec 2012 09:38:46 +0000

+1 HTTPS only

---

From: Nick Jennings <[email-masked]>
Date: Thu, 6 Dec 2012 11:37:04 +0100

On Thu, Dec 6, 2012 at 7:56 AM, Joseph Holsten <[email-masked]> wrote:
> On Dec 5, 2012, at 13:26, Nick Jennings <[email-masked]> wrote:
>
>> On Wed, Dec 5, 2012 at 8:59 PM, Brad Fitzpatrick <[email-masked]> wrote:
>> Although I like the idea of keeping it simple and secure by default,
>> I'm starting to lean on the side of *both* being optional. The more I
>> think about it, the more it really should be the decision of the
>> client library, not the server, as to what type of query they are
>> going to make. The server can, of course, restrict HTTP requests if
>> it's serving sensitive data.
>
> As an implementor, you've gone from two test cases (success via https in secure mode, failure to discover) and added three more (success via https in insecure mode, sucess via http fallback in insecure mide, and failure via http fallback in https only mode) that I have to test.
>

Are you talking about the library itself or the user of the library?
In the case of the library, you don't really have to 'test' for
whether the success was via https or http as long as we are not
supporting downgrading (which I don't think we should).

>From the perspective of the user of the library, you'd specify your
requirements when initializing the library.

> That's not counting the myriad  redirects, timeouts, retries and caching that a mature client requires.

Retries and timeouts would definitely suck when having to consider a
'fallback' option in the library. Though you don't have to implement a
fallback. In which case, the client implementation would be no
different if we go with option #3

>> By forcing HTTPS, or even requiring it as the initial query, we're not
>> allowing the client library to be optimized for it's task. There are
>> performance hits, and if you multiply that for situations where the
>> client app may need to make hundreds or thousands of requests, that becomes a valid consideration.
>
> If you're talking about thousands of requests in any small amount if time, and you're afraid of the processing and latency https adds, you basically aren't mature enough to be calling any external SaaS. Much less calling twitter, facebook, google plus, or any other social network for their data.

I was actually talking about browser-side requests (since we specify
the need for CORS headers), not server-side. So it has nothing to do
with my "maturity" ... though now that you mention it, I guess I
should get a job. :)

> I work at a social media analytics company. We pull large quantities ad this kind of data all day long. And we've had to build frustratingly complex exception handling, retrying, timeouts and scheduling into our data collectors to get deal with these APIs that are officially blessed by the social networks in question. Do you think the same SLAs will apply to an insecure, public data only, weird discovery protocol that isn't core to their business?
>
> And you think a shop should be afraid of https?

Afraid? Absolutely not. I was just bringing up the point that some
situations (ie. web apps) may want to optimize as best they can. If
the data is trivial, why not use HTTP.

> And another thing. Latency?  You're making an https request first, waiting for connect() to time out, then making an http request, right? Or are you calling http directly, then getting redirected to https on sites that require it? Which particular latency should my client library be trying to avoid?

I meant the additional latency of the HTTPS protocol itself (more
noticeable on high latency mobile networks). I wasn't referring to
fallback.

> Also, please stop thinking of this as just a spec. This isn't us agreeing to a spec. This is agreeing to how we want our implementations to work together, and writing it down. If you weren't interested in actually creating working code, why would anyone be interested in achieving rough consensus with you?

What ever gave you the impression that I'm not interested in creating
working code? In fact that's exactly why I became involved in
WebFinger, it's a key part of the current projects I work on in the
open-source world, and could potentially be adopted, in some form, at
the companies where I manage development and technology decisions. I
see WebFinger as a crucial piece of most of my development moving
forward.

That said, I was merely bringing up holes I saw in the HTTPS-only
boat, which I've also been in this past week. I'm not so sure anymore,
option #3 sounds good for adoption and allowing for more use-cases,
but I would go with #1 if that was the consensus. I definitely don't
like #2.

-Nick

---

From: Nick Jennings <[email-masked]>
Date: Wed, 5 Dec 2012 22:26:39 +0100

If I'm an auth library of some sort, I'm going to use HTTPS only to
make my queries. If the server does not support HTTPS, then the server
obviously isn't prepared to handle auth-related topics.

If I'm a library used for blog comment avatars/basic info, I'm going
to use HTTP pretty much exclusively because I don't want the increased
latency and processing power involved with establishing encrypted
sessions for every single comment on the page.

If I'm a mobile app and the data I need to query is not sensitive,
again I'm going to prefer HTTP because of the latency and processing
power (battery life and unreliable internet connectivity).

By forcing HTTPS, or even requiring it as the initial query, we're not
allowing the client library to be optimized for it's task. There are
performance hits, and if you multiply that for situations where the
client app may need to make hundreds or thousands of requests, that
becomes a valid consideration.

-Nick

---

From: Joseph Holsten <[email-masked]>
Date: Wed, 5 Dec 2012 22:56:25 -0800

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 12 Dec 2012 10:58:06 +0100

I would also +1 for option 3.

We've seen during the last year now many distinct use cases that favor either https and/or http. As a generic ietf framework webfinger should simply clarify the risks implied by using plain http in a sort of "how-to" guide based on the most popular usages of wf.
The spec may say at most that clients SHOULD attempt HTTPS first but it may not be always feasible (see the mobile network use case). Servers as well SHOULD expose webfinger over HTTPS but may have very good reasons not to do so (due to certification complexity for small sites and/or simply because the released information is intended for public use)

It should be up to specific contexts/specs to "profile" the webfinger spec by promoting a specific flow (https-only, fallback, etc) eg OMA SNEW, OpenID Connect or the single Social Entreprise software implementations.

walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Mikael Nordfeldth
> Inviato: giovedì 6 dicembre 2012 10.31
> A: Martin J. Dürs; Randall Leeds
> Cc: Salvatore Loreto; [email-masked]
> Oggetto: Re: [webfinger] Consensus call: HTTPS only vs HTTPS-and-HTTP
>

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Mikael Nordfeldth <[email-masked]>
Date: Wed, 12 Dec 2012 11:26:36 +0100

06.12.2012 10:38 skrev ☮ elf Pavlik ☮:
> how about keeping it HTTPS only just to cut off very basic threats
> and at the same time make a informative reference to work done on
> supporting CAcert and other autonomous CAs?

HTTPS won't make bad programmers less bad. Thus the basic threats will 
be just as real with or without it.

Given that the suggested behaviour for HTTPS-only is to _ignore_ 
unverified certificates, I believe CAcert etc. will have a _harder_ time 
catching on than in an environment where HTTP/unverified HTTPS is 
flagged "not verified".

Either way, there's also a huge risk of software being _less_ secure if 
it assumes HTTPS traffic is always Good(tm) just because the server 
signature is validated.

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

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 Dec 2012 17:48:22 +0200

<with the wg chair hat on>

Even if the consensus call will formally end tomorrow I have to say that 
so far I don't see any consensus,
the wg participants are divided almost equally in two camps one that is 
for HTTPS only
and the other one that want to have the possibility to use both HTTP and 
HTTPS.
What I can see clearly is only that the wg does not like the proposal #2 
"HTTPS + HTTP but only as fallback".

So for the sake of making progress
I want to propose a compromise solution that while it will allow to use 
both at same time
will try to reduce at the minimum the security risks to have both;
in particular it tries to reduce the risk that can come from an 
automatic fall back from HTTPS to HTTP.
With this proposal of course you have to accept and live with the fact 
that the client will be "more complicated"
as it has to support both.
Here is the idea and the proposed text for it:

    Clients MAY issue a query to the WebFinger server using either HTTPS
    or HTTP,
    but MUST NOT attempt to use both, either serially or in parallel.
    The choice of transport protocols depends on the client's security
    requirements,
    though use of HTTPS is RECOMMENDED in most situations.

    If a query is issued using HTTPS and the server has an invalid
    certificate,
    the client MUST accept that the WebFinger query has failed.

    WebFinger servers operating on HTTP MAY redirect a client using HTTP
    status codes
    301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST
    follow the redirection,
    issuing a query to the URI in the Location header.
    Likewise, WebFinger servers operating on HTTPS MAY redirect a client
    to another HTTPS URI
    and the client MUST follow the redirection. However, WebFinger
    servers operating on HTTPS
    MUST NOT redirect a client to an HTTP URI.

so please provide your comments, feedback on this compromise solution 
and also state clearly if you support it or not

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: James M Snell <[email-masked]>
Date: Wed, 12 Dec 2012 08:20:08 -0800

+1... this is excellent.

On Wed, Dec 12, 2012 at 7:48 AM, Salvatore Loreto <
[email-masked]> wrote:

> in particular it tries to reduce the risk that can come from an automatic
> fall back from HTTPS to HTTP.
> Clients MAY issue a query to the WebFinger server using either HTTPS or
> HTTP,
> The choice of transport protocols depends on the client’s security
> requirements,
> Likewise, WebFinger servers operating on HTTPS MAY redirect a client to
> another HTTPS URI
> and the client MUST follow the redirection. However, WebFinger servers
> operating on HTTPS
> so please provide your comments, feedback on this compromise solution and
> also state clearly if you support it or not
>
> best regards
> Salvatore
>
>
>
> Salvatore Loreto, PhDwww.sloreto.com
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 Dec 2012 11:37:03 -0500

Hi Salvatore,

> though use of HTTPS is RECOMMENDED in most situations.

OK.

> the client MUST accept that the WebFinger query has failed.

I don't see how you can enforce this. Often times certificate checking is 
done at a layer below the application code - a user may have previously 
"accepted" an invalid certificate for a particular domain and in that case 
subsequent application layer HTTPS connections can succeed without any kind 
of "invalid certificate" notification.

A better statement is:

    If client security requirements require the use of HTTPS, then
    clients MUST use HTTPS and MUST NOT fall back to  HTTP connections
    either as a result of internal failure handling or as a result of a
    server-redirect.

I think my proposed text is something clients can reasonably and reliably 
do.

> 301, 302, or 307 to another HTTP or an HTTPS URI and the client MUST

Don't quote specific response codes - new redirect codes can be defined 
(e.g. 308: 
<https://datatracker.ietf.org/doc/draft-reschke-http-status-308/>)

> and the client MUST follow the redirection.

I am not sure we should enforce "MUST follow the redirection". First off 
redirect behavior is built into HTTP so there is no need to repeat any 2119 
language. Second, there may be additional client security requirements that 
restrict what sources it is willing to trust and the client should be 
allowed to reject a redirect to an untrusted source.

> However, WebFinger servers operating on HTTPS

The last requirement "servers MUST NOT redirect HTTPS to HTTP" needs to be 
backed up by a statement on the client side that "clients MUST NOT follow 
HTTPS to HTTP redirects" (which is what I included in my proposal above).

Also, this behavior seems like it might be applicable to more than just 
webfinger apps. Apps with similar security/trust requirements probably 
exist, so shouldn't this behavior perhaps be rolled into something the 
Websec WG should work on?

-- 
Cyrus Daboo

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 Dec 2012 12:02:59 -0500

Cyrus,

> > or HTTP,  but MUST NOT attempt to use both, either serially or in
> > parallel.
> > requirements, though use of HTTPS is RECOMMENDED in most situations.
> 
> OK.
> 
> > certificate, the client MUST accept that the WebFinger query has
> > failed.
> 
> I don't see how you can enforce this. Often times certificate checking
> is done at a layer below the application code - a user may have
> previously "accepted" an invalid certificate for a particular domain and
> in that case subsequent application layer HTTPS connections can succeed
> without any kind of "invalid certificate" notification.

That might be true if the transport layer below the WF client has been configured by the user to ignore certificate errors and the client code is oblivious to this fact.  We cannot fix that, but we can at least provide guidance to those who do have some control over the transport or when there is an error.
 
> I think my proposed text is something clients can reasonably and
> reliably do.

This does not address your stated concern with certificates.  This is more-or-less a re-wording of the first paragraph in Sal's message.  Personally, I would prefer to not introduce the words "fall back", because there is "fall back" concept in WebFinger.  A client may use HTTPS or HTTP.  So, what's written now is:

    Clients MAY issue a query to the WebFinger server using either
    HTTPS or HTTP, but MUST NOT attempt to use both, either serially
    or in parallel.  The choice of transport protocols depends on the
    client’s security requirements, though use of HTTPS is RECOMMENDED
    in most situations.
 
> > status codes 301, 302, or 307 to another HTTP or an HTTPS URI and the
> > client MUST
> 

That's probably a good idea.  Should we say "status codes 3xx"?  How is this usually phrases?
 
> > to another HTTPS URI and the client MUST follow the redirection.
> 
> redirect behavior is built into HTTP so there is no need to repeat any
> 2119 language. Second, there may be additional client security
> requirements that restrict what sources it is willing to trust and the
> client should be allowed to reject a redirect to an untrusted source.

Redirection behavior is defined in 2119 and this does not re-define it.  It just says "do it".  We can soften that word to "SHOULD".  Does that help?  Clearly, barring any good reason to not redirect, a client SHOULD adhere to a redirection request.
 
> > However, WebFinger servers operating on HTTPS MUST NOT redirect a
> > client to an HTTP URI.
> 
> The last requirement "servers MUST NOT redirect HTTPS to HTTP" needs to
> be backed up by a statement on the client side that "clients MUST NOT
> follow HTTPS to HTTP redirects" (which is what I included in my proposal
> above).

How about this additional sentence?

    Further, a client that issues a request using HTTPS MUST NOT
    follow a redirection to an HTTP URI.

Note, though, that a client in a web browser it totally powerless to prevent that from happening.
 
> Websec WG should work on?

Probably.  I asked Sal a similar question.  That said, we don't want to hold up the WF spec.  Somebody interested in generalizing such security recommendations should write an RFC that future specs can reference.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 12 Dec 2012 12:42:15 -0500

Typos...

> That might be true if the transport layer below the WF client has been
> configured by the user to ignore certificate errors and the client code
> is oblivious to this fact.  We cannot fix that, but we can at least
> provide guidance to those who do have some control over the transport or
> when there is an error.

"for when there is an error"

> This does not address your stated concern with certificates.  This is
> more-or-less a re-wording of the first paragraph in Sal's message.
> Personally, I would prefer to not introduce the words "fall back",
> because there is "fall back" concept in WebFinger.  A client may use
> HTTPS or HTTP.  So, what's written now is:

"there is no "fall back" concept"

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 12 Dec 2012 19:40:02 +0100

+1. In general i would be careful/pragmatic when using MUST NOT on the client side.
As Paul said it may be difficult to prevent some automatic behaviour of http stacks when handling redirects.

But it would also be difficult to prevent a client to issue 2 wf requests in parallel or in sequence. I'm not talking about fallback but simple/stupid behaviour: what would indeed happen if a client do so? I don't think servers would always implement a logic saying that if a client just issued a request on one protocol then I'll recognize the second and reject it. If this is the expected behaviour then the server-side procedure should be clarified. Otherwise such generic statement is unrealistic and should better call out the fallback use case explicitly (eg "clients SHOULD NOT use http as fallback after receiving an error upon an https request for the same resource")

Walter

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 13 Dec 2012 09:58:12 -0500

Hi Paul,

> HTTPS or HTTP.  So, what's written now is:

So I really don't know why the text has to callout the unverified 
certificate error case over any sort of TLS failure. Given that, as you 
say, some clients might have knowledge of it and others not, there is no 
consistent way to give proper advice beyond what general TLS 
recommendations already do.

> That's probably a good idea.  Should we say "status codes 3xx"?  How is

How about the following for the entire paragraph of redirects:

    WebFinger servers operating on HTTP MAY redirect a client using an
    appropriate HTTP status code to another HTTP or an HTTPS URI. Likewise,
    WebFinger servers operating on HTTPS MAY redirect a client to another
    HTTPS URI but MUST NOT redirect a client to an HTTP URI. Further,
    clients MUST NOT follow a redirection from an HTTPS URI to an HTTP URI,
    but SHOULD automatically follow all other server redirects.

-- 
Cyrus Daboo

---

From: Mikael Nordfeldth <[email-masked]>
Date: Thu, 13 Dec 2012 16:13:30 +0100

I very much like the phrasing below by Cyrus Daboo.

Also I fully respect that https must not 3xx redirect to non-encrypted http resources.

>         appropriate HTTP status code to another HTTP or an HTTPS URI.
> to another       HTTPS URI but MUST NOT redirect a client to an HTTP URI.
> Further,       clients MUST NOT follow a redirection from an HTTPS URI to
> an HTTP URI,       but SHOULD automatically follow all other server
> redirects.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 10:47:40 -0500

Cyrus,

> recommendations already do.

I think the reason is that if a client knows the certificate produces an
error, it should not ignore that.  Many clients would know, directly or
indirectly.  At least clients would not try to go around the error with this
language.

The text should call out other errors.  The older text said to assume HTTPS
has issues if:
* A connection cannot be established
* There is an invalid certificate
* HTTP server returns a status code indicating some error (e.g., 4xx or 5xx)

This language was necessary when we had the "fall back" logic.  Now the
proposed text recommends that a client use either HTTP or HTTPS, not both.
So, if the client elects to use HTTPS, the only error condition we really
need to speak to is certificate errors.
 
> Likewise,

This sounds OK, though I think some might ask what an "appropriate" HTTP
status code is.  That's why I suggested using "3xx", since the HTTP spec
uses that language.

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 07:55:29 -0800

> proposed text recommends that a client use either HTTP or HTTPS, not both.

I've yet to understand how this is not going to be totally broken: you're
saying that both the server and the client get to pick HTTP or HTTPS?  That
seems like the most broken thing ever:

HTTPS server & HTTPS client: ok
HTTPS server & HTTP client: FAIL
HTTP server & HTTPS client: FAIL
HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the
server was also running on HTTPS, but the client just got unlucky in which
it picked.

That proposal looks like mostly fail.

If people on this list want to run HTTP servers (which many apparently do),
then we're going to need to push complexity to clients. It's unfortunate,
but it's not going to work otherwise.

Or what am I missing?

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 17:15:58 +0100

> seems like the most broken thing ever:

I agree, I would personally want to run both on my server. Then either
can be used for a varied number of use-cases, where appropriate.

> HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the server
> was also running on HTTPS, but the client just got unlucky in which it
> picked.

If all you're getting is a vcard, name, avatar picture, then who
cares? If you are retrieving sensitive information that could be
dangerous if tampered with, then you're just going to use HTTPS from
the client library.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 08:25:03 -0800

> can be used for a varied number of use-cases, where appropriate.

You agree it's the most broken thing ever.  But because it's the most
broken thing ever, you personally will run servers on both ports. What
about everybody else running a server?

> server

What if I want to say "all links"?  How do I get a mix of secure links and
insecure links?

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 11:41:04 -0500

Brad,

My assumption is that if one runs an HTTPS server, he or she will either respond to either HTTP or HTTPS requests, or redirect HTTP requests to the HTTP server.  So the only scenario that I think is broken is when an HTTPS client issues a request to an HTTP-only server.

In any case, you’re right that there is at least one broken scenario and the only solution is to push that to the client or let it fail.  We tried suggesting use both and people rejected that due to complexity.  The new text recommends use of HTTPS, but HTTP is there because some wanted to use that.  I would expect the “general purpose” WF client to use HTTPS.  But, perhaps “specialized” clients would use HTTP only?

Anyway, yes… this could present issues for some, but primarily for those clients that are HTTPS only.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 10:55 AM
To: Paul E. Jones
Cc: Cyrus Daboo; Salvatore Loreto; [email-masked]
Subject: Re: [webfinger] a compromise proposal about HTTPS only vs HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP)

On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones <[email-masked]> wrote:

I've yet to understand how this is not going to be totally broken: you're saying that both the server and the client get to pick HTTP or HTTPS?  That seems like the most broken thing ever:

HTTP server & HTTP client: ok, but susceptible to MITM, and maybe the server was also running on HTTPS, but the client just got unlucky in which it picked.

If people on this list want to run HTTP servers (which many apparently do), then we're going to need to push complexity to clients. It's unfortunate, but it's not going to work otherwise.

Or what am I missing?

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 09:00:24 -0800

On Thu, Dec 13, 2012 at 8:41 AM, Paul E. Jones <[email-masked]>wrote:

> Brad,****
>
> ** **
>
> My assumption is that if one runs an HTTPS server, he or she will either
> respond to either HTTP or HTTPS requests, or redirect HTTP requests to the
> HTTP server.
>

Rather than assuming, it should be specified as required for servers, but I
don't think we should do that.

So the only scenario that I think is broken is when an HTTPS client issues
> a request to an HTTP-only server.****
>
> ** **
>
> In any case, you’re right that there is at least one broken scenario and
> the only solution is to push that to the client or let it fail.  We tried
> suggesting use both and people rejected that due to complexity.
>

And I think we're compromising on client complexity.  Client simplicity was
a nice bonus effect with HTTPS-only, but the big win was security.

If we're going to allow HTTP, we at least still need security (my
"https:"-prefix secure rel proposal).  We can't also get client simplicity
with HTTPS-and-HTTP.

>   The new text recommends use of HTTPS, but HTTP is there because some
> wanted to use that.  I would expect the “general purpose” WF client to use
> HTTPS.  But, perhaps “specialized” clients would use HTTP only?
>

Seems like that'd be a wart in the spec that nobody knew the definition of
and never worked in practice.  I'm all about making people happy, but I
don't want to put words in a spec that pacify certain people, but don't
actually work in the wild for them.

It reads like "If you're, um, 'specialized', use HTTP? Maybe it'll work
sometimes, in your own little environment, but not with anybody else."

> ****
>
> ** **
>
> Anyway, yes… this could present issues for some, but primarily for those
> clients that are HTTPS only.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Brad Fitzpatrick [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 10:55 AM
> *To:* Paul E. Jones
> *Cc:* Cyrus Daboo; Salvatore Loreto; [email-masked]
> *Subject:* Re: [webfinger] a compromise proposal about HTTPS only vs
> HTTPS-and HTTP (was Re: Consensus call: HTTPS only vs HTTPS-and-HTTP)****
>
> ** **
>
> On Thu, Dec 13, 2012 at 7:47 AM, Paul E. Jones <[email-masked]>
> wrote:****
>
> ****
> ** **
> seems like the most broken thing ever:****
>
> ** **
>
> HTTPS server & HTTPS client: ok****
>
> HTTPS server & HTTP client: FAIL****
>
> HTTP server & HTTPS client: FAIL****
>
> it picked.****
> ** **
> That proposal looks like mostly fail.****
>
> ** **
>
> If people on this list want to run HTTP servers (which many apparently
> do), then we're going to need to push complexity to clients. It's
> unfortunate, but it's not going to work otherwise.****
>
> ** **
>
> Or what am I missing?****
>
> ** **
>

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 19:14:58 +0100

On Thu, Dec 13, 2012 at 6:00 PM, Brad Fitzpatrick <[email-masked]> wrote:
>> a request to an HTTP-only server.
>>

That's what I'm worried about as well. With all this "answering on
HTTP but upgrading to HTTPS" or simply not answering on HTTP... it
defeats the purpose of the initial HTTP request for those use-cases
where it would be beneficial (as I've described before).

If out in the wild, I'm not going to be able to realistically use HTTP
to get public information on a user without a high rate of failures or
HTTPS upgrades, then I'd much rather use HTTPS only.

However, my point was to have servers implement both HTTPS and HTTP
(it's not difficult, afterall) with filtering for HTTP calls. Is that
a possibility or is there no way that will fly?

-Nick