Subject: [apps-discuss] I'm calling this sans-tls bluff

From: Joseph Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 11:23:15 -0800

I don't think this wf-sans-tls issue is an issue to any real, existent person.

I'll bet $50 that you can't find a site operator that has >50 users and would implement webfinger so long as it doesn't require https. 

--
http://josephholsten.com

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 11:45:03 -0800

On 2012-11-29, at 11:26 , Brad Fitzpatrick <[email-masked]> wrote:
> On Thu, Nov 29, 2012 at 11:23 AM, Joseph Holsten <[email-masked]> wrote:
> I'm having a hard time parsing that sentence.
> 
> Rephrase?

If a person on [email-masked] finds me:
- a site operator,
- whose site has > 50 users,
- who would implement webfinger if it allowed HTTP,
- but who will not implement webfinger if it requires HTTPS

I will gladly send $50 USD to that person or a charity of their choice.
--
http://josephholsten.com

---

From: John Panzer <[email-masked]>
Date: Thu, 29 Nov 2012 11:49:55 -0800

That's not the concern I am hearing here.

The concern is that one of those well-behaved sites can still be attacked
via http if we require clients to downgrade to HTTP after an HTTPS
connection fails.

Attack vector:  I intercept communications in your hotel so that all HTTPS
connections fail the first time, and all HTTP connections go through my
service which checks the URI path for /.well-known requests.  Webfinger
client gets initial failure on HTTPS, then retry with HTTP, which goes to
my proxy, which replies with bogus information, sending the client off to
perhaps get the wrong login service or the wrong public key or... This is
totally out of the control of the site operator with >50 users because *they
never saw any requests*.

On Thu, Nov 29, 2012 at 11:45 AM, Joseph Anthony Pasquale Holsten <
[email-masked]> wrote:

> >> I'll bet $50 that you can't find a site operator that has >50 users and
> would implement webfinger so long as it doesn't require https.
> >

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 12:03:57 -0800

I'm sorry, I wasn't clear.

If there is an existing person who has a legitimate need for webfinger to support HTTP-sans-TLS, then I'm okay with leaving webfinger for untrusted information discovery.

Otherwise, webfinger MUST NOT allow HTTP-sans-TLS because no existing person actually wants it.

On 2012-11-29, at 11:49 , John Panzer <[email-masked]> wrote:

> The concern is that one of those well-behaved sites can still be attacked via http if we require clients to downgrade to HTTP after an HTTPS connection fails.
> 
> Attack vector:  I intercept communications in your hotel so that all HTTPS connections fail the first time, and all HTTP connections go through my service which checks the URI path for /.well-known requests.  Webfinger client gets initial failure on HTTPS, then retry with HTTP, which goes to my proxy, which replies with bogus information, sending the client off to perhaps get the wrong login service or the wrong public key or... This is totally out of the control of the site operator with >50 users because they never saw any requests.
> 
> 
> On Thu, Nov 29, 2012 at 11:45 AM, Joseph Anthony Pasquale Holsten <[email-masked]> wrote:

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Nov 2012 15:04:44 -0500

Maybe, but there would be a gazillion smaller sites that might want to
implement WF and that have no need for TLS and who might not even be able to
get TLS working.

If one's use of WF is to find information that is stored on web servers
accessed via HTTP, there is little point in requiring HTTPS to discover that
information.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Joseph Anthony Pasquale Holsten
> Sent: Thursday, November 29, 2012 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [apps-discuss] I'm calling this sans-tls bluff
> 
> >> I'll bet $50 that you can't find a site operator that has >50 users
> and would implement webfinger so long as it doesn't require https.
> >
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 15:21:30 -0500

Well, that's easy enough: me.

Paypal your $50 to [email-masked].

-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: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 12:28:54 -0800

That's sad Evan. I'm sending now.

You haven't been particularly vocal on this thread though. Mind telling us why you want webfinger to be impossible to secure? Surely you can afford to run TLS.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2012 16:50:18 -0300

I agree that server certificates are essentially free now (thanks Eddy Nigg).

The problem is for the small hosting providers who need to support SNI because they don't have dedicated IP addresses.
Those hosted domains won't be able to host there own WF domains.

Personally I think clients using WF without authenticating the host they are talking to make WF less trustworthy and valuable.

Having WF clients support fallback from TLS adds complexity.  I would prefer to see WF TLS only and if not http only (the server can always redirect to TLS if it wants.)

I am for picking one and reducing security and interoperability issues.

However that decision drives what WF is used for at the end of the day.

John B.

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 15:53:23 -0500

I disagree with the premise. I don't think it's impossible to use 
Webfinger securely if it's possible to use Webfinger insecurely. Just 
say, "For this application, only use HTTPS."

But, quickly: StatusNet makes Open Source social network software. Our 
customers have small-to-medium-sized networks. We use RFC 6415 for 
endpoint discovery to enable social connections across domains.

I really like the idea of suggesting that clients require HTTPS for some 
implementations, but many of my users won't be able to implement.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 29 Nov 2012 15:59:23 -0500

But, hey: I'm going to return your money. I realized after writing this 
that I'd be OK with falling back to RFC 6415 if needed.

If there's a proposal to make Webfinger HTTPS-only, I won't oppose it.

Having exactly one endpoint for Webfinger would actually be pretty 
useful for clients.

-Evan

On 12-11-29 03:53 PM, Evan Prodromou wrote:
> I really like the idea of suggesting that clients require HTTPS for 
> some implementations, but many of my users won't be able to implement.
>
> -Evan
>
>> You haven't been particularly vocal on this thread though. Mind 
>> telling us why you want webfinger to be impossible to secure? Surely 
>> you can afford to run TLS.
>>

---

From: Joseph Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 13:20:30 -0800

Well that $50 is back on the table for anyone else opposed to HTTPS-only. 

--
http://josephholsten.com

On Nov 29, 2012, at 12:59, Evan Prodromou <[email-masked]> wrote:

> But, hey: I'm going to return your money. I realized after writing this that I'd be OK with falling back to RFC 6415 if needed.
> 
> Having exactly one endpoint for Webfinger would actually be pretty useful for clients.
> 
> -Evan
> 
>> I disagree with the premise. I don't think it's impossible to use Webfinger securely if it's possible to use Webfinger insecurely. Just say, "For this application, only use HTTPS."
>> 
>> But, quickly: StatusNet makes Open Source social network software. Our customers have small-to-medium-sized networks. We use RFC 6415 for endpoint discovery to enable social connections across domains.
>> 
>> I really like the idea of suggesting that clients require HTTPS for some implementations, but many of my users won't be able to implement.
>> 
>> -Evan
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Nov 2012 17:02:31 -0500

I think that there will be plenty that will implement Webfinger without TLS
regardless of whether this is a MUST, SHOULD, MAY or MUST NOT.

I think that all HTTP should run over at least one secure transport at all
times. Ideally there should be confidentiality at BOTH the IPSEC and the
TLS levels and authentication and integrity checks at BOTH the TLS and HTTP
levels.

The security properties are very different.

What is worrying me here is that mandating TLS has become the new firewall
fetish. Using a firewall doesn't make you any safer unless you know what
you are trying to achieve.

When people are saying we MUST use TLS and MUST ensure that client side
javascript can make Webfinger lookups, I see a disaster looming.

-- 
Website: http://hallambaker.com/

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 14:03:22 -0800

On Thu, Nov 29, 2012 at 12:53 PM, Evan Prodromou <[email-masked]> wrote:
> I disagree with the premise. I don't think it's impossible to use Webfinger
> securely if it's possible to use Webfinger insecurely. Just say, "For this
> application, only use HTTPS."

You are free to disagree, but that doesn't change the facts. If the
client will fallback to HTTP, the server can do nothing to protect
that client. If by client you mean popular implementations in open
source libraries, then the server cannot protect most users.

> customers have small-to-medium-sized networks. We use RFC 6415 for endpoint
> discovery to enable social connections across domains.
>
>> You haven't been particularly vocal on this thread though. Mind telling us
>> why you want webfinger to be impossible to secure? Surely you can afford to
>> run TLS.
>>

-- 
--Breno

---

From: Breno de Medeiros <[email-masked]>
Date: Thu, 29 Nov 2012 14:07:18 -0800

> regardless of whether this is a MUST, SHOULD, MAY or MUST NOT.

I agree. That's why I don't see any benefit in not placing a MUST in
the spec language.

There is a big difference in practice. Implementors of open source
libraries that want to claim interoperability will at least make the
effort to ensure that the library can be configured to prevent
cleartext transport. If the language is not there, then in practice
many implementations will implement the fallback strategy because it
(a) is spec compliant; and (b) appears to work for all users out of
the box (it doesn't really work for users that need security and are
operating in an adversarial context, but that's not going to be the
out-of-box experience).

So, if the mandatory language is not there, it likely makes the spec
unsuitable for secure applications, but if the language is there, it
is not likely to be a significant impedance to insecure usages. People
always find a way to circumvent security when they don't care about
it.

> times. Ideally there should be confidentiality at BOTH the IPSEC and the TLS
> levels and authentication and integrity checks at BOTH the TLS and HTTP
> levels.
>
> fetish. Using a firewall doesn't make you any safer unless you know what you
> are trying to achieve.

We know what we are trying to achieve.

> On Thu, Nov 29, 2012 at 2:45 PM, Joseph Anthony Pasquale Holsten
> <[email-masked]> wrote:
>>

-- 
--Breno

---

From: Joseph Holsten <[email-masked]>
Date: Thu, 29 Nov 2012 14:17:57 -0800

On Nov 29, 2012, at 14:02, Phillip Hallam-Baker <[email-masked]> wrote:
> When people are saying we MUST use TLS and MUST ensure that client side javascript can make Webfinger lookups, I see a disaster looming.

Is there a reason some JavaScript clients could not make a wf lookup over TLS that I'm missing? It's been over a year since I've done frontend js, I'm sorry if I'm missing something obvious. 

--
http://josephholsten.com

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 29 Nov 2012 11:26:43 -0800

Rephrase?

---

From: Nico Williams <[email-masked]>
Date: Fri, 30 Nov 2012 12:49:36 -0600

Er, why not:

 - if you use TLS you can get the whole resource
 - if you don't use TLS you get a reduced resource (e.g., minus any
security-relevant content)

Or, alternatively, and better, if the client didn't use TLS, then the
client MUST NOT trust any security-relevant content, and the client
really must not trust any of the content.  Lack of trust != useless.
The old finger protocol was never secure, yet it was useful....

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Nov 2012 11:12:51 -0800

> The old finger protocol was never secure, yet it was useful....

+1