Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP

From: Evan Prodromou <[email-masked]>
Date: Sat, 01 Dec 2012 09:42:30 -0500

I think I've already given this proposal my -1.

It doesn't belong in this spec, which isn't about libraries or their 
APIs. If someone wants to define an IDL model for Webfinger libraries in 
some other document, best wishes.

This document should be about the interface between clients and servers, 
not the interface between client libraries and their calling applications.

-Evan

On 12-11-30 06:09 PM, Tim Bray wrote:
> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> > You're right on target. In fact, I have made both proposals here:
> >
> > 1. Mandatory TLS
> > 2. Mandatory-to-implement configuration for no-HTTP fallback.
> > Essentially in this case the inputs to a WF client are an email
> > address and a boolean to say whether fallback is allowed. May not be
> > pleasant to write in a spec...
>
> OK, let's make this concrete, I don't think it's that unpleasant to 
> spec out:
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> In draft-ietf-appsawg-webfinger-06
>
> - Remove the second paragraph of Section 5.1, which begins "Clients 
> MUST first attempt a query...
>
> Introduce a new section 5.2 and bump up the other sections, as follows
>
> 5.2 Use of HTTPS
>
> WebFinger client software MUST accept as input a boolean parameter 
> which for the purposes of this discussion will be referred as 
> "allow-fallback".
>
> WebFinger client software MUST attempt to retrieve 
> /.well-known/webfinger using the HTTPS protocol.  If an HTTPS 
> connection is made, and the server has an invalid certificate, or 
> returns an HTTP status code indicating an error, the client software 
> MUST report an error and cease attempting to retrieve the resource.
>
> If the WebFinger client software is unable to establish an HTTPS 
> connection to the server, behavior depends on the value of the 
> allow-fallback parameter.  If the value of allow-fallback is true, the 
> client software MAY fall back to unencrypted HTTP in an attempt to 
> retrieve /.well-known/webfinger.  If allow-fallback is false, client 
> software MUST report an error and cease attempting to retrieve the 
> resource.
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: James M Snell <[email-masked]>
Date: Sat, 1 Dec 2012 07:57:02 -0800

+1 to Evans objection
On Dec 1, 2012 6:42 AM, "Evan Prodromou" <[email-masked]> wrote:

> It doesn't belong in this spec, which isn't about libraries or their APIs.
> If someone wants to define an IDL model for Webfinger libraries in some
> other document, best wishes.
>
> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <[email-masked]>
> wrote:
>
> OK, let's make this concrete, I don’t think it’s that unpleasant to spec
> out:
> - Remove the second paragraph of Section 5.1, which begins “Clients MUST
> first attempt a query...
>
> WebFinger client software MUST accept as input a boolean parameter which
> for the purposes of this discussion will be referred as "allow-fallback".
>
> WebFinger client software MUST attempt to retrieve /.well-known/webfinger
> using the HTTPS protocol.  If an HTTPS connection is made, and the server
> has an invalid certificate, or returns an HTTP status code indicating an
> error, the client software MUST report an error and cease attempting to
> retrieve the resource.
>
> client software MAY fall back to unencrypted HTTP in an attempt to retrieve
> /.well-known/webfinger.  If allow-fallback is false, client software MUST
> report an error and cease attempting to retrieve the resource.
>
>
>
> apps-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 30 Nov 2012 12:20:00 -0800

On Fri, Nov 30, 2012 at 10:48 AM, Bob Wyman <[email-masked]> wrote:

>
>
>
> On Fri, Nov 30, 2012 at 12:20 PM, Brad Fitzpatrick <[email-masked]>wrote:
>
>> On Fri, Nov 30, 2012 at 8:43 AM, Bob Wyman <[email-masked]> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Nov 29, 2012 at 5:31 PM, John Panzer <[email-masked]> wrote:
>>>
>>>> It's Bob's entire public identity.  Knowing it wasn't altered in
>>>> transit or served from a take origin is kind of... important.
>>>>
>>>  An alternative to requiring a TLS encrypted link to read Bob's
>>> information would be to permit Bob to sign the documents he publishes. That
>>> would allow some level of integrity and authentication to be provided
>>> whether HTTP or HTTPS had been used. WebFinger says nothing about signing.
>>> Why not?
>>>
>>
>> WebFinger says nothing about religion or tying shoelaces either.
>>
>> I intend to use email addresses as the identifier for addressing people
>> (crazy!) and sharing in my Camlistore project, which means Camlistore can
>> use WebFinger to find other people's Camlistore servers and communicate
>> between them.  And in Camlistore, everything is signed.
>>
>> Yet I'm not trying to push Camlistore into WebFinger.
>>
> Thanks for your very kind comments. But, can you tell me, if I wanted to
> publish a signed JRD using WebFinger, how would I do that?  The JRD
> specification <http://tools.ietf.org/html/rfc6415#page-12> linked to the
> latest WebFinger draft doesn't seem to address the issue.
>

Two options immediately come to mind:

1) Use Accept headers.  Have the WebFinger client tell the WebFinger server
that it supports a superset of the base types and would understand a
version that's signed with the JSON signing method of the week.

2) Have the unsigned version include a URL to the signed version, then it
could be understood by both old and new clients.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Fri, 30 Nov 2012 16:01:07 -0800

I like Tim Bray's addition.

If WebFinger isn't going to be HTTPS-only (which is still my preference,
after thinking about it a few days), it definitely needs this sort of
addition (or this addition verbatim), otherwise nobody using WebFinger for
anything secure will be able to trust likely-insecure permissive clients
out there.

But I'd still like to keep WebFinger simpler for clients and more secure by
making it HTTPS-only.  A follow-on spec could define DirtyFinger and its
hygienic best practices, but the onus would be on that group to define all
this sort of stuff like Tim does below.  And DirtyFinger could have its own
well-known endpoint.

In retrospect, I should've made OpenID HTTPS-only from the beginning, but I
was lazy ("HTTPS is annoying"), and I regret it.  It resulted in years of
debate about OpenID's security, much of it warranted.

If WebFinger is going to be a bootstrapping mechanism for other things,
it'd be nice to know the base was trustworthy, even if for certain
applications it's often unnecessary.

I'm mostly interested in the client simplicity: one request.

On Fri, Nov 30, 2012 at 3:25 PM, Tim Bray <[email-masked]> wrote:

> Or, a little more smoothly. “If the value of allow-fallback is not
> explicitly specified, WebFinger software MUST assume the value is false.”
>
>
> On Fri, Nov 30, 2012 at 3:18 PM, Breno de Medeiros <[email-masked]>wrote:
>
>> On Fri, Nov 30, 2012 at 3:15 PM, Martin Thomson
>> <[email-masked]> wrote:
>> > On 30 November 2012 15:09, Tim Bray <[email-masked]> wrote:
>> which for
>> >> the purposes of this discussion will be referred as "allow-fallback".
>> >
>> > I suspect that many implementations will choose to disregard this
>> > clause in favour of fixing the value to "false".
>> > <<<
>> > WebFinger client software MAY accept as input a boolean parameter,
>> > which for the purposes of this discussion will be referred /to/ as
>> > "allow-fallback".  Otherwise, WebFinger client software MUST assume
>> > that allow-fallback is false.
>>
>> +1
>>
>> --
>> --Breno
>>
>
>

---

From: John Bradley <[email-masked]>
Date: Sat, 1 Dec 2012 14:25:32 -0300

Jeff's RFC on strict transport is good but mostly targeted at the threat of cookie disclosure if a user clicks through on a TLS warning.

We could require WF clients to support it, however if the first interaction is to the hijacked site the Client never sees the strict header and would fall back.

I don't think this solves the issue.

I am uncharacteristically agreeing with Brad on this.  I prefer https: only as it stops lots of interoperability issues, and is simpler for clients to implement than a fall back sometimes under some circumstances for some things.  Caching will also need to be considered in the client library you can't cache the http version and later serve it up to a secure only request it, needs to treat them as separate resources.   It is not simple.

If we need to support both the protocol needs to be https: only unless it receives an explicit request from the app level to allow fallback.   
In the end that winds up being https: only with extra complexity that is not required but I could live with it if I have to.

John B.

On 2012-11-30, at 8:59 PM, Blaine Cook <[email-masked]> wrote:

> http://tools.ietf.org/html/rfc6797
> 
> 
> On 30 November 2012 16:36, Nico Williams <[email-masked]> wrote:
> I think the right thing to do is to leave WF signing for later and
> rely on TLS for integrity protection where it's needed.  I doubt we're
> prepared to start doing JWE signatures here, right now.

---

From: John Bradley <[email-masked]>
Date: Sat, 1 Dec 2012 14:31:07 -0300

Defining library API is not in any way my preference.   I think mandatory TLS is the only correct answer.  

However if we are to allow both without being clear with developers how to control fallback it won't be useful.

The other thing to do is have two versions of WF clean and dirty and allow applications to call dirty if clean fails and they want to try again rather than hiding it all in a single flow and expecting some magic to happen.

John B.

On 2012-12-01, at 12:57 PM, James M Snell <[email-masked]> wrote:

> It doesn't belong in this spec, which isn't about libraries or their APIs. If someone wants to define an IDL model for Webfinger libraries in some other document, best wishes.
> 
> This document should be about the interface between clients and servers, not the interface between client libraries and their calling applications.
> 
> -Evan
> 
>> On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros <[email-masked]> wrote:
>> 
>> OK, let's make this concrete, I don’t think it’s that unpleasant to spec out:
>> - Remove the second paragraph of Section 5.1, which begins “Clients MUST first attempt a query...
>> 
>> WebFinger client software MUST accept as input a boolean parameter which for the purposes of this discussion will be referred as "allow-fallback".
>> 
>> WebFinger client software MUST attempt to retrieve /.well-known/webfinger using the HTTPS protocol.  If an HTTPS connection is made, and the server has an invalid certificate, or returns an HTTP status code indicating an error, the client software MUST report an error and cease attempting to retrieve the resource.
>> 
>> If the WebFinger client software is unable to establish an HTTPS connection to the server, behavior depends on the value of the allow-fallback parameter.  If the value of allow-fallback is true, the client software MAY fall back to unencrypted HTTP in an attempt to retrieve /.well-known/webfinger.  If allow-fallback is false, client software MUST report an error and cease attempting to retrieve the resource.
>> 
>> 
>>

---

From: Tim Bray <[email-masked]>
Date: Sat, 1 Dec 2012 09:55:28 -0800

I normally agree with Evan on most things, but not here. It is perfectly OK
and unsurprising for an Internet protocol to impose behavioral constraints
on software. Otherwise you could never specify MustUnderstand. -T

---

From: Tim Bray <[email-masked]>
Date: Sat, 1 Dec 2012 09:56:21 -0800

Er once again I mean MustIgnore.
On Dec 1, 2012 9:55 AM, "Tim Bray" <[email-masked]> wrote:

> I normally agree with Evan on most things, but not here. It is perfectly
> OK and unsurprising for an Internet protocol to impose behavioral
> constraints on software. Otherwise you could never specify MustUnderstand.
> -T

---

From: Tim Bray <[email-masked]>
Date: Sat, 1 Dec 2012 10:07:00 -0800

My overriding goal is that we leave open the possibility of using WF in
OIDC. Given what the security people have said, that means either
https-only or a fallback parameter.  I'm with a rough consensus in favor of
either.

If I were wearing a WG chair hat, I'd be trying some consensus calls PDQ.
On Dec 1, 2012 9:25 AM, "John Bradley" <[email-masked]> wrote:

> Jeff's RFC on strict transport is good but mostly targeted at the threat
> of cookie disclosure if a user clicks through on a TLS warning.
>
> We could require WF clients to support it, however if the first
> interaction is to the hijacked site the Client never sees the strict header
> and would fall back.
>
> I am uncharacteristically agreeing with Brad on this.  I prefer https:
> only as it stops lots of interoperability issues, and is simpler for
> clients to implement than a fall back sometimes under some circumstances
> for some things.  Caching will also need to be considered in the client
> library you can't cache the http version and later serve it up to a secure
> only request it, needs to treat them as separate resources.   It is not
> simple.
>
> If we need to support both the protocol needs to be https: only unless it
> receives an explicit request from the app level to allow fallback.
> In the end that winds up being https: only with extra complexity that is
> not required but I could live with it if I have to.
>
> John B.
>
>

---

From: Nico Williams <[email-masked]>
Date: Sat, 1 Dec 2012 12:53:46 -0600

On Sat, Dec 1, 2012 at 8:42 AM, Evan Prodromou <[email-masked]> wrote:
> This document should be about the interface between clients and servers, not
> the interface between client libraries and their calling applications.

We don't just describe bits on the wire.  We describe behavior as
well.  And that means at least a modicum of recommendations and/or
requirements for APIs.

BTW, another thing we need to require is an output (from the client
API) indicating whether TLS was used or not.

Nico
--

---

From: William Mills <[email-masked]>
Date: Sat, 1 Dec 2012 16:24:21 -0800 (PST)

Another possibility is to define 2 endpoints; "webfinger" for general use, and "tlsfinger" which MUST be TLS (or other secured method) only.

>________________________________
> From: Nico Williams <[email-masked]>
>To: Evan Prodromou <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; "[email-masked] Discuss" <[email-masked]> 
>Sent: Saturday, December 1, 2012 10:53 AM
>Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 1 Dec 2012 23:02:16 -0500

There is still a glaring hole in that spec where a client unfamiliar with a given domain does not know that the domain wants to use HTTPS or not.  A possible solution to that is querying the site’s webfinger resource to see if it returns the “Strict-Transport-Security” header in the reply :-)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Friday, November 30, 2012 6:59 PM
To: Nico Williams
Cc: Joseph Holsten; WebFinger List; [email-masked] Discuss
Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP

---

From: John Bradley <[email-masked]>
Date: Sun, 2 Dec 2012 01:16:11 -0300

The query about the client wanting to use strict https: would only be useful if it were over https.  

It winds up a bit circular. 

The main thing it is doing is not letting users click OK to certificate errors in the browser after they have received the header. 
So it works if you have already connected to the real site before the DNS is hijacked.

The header is still quite new so I wouldn't count on everything being able to see or inspect it.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 2 Dec 2012 03:30:34 -0500

I think it comes down to "what are you going to do with the information?"
If you have a web site that has a comments area and you just want to use WF
to get a picture of the person posting comments so make it a little more
"colorful", then HTTP is likely sufficient.  However, if you blog requests
users to log in using some mechanism that results in possibly passing user
login credentials to a rogue site as a result of having the response message
altered in flight, then HTTPS is mandatory.

I would also expect HTTPS to be used when collecting server information for
auto-provisioning email for the same reason. I would not want to pass my
user credentials to a third-party site that uses plain text logins and
steals my password.

If your email client uses WF to grab a person's picture, vcard, or other
information for use in your email program, then I'd say HTTP is probably
just fine.

In any case, the current document encourage use of HTTPS.  But, it still
allows for HTTP and I can see some valid cases for it.

Paul 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Zellyn Hunter
> Sent: Sunday, December 02, 2012 1:17 AM
> To: [email-masked]
> Cc: Blaine Cook; Nico Williams; Joseph Holsten; [email-masked]
> Would it be useful to enumerate specific cases where people feel HTTP
> would be useful, so we can see whether the concern is justified?
> 
> My first thoughts were:
> - static sites like github pages, small sites hosted places like
> bluehost, etc.
> - locally served pages while debugging: setting up certificates might be
> painful.
> 
> However,
> - I'm sure that with free certs offered now, it won't stay complicated
> or unusual to upload certs for long
> - I'm less certain about local debugging, although it seems like a one-
> paragraph tutorial could easily cover generating testing certs and
> signing for any given framework (eg. django, rails) and tool (eg.
> curl, wget).
> 
> Are there more pressing concerns about disallowing HTTP? Several of the
> pro-HTTP comments have mentioned that everything in webfinger will point
> to HTTP-only resources that are freely and un-encryptedly available. But
> I imagine that it is precisely if webfinger is successful that more and
> more important things will use it as a jumping-off point. I also have a
> hard time discounting (a) the increasing trend towards HTTPS for web
> traffic, and (b) the comments of people like Brad about wishing they'd
> done HTTPS-only for other
> protocols: it would be a shame to ignore that hard-won wisdom.
> 
> Sorry if I'm adding to the noise: I'd just like to see some more
> concrete arguments in favor of allowing HTTP.
> 
> Zellyn
> 
> 
> On Sat, Dec 1, 2012 at 8:16 PM, John Bradley <[email-masked]> wrote:
> > The main thing it is doing is not letting users click OK to
> > certificate errors in the browser after they have received the header.
> > There is still a glaring hole in that spec where a client unfamiliar
> > with a given domain does not know that the domain wants to use HTTPS
> > or not.  A possible solution to that is querying the site's webfinger
> > resource to see if it returns the "Strict-Transport-Security" header
> > in the reply :-)
> >
> > Paul
> >
> >
> > From: [email-masked]
> > [mailto:[email-masked]]
> > On Behalf Of Blaine Cook

---

From: Mikael Nordfeldth <[email-masked]>
Date: Sun, 02 Dec 2012 15:47:31 +0100

> allows for HTTP and I can see some valid cases for it.

I simply haven't written in this discussion because it took some time 
to catch up with all the activity. But I think Paul is very right here. 
The context is that there _are_ cases where HTTP is ok.

When I first joined this discussion the main topic was that "XML would 
be too hard for newbies" and that XRD support would cripple adoption. If 
one _requires_ a user to get, configure and setup an SSL certificate, 
regardless of easiness through web hotels, I think it would be a much 
larger obstacle.

Also, to really get my personal point through regarding HTTP/HTTPS, I 
wish to remind everyone reading this discussion that HTTPS does _not_ 
mean secure. There remains big security loop-holes due to things like 
non-secure DNS requests, huge reliance upon on small number of 
certificate authorities and of course relaxed default configurations in 
https libraries.

So. Having mandatory HTTPS would in practice not secure the majority of 
Webfinger use. If one's specific application is very sensitive regarding 
100% verifiable data, the only option is to gather out-of-band data to 
compare. Which works just as well for HTTP.

I don't mean to pour further gasoline in the fire, so if anyone wishes 
to comment or correct me on this post they can do it privately. I think 
most relevant cases for Webfinger are already discussed on this list.

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

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 2 Dec 2012 15:57:38 +0100

On 2 December 2012 05:02, Paul E. Jones <[email-masked]> wrote:

> There is still a glaring hole in that spec where a client unfamiliar with
> a given domain does not know that the domain wants to use HTTPS or not.  A
> possible solution to that is querying the site’s webfinger resource to see
> if it returns the “Strict-Transport-Security” header in the reply :-)
>

Agree this is a hole and mandating https would seem to fix it.  Tho the
added constraint may alienate some adopters.

At this point it's probably getting more urgent to ship something that is
usable, rather than the making webfinger the perfect all-purpose discovery
system for the web (which it can never be anyway, as linked data has sewn
that up already).  So I suggest going with whatever can achieve consensus
fastest.

> ****
>
> ** **
>
> Paul****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Blaine Cook
> *Sent:* Friday, November 30, 2012 6:59 PM
> *To:* Nico Williams
> *Cc:* Joseph Holsten; WebFinger List; [email-masked] Discuss
>
> *Subject:* Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP****
>
> ** **
>
> http://tools.ietf.org/html/rfc6797****
>
> ** **
>
> On 30 November 2012 16:36, Nico Williams <[email-masked]> wrote:***
> *
>
> prepared to start doing JWE signatures here, right now.****
>
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 07:00:05 -0800

> allows for HTTP and I can see some valid cases for it.

What are the avid use cases? 

Keep in mind we are adding complexity to clients by allowing both, so there is a real cost to allowing both. I'm not clear what we are losing by HTTPS-only

-- Dick

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 1 Dec 2012 10:14:07 -0800

> not the interface between client libraries and their calling applications.

Security is an end-to-end thing, though.

You can mandate that seat belts are installed in cars, but you save many
more lives by legislating that people actually wear them.

You seem to be in the "why should anybody be allowed to tell me I have to
wear a motorcycle helmet?" camp, but I think a lot of people on this list
are looking for more safety.

Is your objection against HTTPS that it would be too difficult for
status.net users?  (or actually, I'm not sure of your position on this, so
I don't mean to put words in your mouth....)

---

From: Zellyn Hunter <[email-masked]>
Date: Sat, 1 Dec 2012 22:16:51 -0800

My first thoughts were:
- static sites like github pages, small sites hosted places like bluehost, etc.
- locally served pages while debugging: setting up certificates might
be painful.

However,
- I'm sure that with free certs offered now, it won't stay complicated
or unusual to upload certs for long
- I'm less certain about local debugging, although it seems like a
one-paragraph tutorial could easily cover generating testing certs and
signing for any given framework (eg. django, rails) and tool (eg.
curl, wget).

Are there more pressing concerns about disallowing HTTP? Several of
the pro-HTTP comments have mentioned that everything in webfinger will
point to HTTP-only resources that are freely and un-encryptedly
available. But I imagine that it is precisely if webfinger is
successful that more and more important things will use it as a
jumping-off point. I also have a hard time discounting (a) the
increasing trend towards HTTPS for web traffic, and (b) the comments
of people like Brad about wishing they'd done HTTPS-only for other
protocols: it would be a shame to ignore that hard-won wisdom.

Zellyn

On Sat, Dec 1, 2012 at 8:16 PM, John Bradley <[email-masked]> wrote:
> The main thing it is doing is not letting users click OK to certificate
> errors in the browser after they have received the header.
> There is still a glaring hole in that spec where a client unfamiliar with a
> given domain does not know that the domain wants to use HTTPS or not.  A

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Dec 2012 17:41:02 -0600

> would be useful, so we can see whether the concern is justified?

As long as WF is a bag of arbitrary stuff, no: we can't enumerate what
might get put in in the future.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 2 Dec 2012 22:11:46 -0500

Dick,

I can imagine university networks and even some businesses that would
utilize WebFinger for internal purposes where security is not essential.
 
If WF takes off, then there might be millions of domains out there that
provide WF services.  What percentage of those might use WF in scenarios
where security is important?  If WF is used to auto-provision an email
client or direct a user to log into an IdP, then I can appreciate a need to
use TLS.  So, in applications where TLS is really needed, I would not bother
with attempting a request via HTTP.

Example uses where HTTP is probably "good enough":
  * Clicking on acct:[email-masked] in my browser and having
    a "profile" page produced that contains whatever information
    that is found (e.g., a picture, contact info, blog, web site)
  * Clicking on the sender's name in an email client to fetch
    the person's vcard, picture, or other.
  * Fetching a user's picture when he or she posts something on a web
    site (I assume that the user has an account at the web site and the
    site has verified the user's email address)

I appreciate that the client code will be made a little more complex, but
the effort is not really more than handling a 3xx redirection.

I'm not arguing strongly either way, though.  I could put the mandate in for
TLS, but there are other folks who want to allow plain ol' HTTP.  They've
spoken on the list.

Paul

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Dick Hardt
> Sent: Sunday, December 02, 2012 10:00 AM
> Cc: [email-masked]; 'Joseph Holsten'
> > In any case, the current document encourage use of HTTPS.  But, it
> > still allows for HTTP and I can see some valid cases for it.
> 
> Keep in mind we are adding complexity to clients by allowing both, so
> there is a real cost to allowing both. I'm not clear what we are losing
> by HTTPS-only
> 
> -- Dick

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 19:24:54 -0800

Hi Paul

I agree there are many use cases where the security is not essential.

My question was what do we lose by requiring TLS? 

I know we are adding complexity to server implementations, but what else are we losing?

As for dealing with a 3XX redirect, many client libraries will do that automagically for you. 

There is a real latency and extra code in dealing with the fallback as currently specified.

For example, we lose being able to use a simple CURL command to get a JRD.

Again, what are we losing by HTTPS only? A pro and con list would be helpful.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 19:25:54 -0800

On Dec 2, 2012, at 12:25 PM, [email-masked] wrote:

> On 2012-12-02 15:00, Dick Hardt wrote:
>> there is a real cost to allowing both. I'm not clear what we are
>> losing by HTTPS-only
>> 
>> -- Dick
> Surely mandating HTTPS for all connections would not only increase overhead by forcing SSL key exchange where it isn't necessary, but wouldn't it remove the ability to cache web content, thereby crippling the performance of many content-heavy websites? For sites which don't require secure connections, it just doesn't make sense. The additional complexity on the client from running both protocols that you mentioned is the lesser of two evils (unless the two protocols are somehow integrated).

It is implementation complexity that I am talking about. Per the latest draft, the Client has to first call HTTPS and depending on the result of that call, can call HTTP.

The overhead of SSL is nothing compared to making to calls, and the first has to be SSL anyway!

-- Dick

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Dec 2012 22:56:22 -0600

> My question was what do we lose by requiring TLS?

Some hosting sites can't handle it well at all.  Either they require
server certs that can serve many domains or they require per-domain IP
addresses because SNI is not well supported.

Many clients don't do proper server cert validation.  "I used TLS" !=
"I got it securely".

> There is a real latency and extra code in dealing with the fallback as currently specified.

But is that relevant here?

> For example, we lose being able to use a simple CURL command to get a JRD.

So you need an if and two invocations of curl.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Dec 2012 22:57:40 -0600

> It is implementation complexity that I am talking about. Per the latest draft, the Client has to first call HTTPS and depending on the result of that call, can call HTTP.

That's two lines of code.  Compare to the discovery process.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 20:58:32 -0800

> That's two lines of code.  Compare to the discovery process.

Compare what?

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 21:02:41 -0800

> addresses because SNI is not well supported.

Which sites? Are they critical to the successful deployment of WF? If WF is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only will drive easier TLS support. That would seem to be a good thing.

> Many clients don't do proper server cert validation.  "I used TLS" !=

So we should not force HTTPS because some clients don't implement it properly? Really?

> But is that relevant here?

I would think so. If the user is waiting for discovery to be finished, latency is an issue.
Extra code is extra code and complexity and more to understand.

> So you need an if and two invocations of curl.

So you agree it is more complicated. The agreed goal is to push complexity to the server.

---

From: Nico Williams <[email-masked]>
Date: Sun, 2 Dec 2012 23:10:55 -0600

On Sunday, December 2, 2012, Dick Hardt wrote:

>
> On Dec 2, 2012, at 8:56 PM, Nico Williams <[email-masked]<javascript:;>>
> wrote:
>
> > On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <[email-masked]<javascript:;>>
> wrote:
> Which sites? Are they critical to the successful deployment of WF? If WF
> is successful, will they make it easier to deploy TLS? Perhaps HTTPS-only
> will drive easier TLS support. That would seem to be a good thing.

My domain's hosting site, for example.  This is not about the hosting site:
it's about the incomplete deployment of TLS SNI.

> So we should not force HTTPS because some clients don't implement it

No, we should not mandate TLS if either we know that requirement will often
be ignored or if we're doing it because we think that gets use "security".
 And if we do end up requiring TLS we need to say a lot more about server
certificate validation, about TLS cipher suites (e.g., no anon DH ones),
and so on, about trust anchors (same as for web browsers?).

> Extra code is extra code and complexity and more to understand.

I wouldn't worry about a line of code given TLS' complexity, which we'd be
requiring.  The latency involved in one more fallback may well matter, but
I'm not ready to conclude that it means we must require TLS because we
could still consider the alternative that the WF app/ user be the one to
decide whether to use TLS at all or not, without a fallback in either case
(actually, I prefer this alternative).

> So you agree it is more complicated. The agreed goal is to push complexity

Agreed by whom?

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 21:19:08 -0800

On Dec 2, 2012, at 9:10 PM, Nico Williams <[email-masked]> wrote:
> 
> My domain's hosting site, for example.  This is not about the hosting site: it's about the incomplete deployment of TLS SNI.

Would motivating hosting sites to do complete deployment of TLS SNI not be a good thing?

> No, we should not mandate TLS if either we know that requirement will often be ignored or if we're doing it because we think that gets use "security".  And if we do end up requiring TLS we need to say a lot more about server certificate validation, about TLS cipher suites (e.g., no anon DH ones), and so on, about trust anchors (same as for web browsers?).

We mandated TLS in OAuth 2.0 without any of that. Not sure why that is suddenly an issue now.

> I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring.  

TLS support is in libraries readily available to clients. Yes, some of them need to be improved to have *better* support of TLS, but that is a separate issue.

> The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case

The latest spec requires an HTTPS call to start ALL the time.

Choice of what to use adds complexity and incorrect choices by implementations.

> (actually, I prefer this alternative).

And how would the WF app decide if to use TLS or not, or how will it discover what the server supports? 

> So you agree it is more complicated. The agreed goal is to push complexity to the server.

There seemed consensus on this, and I think should be a guiding principal. All other things being equal, move complexity to the side that has fewer implementations and is likely to be done by less sophisticated implementors.

-- Dick

---

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

On Dec 2, 2012 9:19 PM, "Dick Hardt" <[email-masked]> wrote:
>> My domain's hosting site, for example.  This is not about the hosting
site: it's about the incomplete deployment of TLS SNI.
>> No, we should not mandate TLS if either we know that requirement will
often be ignored or if we're doing it because we think that gets use
"security".  And if we do end up requiring TLS we need to say a lot more
about server certificate validation, about TLS cipher suites (e.g., no anon
DH ones), and so on, about trust anchors (same as for web browsers?).
> TLS support is in libraries readily available to clients. Yes, some of
them need to be improved to have *better* support of TLS, but that is a
separate issue.
>
>> The latency involved in one more fallback may well matter, but I'm not
ready to conclude that it means we must require TLS because we could still
consider the alternative that the WF app/ user be the one to decide whether
to use TLS at all or not, without a fallback in either case
> There seemed consensus on this, and I think should be a guiding
principal. All other things being equal, move complexity to the side that
has fewer implementations and is likely to be done by less sophisticated
implementors.

s/less/more/ I assume.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 2 Dec 2012 21:26:01 -0800

On Dec 2, 2012, at 9:24 PM, John Panzer <[email-masked]> wrote:

> s/less/more/ I assume

Yes, thanks, John. Working with PowerPoint right now. My brain is being rewired on me.

-- Dick

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 02:33:37 -0500

Dick,

I gave a list down below of where HTTP was likely sufficient.  What we lose
by demanding TLS is the ability to use WF in places where putting a TLS
certificate is impossible or impractical or useless.  I don't need TLS on
the server running in my house, for example.  (And I'm just the kind of
person that might find a use for WF in such a closed environment.)

You can still use curl, though:
curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com || curl
http://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer.
com

Granted, this is a somewhat faulty fallback mechanism.  This is more
accurate:

curl
https://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer
.com
if [ $? == 7 ]
then
  curl
http://packetizer.com/.well-known/webfinger?resource=acct:paulej@packetizer.
com
fi

I fully agree that this is not as elegant as a one-liner, but it works.

You're entirely right about the latency.  That's the one thing I really
don't like about the fallback approach.  That said, if we go with HTTPS only
and there is no server running, the delay still exists and the user gets no
information.  Turning around immediately and issuing a query via HTTP is
pretty quick... unless there is no server running there, either :)

I'll say again, though, that I don't need to be persuaded.  I'll go along
with the group.

Paul

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, December 02, 2012 10:25 PM
> To: Paul E. Jones
> Cc: 'Dick Hardt'; [email-masked]; [email-masked];
> 'Joseph Holsten'
> > If WF takes off, then there might be millions of domains out there
> > that provide WF services.  What percentage of those might use WF in
> > scenarios where security is important?  If WF is used to
> > auto-provision an email client or direct a user to log into an IdP,
> > then I can appreciate a need to use TLS.  So, in applications where
> > TLS is really needed, I would not bother with attempting a request via
> HTTP.
> >
> > I appreciate that the client code will be made a little more complex,
> > but the effort is not really more than handling a 3xx redirection.
> >
> > I'm not arguing strongly either way, though.  I could put the mandate
> > in for TLS, but there are other folks who want to allow plain ol'
> > HTTP.  They've spoken on the list.
> >
> > Paul
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 02:37:46 -0500

SNI is actually a real problem still and with the current WF spec, even HTTP would not work since the text says that if we get a cert error, don’t try HTTP.

If we want to allow HTTP to work on sites that are running HTTPS for some service, but not necessarily dedicated to the target domain, we will have intermittent issues until such time as all client code properly supports SNI.

I mentioned before that there is a heck of a lot of client code out there still that does not work with SNI.  This will just take time.  We either have to just accept the failures or soften the text related to failures by saying the response should be ignored and allow the client to use HTTP to get a WF response.  (Again, apps that depend on security may opt to not do that.)

Paul

From: Nico Williams [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 12:11 AM
To: Dick Hardt
Cc: Nico Williams; Paul E. Jones; Joseph Holsten; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP

On Dec 2, 2012, at 8:56 PM, Nico Williams <[email-masked] <javascript:;> > wrote:

> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt <[email-masked] <javascript:;> > wrote:

I wouldn't worry about a line of code given TLS' complexity, which we'd be requiring.  The latency involved in one more fallback may well matter, but I'm not ready to conclude that it means we must require TLS because we could still consider the alternative that the WF app/ user be the one to decide whether to use TLS at all or not, without a fallback in either case (actually, I prefer this alternative).

Agreed by whom?

---

From: Tim Bray <[email-masked]>
Date: Mon, 3 Dec 2012 00:09:56 -0800

Possibly related and FWIW, I just set up https on my blog this weekend, see
http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS

It was easy and cheap. Now I’m waiting to discover the horrible problems
and difficulties people keep talking about here.  -T

On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones <[email-masked]>wrote:

> SNI is actually a real problem still and with the current WF spec, even
> HTTP would not work since the text says that if we get a cert error, don’t
> try HTTP.****
>
> ** **
>
> If we want to allow HTTP to work on sites that are running HTTPS for some
> service, but not necessarily dedicated to the target domain, we will have
> intermittent issues until such time as all client code properly supports
> SNI.****
>
> ** **
>
> I mentioned before that there is a heck of a lot of client code out there
> still that does not work with SNI.  This will just take time.  We either
> have to just accept the failures or soften the text related to failures by
> saying the response should be ignored and allow the client to use HTTP to
> get a WF response.  (Again, apps that depend on security may opt to not do
> that.)****
>
> ** **
>
> Paul****
>
> ** **
>
> ** **
>
> *From:* Nico Williams [mailto:[email-masked]]
> *Sent:* Monday, December 03, 2012 12:11 AM
> *To:* Dick Hardt
> *Cc:* Nico Williams; Paul E. Jones; Joseph Holsten;
> [email-masked]; [email-masked]
>
> On Sunday, December 2, 2012, Dick Hardt wrote:****
>
>
> will drive easier TLS support. That would seem to be a good thing.****
>
> ** **
>
> site: it's about the incomplete deployment of TLS SNI.****
>
>  ****
>
> >
> So we should not force HTTPS because some clients don't implement it
> properly? Really?****
>
> ** **
>
> DH ones), and so on, about trust anchors (same as for web browsers?).****
>
>  ****
>
> >
> Extra code is extra code and complexity and more to understand.****
>
> ** **
>
> (actually, I prefer this alternative).****
>
>  ****
>
> So you agree it is more complicated. The agreed goal is to push complexity
> to the server.****
>
> ** **
>
> Agreed by whom?****
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 04:05:23 -0500

Tim,

I think Apache just added SNI support in 2.2.12 released in 2009, I think.
One would also need OpenSSL 0.9.8f or newer.  That was released in 2007, I
think.  It took a little time for those packages to find their way into
Linux distributions, of course.  I would assume all new Linux releases have
this code.  Many servers are still in operation that do not have the right
software installed.

On the client side, Windows XP still seems to lack support for SNI, I think.
Not sure if that affects every browser, but it would affect a lot of
software nonetheless.

SNI is one issue.  The other is cost.  It can be cheap. Did you buy a
wildcard certificate?  Those are expensive.  I'd like to have one, but I'm
not going to pay for it.  And did you get a one-year cert or 5 year?  If
one-year, then you can add the additional labor of swapping out certificates
next year.  Personally, I find this to be a pain.  It's worth it for
applications where I truly need it.  But, there are applications where I
don't.

And while you're technically capable, there are some (many) who are not.
I've purchased TLS certificates from three different companies.  The process
is somewhat painful, in my opinion.  I can create my own self-signed
certificate more easily.  Way more easily.  If you understand the language,
you're OK.  But, there are many who can set up a simple web site but get
lost trying to get a certificate or figure out how to install it. 

Paul

From: Tim Bray [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 3:10 AM
To: Paul E. Jones
Cc: Nico Williams; Dick Hardt; [email-masked];
[email-masked]; Joseph Holsten
Subject: Re: [apps-discuss] HTTPS-only vs HTTPS-and-HTTP

It was easy and cheap. Now I'm waiting to discover the horrible problems and
difficulties people keep talking about here.  -T

On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones <[email-masked]>
wrote:

SNI is actually a real problem still and with the current WF spec, even HTTP
would not work since the text says that if we get a cert error, don't try
HTTP.

SNI.

that.)

Paul

From: Nico Williams [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 12:11 AM
To: Dick Hardt
Cc: Nico Williams; Paul E. Jones; Joseph Holsten;
[email-masked]; [email-masked]

 

> addresses because SNI is not well supported.

Which sites? Are they critical to the successful deployment of WF? If WF is
successful, will they make it easier to deploy TLS? Perhaps HTTPS-only will
drive easier TLS support. That would seem to be a good thing.

properly? Really?

No, we should not mandate TLS if either we know that requirement will often
be ignored or if we're doing it because we think that gets use "security".
And if we do end up requiring TLS we need to say a lot more about server
certificate validation, about TLS cipher suites (e.g., no anon DH ones), and
so on, about trust anchors (same as for web browsers?).

> But is that relevant here?

I would think so. If the user is waiting for discovery to be finished,
latency is an issue.
Extra code is extra code and complexity and more to understand.

I wouldn't worry about a line of code given TLS' complexity, which we'd be
requiring.  The latency involved in one more fallback may well matter, but
I'm not ready to conclude that it means we must require TLS because we could
still consider the alternative that the WF app/ user be the one to decide
whether to use TLS at all or not, without a fallback in either case
(actually, I prefer this alternative).

to the server.

Agreed by whom?

---

From: Tim Bray <[email-masked]>
Date: Mon, 3 Dec 2012 01:12:36 -0800

I bought a wildcard for $90/year from cheapssls.com.  Easy,
straightforward, affordable, well-documented. Single-domain certs are now
down below $10/year.

 -T

On Mon, Dec 3, 2012 at 1:05 AM, Paul E. Jones <[email-masked]> wrote:

> Tim,****
>
> ** **
>
> I think Apache just added SNI support in 2.2.12 released in 2009, I
> think.  One would also need OpenSSL 0.9.8f or newer.  That was released in
> 2007, I think.  It took a little time for those packages to find their way
> into Linux distributions, of course.  I would assume all new Linux releases
> have this code.  Many servers are still in operation that do not have the
> right software installed.****
>
> ** **
>
> On the client side, Windows XP still seems to lack support for SNI, I
> think.  Not sure if that affects every browser, but it would affect a lot
> of software nonetheless.****
>
> ** **
>
> wildcard certificate?  Those are expensive.  I’d like to have one, but I’m
> one-year, then you can add the additional labor of swapping out
> certificates next year.  Personally, I find this to be a pain.  It’s worth
> it for applications where I truly need it.  But, there are applications
> where I don’t.****
>
> ** **
>
> And while you’re technically capable, there are some (many) who are not.
> I’ve purchased TLS certificates from three different companies.  The
> process is somewhat painful, in my opinion.  I can create my own
> self-signed certificate more easily.  Way more easily.  If you understand
> the language, you’re OK.  But, there are many who can set up a simple web
> site but get lost trying to get a certificate or figure out how to install
> it. ****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Tim Bray [mailto:[email-masked]]
> *Sent:* Monday, December 03, 2012 3:10 AM
> *To:* Paul E. Jones
> *Cc:* Nico Williams; Dick Hardt; [email-masked];
> Possibly related and FWIW, I just set up https on my blog this weekend,
> see http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS
>
> and difficulties people keep talking about here.  -T****
>
> wrote:****
> [email-masked]; [email-masked]****
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 03 Dec 2012 18:56:02 +0900

> http://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS

Great! (as the person who suggested it, I'm glad to see it worked out)

But shouldn't that be
https://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS ?
     ^

As for the actual issue at hand, my preference would be to allow both 
HTTPS and HTTP. (Just because Tim Bray says it's easy doesn't mean that 
everybody will get it right :-).

Regards,   Martin.

> On Sun, Dec 2, 2012 at 11:37 PM, Paul E. Jones<[email-masked]>wrote:
>
>> On Dec 2, 2012, at 8:56 PM, Nico Williams<[email-masked]>  wrote:
>>
>>> On Sun, Dec 2, 2012 at 9:24 PM, Dick Hardt<[email-masked]>  wrote:

---

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

In Oauth 2 Security considerations we reference RFC6125 to describe proper certificate validation. 
It tells servers what the right thing to do is.  For JS clients, enforcing that is admittedly a challenge.

I don't think the correct thing is to say that just because TLS is not perfect we should just give up.

Some clients will get it wrong but if the spec is correct and clear those can be made to be fixed. 
If the spec is not clear then people will do what they like as good enough.

John B.

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 11:00:25 -0600

Right, SNI is critical to being able to mandate TLS, and there's been
enough lack of coverage on the installed client and server base that a
number of hosting providers have refused to support TLS w/o per-domain
IP addresses (which cost more).

This is changing, slowly but surely.  I will re-check with my hosting
provider later today.

Nico
--

---

From: Evan Prodromou <[email-masked]>
Date: Mon, 03 Dec 2012 13:49:13 -0500

I think the problem with modeling interactions around libraries, 
function calls, and parameters is that it's presupposing a particular 
kind of operating environment.

Webfinger as defined is simple enough that you can use HTTP libraries 
directly without an intermediate chunk of software. I think those 
implementations should still be compliant, even though they don't 
implement a boolean parameter to anything.

I'd suggest if we're going to include this, it be made a SHOULD rather 
than a MUST. And if we start to go down the path of "What's a 
parameter?" and "What are possible 'false' values?" the whole thing 
should be struck out as a distraction.

-Evan

On 2012-12-01 12:55, Tim Bray wrote:
>
> I normally agree with Evan on most things, but not here. It is 
> perfectly OK and unsurprising for an Internet protocol to impose 
> behavioral constraints on software. Otherwise you could never specify 
> MustUnderstand. -T
>
> On Dec 1, 2012 6:42 AM, "Evan Prodromou" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     It doesn't belong in this spec, which isn't about libraries or
>     their APIs. If someone wants to define an IDL model for Webfinger
>     libraries in some other document, best wishes.
>
>     This document should be about the interface between clients and
>     servers, not the interface between client libraries and their
>     calling applications.
>
>     -Evan
>
>>     On Fri, Nov 30, 2012 at 2:28 PM, Breno de Medeiros
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     WebFinger client software MUST accept as input a boolean
>>     parameter which for the purposes of this discussion will be
>>     referred as "allow-fallback".
>>
>>     returns an HTTP status code indicating an error, the client
>>     software MUST report an error and cease attempting to retrieve
>>     the resource.
>>
>>     allow-fallback parameter.  If the value of allow-fallback is
>>     true, the client software MAY fall back to unencrypted HTTP in an
>>     attempt to retrieve /.well-known/webfinger.  If allow-fallback is
>>     false, client software MUST report an error and cease attempting
>>     to retrieve the resource.
>>
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
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: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2012 13:15:23 -0600

On Mon, Dec 3, 2012 at 12:49 PM, Evan Prodromou <[email-masked]> wrote:
> I think the problem with modeling interactions around libraries, function
> calls, and parameters is that it's presupposing a particular kind of
> operating environment.
>
> implementations should still be compliant, even though they don't implement
> a boolean parameter to anything.

My knee-jerk reaction is that this is irrelevant in a WF app that
internally implements a WF client.  Thinking a bit more about this I
think that fallback is the wrong compromise.  I would prefer that we
state that the WF client app/user must decide whether TLS is required
for its purpose -- no fallback.

FYI:

http://wiki.dreamhost.com/Secure_Hosting#Considerations_and_Caveats

That wiki page doesn't mention SNI, but ISTR them claiming that SNI is
not sufficiently supported by clients.

Nico
--

---

From: John Panzer <[email-masked]>
Date: Mon, 3 Dec 2012 11:21:37 -0800

If we do allow http-only servers, then for interop I'd suggest this
language:

"Clients MUST be able to be configured so that they can successfully query
a TLS-only server."

On Mon, Dec 3, 2012 at 10:49 AM, Evan Prodromou <[email-masked]> wrote:

> function calls, and parameters is that it's presupposing a particular kind
> of operating environment.
>
> than a MUST. And if we start to go down the path of "What's a parameter?"
> and "What are possible 'false' values?" the whole thing should be struck
> out as a distraction.
>
> -Evan
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Mon, 3 Dec 2012 11:32:17 -0800

> a boolean parameter to anything.

No existing HTTP library does fallback from HTTPS to HTTP, though, so
there's still a bit of intermediate software required if we allow HTTP.  If
we say HTTPS-only, though, then every HTTP library is a WebFinger library.