Subject: [apps-discuss] Draft -07 mod proposal: HTTPS only

From: Tim Bray <[email-masked]>
Date: Sun, 2 Dec 2012 17:15:15 -0800

Proposal: Change para 2 of section 5.2 to read as follows:

Clients MUST query the server using HTTPS. If an HTTPS connection cannot be
established, or returns an HTTP status code indicating some error, such as
4xx or 5xx, the client MUST report an error and MUST cease attempting to
retrieve the resource.

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Dec 2012 22:36:50 -0300

Of the two proposals Tim has submitted on this, this is my clear preference.   I may be able to live with the other.
Not news to anyone I expect.   

This is simpler to code for clients and will have fewer interoperability issues.

John B.

On 2012-12-02, at 10:15 PM, Tim Bray <[email-masked]> wrote:

> Clients MUST query the server using HTTPS. If an HTTPS connection cannot be established, or returns an HTTP status code indicating some error, such as 4xx or 5xx, the client MUST report an error and MUST cease attempting to retrieve the resource.
>

---

From: John Panzer <[email-masked]>
Date: Sun, 2 Dec 2012 21:27:46 -0800

+1.
On Dec 2, 2012 5:15 PM, "Tim Bray" <[email-masked]> wrote:

> Clients MUST query the server using HTTPS. If an HTTPS connection cannot
> be established, or returns an HTTP status code indicating some error, such
> as 4xx or 5xx, the client MUST report an error and MUST cease attempting to
> retrieve the resource.
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Dec 2012 06:39:01 +0100

Department of "here we go again".

TLS does not require security on its own.  Making mandatory use of it
requires a signed certificate.  Self-signed certs are common in
enterprise (and other environments).  One of the examples given in the
draft (4.3 email client) is a classic enterprise configuration matter. 
And so what this would do is force more nags at the user about untrusted
certificates.  Worse– some email clients (in the given example) may not
handle that warning well.

So on the whole, I'd oppose any sort of language like the below.  It's
too strong, and eliminates webfinger from serious consideration within
the enterprise.

Eliot

On 12/3/12 2:15 AM, Tim Bray wrote:
> Clients MUST query the server using HTTPS. If an HTTPS connection
> cannot be established, or returns an HTTP status code indicating some
> error, such as 4xx or 5xx, the client MUST report an error and MUST
> cease attempting to retrieve the resource.
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 10:00:34 -0300

I added Web Finger to the subject to make filtering easier for those that want to not see this.

Enterprises that are acting as their own CA install there signing certificates in the clients certificate store to prevent browser warnings now.

I don't see how this makes that situation any better or worse.  True if a enterprise is it's own CA third parties going to that site for WF will have to install the root cert anyway.

A concrete example of that would be MITRE who sign their own certificates for security reasons rather cost.   I expect for security that they would not be allowed to do non TLS web-finger.
They will have a issue that they need to solve independent of whether TLS is mandatory in the spec.

The simplest solution is to not use a certificate from a CA that is not part of the default certificate store if you want the public to come to your site and read your WF documents.

I think most people know that already.

I don't think the enterprise example really holds water, they are the people most likely to get a commercial vert if they are dealing with the public.
(MITRE has a different audience who's names I can't speak)

John B.

On 2012-12-03, at 2:39 AM, Eliot Lear <[email-masked]> wrote:

> TLS does not require security on its own.  Making mandatory use of it requires a signed certificate.  Self-signed certs are common in enterprise (and other environments).  One of the examples given in the draft (4.3 email client) is a classic enterprise configuration matter.  And so what this would do is force more nags at the user about untrusted certificates.  Worse– some email clients (in the given example) may not handle that warning well.
> 
> So on the whole, I'd oppose any sort of language like the below.  It's too strong, and eliminates webfinger from serious consideration within the enterprise.
> 
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Dec 2012 14:58:15 +0100

John,

I think the problem we're having here is the applicability of
webfinger.  One of the examples could be viewed as an internal employee
at an enterprise configuring email.  Also, Internet (big I) tools often
end up in the enterprise.  Your MITRE example is a good one.  In that
case, and there are others like it, administrators have made a choice. 
That's the way it should be.  Other administrators will make other
choices.  Don't force them to make bad ones.  Different story for
implementers.  There I have no problem with a MUST.

Eliot

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 11:57:14 -0300

I am not recommending a particular solution for enterprises,  just pointing out that is they probably have a solution for trusting there own certificates for web browsers.  That works for WF as well.

If they don't have a solution other than telling users to hit ignore all the time then we probably can't help them.

Remember WF is deployed on the web server for there domain, so whatever cert is there will work or not work for them as well as it is now.

John B.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 4 Dec 2012 18:54:55 +0000

Can I offer a compromise? I know the voice of small providers isn't very
welcome here, but I think it's (still) important. Examples like Github
Pages are relevant, whether those at organisations with large engineering
resources think so or not.

n.b. If someone on this list can convince Github to do the necessary
work (or even a clear commitment with a stated time-frame for delivery) to
have this ticket closed:
http://www.mail-archive.com/[email-masked]/msg30067.htmlI'll
totally rescind my concerns over this.

How about:

Clients MUST query the server using HTTPS, obeying HSTS semantics. If an
HTTPS connection has never been established, or returns an HTTP status code
indicating some error, such as 4xx or 5xx, absent HSTS headers, the client
MAY attempt the same query using HTTP.

... and then add something (e.g. after §7) to the effect of:

---
Transport Security

It is advised that webfinger resources that are to be used for
authentication or verification purposes SHOULD use HTTPS, and HTTPS-enabled
servers SHOULD use HSTS to ensure that clients are not vulnerable to
downgrade attacks.
---

It's worth noting that DNS is still a huge security hole in all of this. I
don't see Webfinger mandating the use of DNSSEC, nor the methods by which
to verify certificates, so no-one should be under the illusion that
mandating HTTPS is going to lead to "secure" implementations.

b.

On 4 December 2012 16:04, Brad Fitzpatrick <[email-masked]> wrote:

> +1
>
> But I would also tolerate the alternative, requiring that clients provide
> an HTTPS-only mode.
>
>
> On Sun, Dec 2, 2012 at 5:15 PM, Tim Bray <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Tue, 4 Dec 2012 16:43:15 -0300

HSTS doesn't protect against a DNS attack before the client makes first contact.   It is intended to prevent leaking https: bound cookies after the first contact.
I don't think it helps us in any way.  An attacker would redirect the client to the fake site without HSTS before it makes the WF request.

The certificate verification re RFC6125 per OAuth and other specs still needs to be added, rather than just implied.
 
John B.

On 2012-12-04, at 4:03 PM, Brad Fitzpatrick <[email-masked]> wrote:

> On Tue, Dec 4, 2012 at 10:54 AM, Blaine Cook <[email-masked]> wrote:
> and HTTPS-enabled servers SHOULD use HSTS to ensure that clients are not vulnerable to downgrade attacks.
> 
> HSTS is a huge hammer and very few sites are prepared to enable it.  I don't think it should be a SHOULD, especially because webfinger shares the same domain as other things on that host, and WebFinger's use of HSTS would influence other paths on that host.  (yes, I already hear the arguments for a webfinger subdomain coming back)
> 
> It's worth noting that DNS is still a huge security hole in all of this. I don't see Webfinger mandating the use of DNSSEC, nor the methods by which to verify certificates, so no-one should be under the illusion that mandating HTTPS is going to lead to "secure" implementations.
> 
> I believe verification of certs with root CAs was implicit.  At least that's what (almost?) all HTTP clients do by default anyway.

---

From: Randall Leeds <[email-masked]>
Date: Tue, 4 Dec 2012 12:07:01 -0800

+1.

I've been lurking this discussion for a while, trying to ascertain where I
might contribute and I'd like to chime in to say that this language makes
sense to me.

As has been repeated many times, an implementor can *always* break spec.
Providing recommendations around fallbacks and client API requirements just
doesn't seem worth the words. In the end, the communities of practice will
decide what becomes common use.*

> mandating HTTPS is going to lead to "secure" implementations.

If it's worth noting, then I'd say note it in the spec. Again, I think it's
good to cover the issues, but not mandate what anyone should do with that
information. It seems clear to me that there are a range of security
concerns around, from zero concerns, trusted links and hosts, all the way
to DNSSEC. If WebFinger will serve all of these uses then I feel that it
shouldn't try to over-specify these issues.

Please, correct me if I'm missing something; many in this discussion seem
to have much more spec-writing experience and security knowledge than I.

--

* For example, I might expect some kind of OpenID Connect consumer library
to enforce a strict HTTPS-only policy when looking up the IdP (or decide to
offer a fallback parameter in its API), but that's completely up to those
implementors. Similarly, a provider of WebFinger resources might redirect
HTTP to HTTPS+HSTS if it feels strongly that this would protect its users
from phishing or some such threat. Market pressure should dictate that
identity providers make a best effort at ensuring their WebFinger resources
are difficult to impersonate successfully.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 4 Dec 2012 08:04:44 -0800

+1

---

From: Brad Fitzpatrick <[email-masked]>
Date: Tue, 4 Dec 2012 11:03:47 -0800

> vulnerable to downgrade attacks.

HSTS is a huge hammer and very few sites are prepared to enable it.  I
don't think it should be a SHOULD, especially because webfinger shares the
same domain as other things on that host, and WebFinger's use of HSTS would
influence other paths on that host.  (yes, I already hear the arguments for
a webfinger subdomain coming back)

> mandating HTTPS is going to lead to "secure" implementations.

I believe verification of certs with root CAs was implicit.  At least
that's what (almost?) all HTTP clients do by default anyway.