Subject: [webfinger] Current HTTP/HTTPS Language

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

Folks,

Here's the current language.  I get the feeling more people like this than
what we had before.  Now, what fine-tuning do we need to do?  Or are people
still of the mind that we need HTTPS only no matter what?

Current language:

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 server returns a 4xx or 5xx status code, or the HTTPS connection cannot
be established for any reason, the client MUST accept that the WebFinger
query has failed and MUST NOT attempt to reissue the WebFinger request using
HTTP.

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.

I would like to suggest we strike ", but MUST NOT attempt to use both,
either serially or in parallel".  Let the client decide what to do based on
its security requirements.

I would like to suggest we change "If a query is issued using HTTPS" to "If
a query is issued using HTTPS because it has strict security requirements".
Reasoning, again, is that if a client like a blog server issues a query via
HTTPS looking for a user's avatar and it fails, why not let it use HTTP?
Actually, we could probably just remove this whole second paragraph.  We
could just speak to the certificate checking on the security section as it
relates to secure clients.

Thus, I propose we go with this (with or without the middle paragraph):

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, though use of HTTPS is RECOMMENDED in most situations.

If a query is issued using HTTPS because it has strict security requirements
and the server has an invalid certificate, the server returns a 4xx or 5xx
status code, or the HTTPS connection cannot be established for any reason,
the client MUST accept that the WebFinger query has failed and MUST NOT
attempt to reissue the WebFinger request using HTTP.

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.

Paul

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 17:05:09 +0100

Are we foregoing the secure links filtering idea?

On Sat, Dec 15, 2012 at 5:02 PM, Kingsley Idehen <[email-masked]>wrote:

>  On 12/15/12 2:56 AM, Paul E. Jones wrote:
>
>  Folks,****
>
> ** **
>
> Here’s the current language.  I get the feeling more people like this than
> still of the mind that we need HTTPS only no matter what?****
>
> ** **
>
> Current language:****
>
> ** **
>
> 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 server returns a 4xx or 5xx status code, or the HTTPS
> connection cannot be established for any reason, the client MUST accept
> that the WebFinger query has failed and MUST NOT attempt to reissue the
> WebFinger request using HTTP.****
>
> ** **
>
> automatically follow all other server redirects.****
>
> ** **
>
> I would like to suggest we strike “, but MUST NOT attempt to use both,
> either serially or in parallel”.  Let the client decide what to do based on
> its security requirements.****
>
> ** **
>
> I would like to suggest we change “If a query is issued using HTTPS” to
> “If a query is issued using HTTPS because it has strict security
> requirements”.  Reasoning, again, is that if a client like a blog server
> issues a query via HTTPS looking for a user’s avatar and it fails, why not
> let it use HTTP?  Actually, we could probably just remove this whole second
> paragraph.  We could just speak to the certificate checking on the security
> section as it relates to secure clients.****
>
> ** **
>
> Thus, I propose we go with this (with or without the middle paragraph):***
> *
>
> ** **
>
> HTTP.  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 because it has strict security
> requirements and the server has an invalid certificate, the server returns
> a 4xx or 5xx status code, or the HTTPS connection cannot be established for
> any reason, the client MUST accept that the WebFinger query has failed and
> MUST NOT attempt to reissue the WebFinger request using HTTP.****
>
> ** **
>
> automatically follow all other server redirects.****
>
> ** **
>
> Paul****
>
> ** **
>
> +1
>
> --
>
> Regards,
>
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 15 Dec 2012 08:19:43 -0800

+0.5

I think the language at the bottom is better than the language at the top.

I continue to feel that HTTPS only is better, but perhaps HTTPS only deployments will be driven by clients that will ONLY support HTTPS. Given the strong desire by some (even though they fail to explain why :), this may be the best that we can do to reach consensus.

-- Dick
On Dec 14, 2012, at 11:56 PM, "Paul E. Jones" <[email-masked]> wrote:

> Folks,
>  
> Here’s the current language.  I get the feeling more people like this than what we had before.  Now, what fine-tuning do we need to do?  Or are people still of the mind that we need HTTPS only no matter what?
>  
> Current language:
>  
> 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 server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.
>  
> 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.
>  
> I would like to suggest we strike “, but MUST NOT attempt to use both, either serially or in parallel”.  Let the client decide what to do based on its security requirements.
>  
> I would like to suggest we change “If a query is issued using HTTPS” to “If a query is issued using HTTPS because it has strict security requirements”.  Reasoning, again, is that if a client like a blog server issues a query via HTTPS looking for a user’s avatar and it fails, why not let it use HTTP?  Actually, we could probably just remove this whole second paragraph.  We could just speak to the certificate checking on the security section as it relates to secure clients.
>  
> 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, though use of HTTPS is RECOMMENDED in most situations.
>  
> If a query is issued using HTTPS because it has strict security requirements and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and MUST NOT attempt to reissue the WebFinger request using HTTP.
>  
> 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.
>  
> Paul

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 17:26:57 +0100

On Sat, Dec 15, 2012 at 5:19 PM, Dick Hardt <[email-masked]> wrote:

> I continue to feel that HTTPS only is better, but perhaps HTTPS only
> deployments will be driven by clients that will ONLY support HTTPS. Given
> the strong desire by some (even though they fail to explain why :), this
> may be the best that we can do to reach consensus.
>

I think I've made several points as to why HTTP is a valid option.

---

From: James M Snell <[email-masked]>
Date: Sat, 15 Dec 2012 09:45:27 -0800

On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones <[email-masked]>wrote:

> **

Note that there is a different between a user-agent automatically falling
back to http and a user issuing a second request after failing. The former
involves no user-interaction with the second step, the latter requires it.
Client implementations ought to be forbidden from automatic fallbacks.
Require intentional intervention to issue the secondary request. This is no
different really than the issues involved in automatic redirection of
unsafe HTTP methods (see [1] section 7.4).

[1]
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_text=1

So rather than removing that paragraph, try this:

"If a query is issued using HTTPS and the server has an invalid
certificate, the server returns a 4xx or 5xx status code, or the HTTPS
connection cannot be established for any reason, the client MUST accept
that the WebFinger query has failed and SHOULD NOT attempt to automatically
reissue the WebFinger request using HTTP. This failure condition SHOULD be
reported to the user. Following such a failure, a client MAY attempt to
issue a separate subsequent query over HTTP if an application's security
requirements permit."

This would require that any subsequent HTTP fallbacks would occur only
after human intervention (either the user reissues the request or a
developer specifically handles the failure and sends a new request). In
either case, fallback requires a conscious choice to accept the fallback
risks.

- James

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

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 18:58:48 +0100

On Sat, Dec 15, 2012 at 6:45 PM, James M Snell <[email-masked]> wrote:

>> Here’s the current language.  I get the feeling more people like this
>> than what we had before.  Now, what fine-tuning do we need to do?  Or are
>> people still of the mind that we need HTTPS only no matter what?****
>>
>> ** **
>>
>> Current language:****
>>
>> ** **
>>
If you are just querying for 'public' information (no security concerns),
then this encourages an HTTP-first with automatic HTTPS fallback process
from the client end. The other way around, you are saying it would be
mandated that the client would need to abort on a 404 or otherwise failure
to connect (maybe they don't have an HTTPS service running at all), and the
user of the library would need to write in functionality to handle that
case and issue the request again using HTTP.

> - James
>
> **
>>
>> Thus, I propose we go with this (with or without the middle paragraph):**
>> **
>>
>> ** **
>>

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sat, 15 Dec 2012 20:18:53 +0000

> If you are just querying for 'public' information (no security concerns),
[snip]
not sure if we stay on the same page with security concerns and public/private terminology

all information we request with webfinger i would consider public since it doesn't use any ACL, so instead of saying (no security concers) when querying for public information, i would say *quering for information that we don't mind receiving spoofed response*...

on example of OpenID, information about server which i use for that i consider fully public but if someone accepted it over HTTP it would open possibility for impostors!

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 21:23:08 +0100

> on example of OpenID, information about server which i use for that i consider fully public but if someone accepted it over HTTP it would open possibility for impostors!

Right. I realized I should have used different wording after I sent
it. Thanks for clarifying.

---

From: Evan Prodromou <[email-masked]>
Date: Sat, 15 Dec 2012 15:35:14 -0500

-1

Well-written implementations are going to fallback to HTTP, to HostMeta 
+ LRDD, and possibly to SWD because that's what's right for the users. 
Very-well-written implementations will carefully choose which 
combination of SSL and non-SSL makes sense for their application.

We need to stop backseat driving. Balancing the requirements of getting 
the information that the user has requested, versus various security 
risks, is something that implementers do.

Some will do it wrong. That is how technology works.

No one will tell users that they can't have the data they need because 
technically the spec says MUST NOT right here in section 5.1.2.  
However, a good cluster of convoluted MUST/MUST NOT language will be 
enough to keep people from ever implementing the spec in the first place.

I suggest the following language:

    Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS.
    Servers MAY provide a /.well-known/webfinger endpoint over HTTP.

    Clients SHOULD request Webfinger documents via
    /.well-known/webfinger over HTTPS. Clients MAY request Webfinger
    documents via /.well-known/webfinger over HTTP.

    There are a class of attacks on HTTP-only requests listed in the
    Security Considerations. There are additional potential attacks on
    mixed HTTPS and HTTP requests. Where possible, it is RECOMMENDED
    that clients and servers use HTTPS only.

Those of us who care about micromanaging the client request flow should 
take the time to build liberally-licensed Open Source libraries for 
Python, Perl, Java, C++, JavaScript and Ruby. Code is law.

-Evan

On 12-12-15 02:56 AM, Paul E. Jones wrote:
>
> Folks,
>
> Here's the current language.  I get the feeling more people like this 
> than what we had before.  Now, what fine-tuning do we need to do?  Or 
> are people still of the mind that we need HTTPS only no matter what?
>
> Current language:
>
> 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.
>
> connection cannot be established for any reason, the client MUST 
> accept that the WebFinger query has failed and MUST NOT attempt to 
> reissue the WebFinger request using HTTP.
>
> 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.
>
> either serially or in parallel".  Let the client decide what to do 
> based on its security requirements.
>
> I would like to suggest we change "If a query is issued using HTTPS" 
> to "If a query is issued using HTTPS because it has strict security 
> requirements". Reasoning, again, is that if a client like a blog 
> server issues a query via HTTPS looking for a user's avatar and it 
> fails, why not let it use HTTP?  Actually, we could probably just 
> remove this whole second paragraph.  We could just speak to the 
> certificate checking on the security section as it relates to secure 
> clients.
>
> 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, though use of HTTPS is RECOMMENDED in most 
> situations.
>
> requirements and the server has an invalid certificate, the server 
> returns a 4xx or 5xx status code, or the HTTPS connection cannot be 
> established for any reason, the client MUST accept that the WebFinger 
> query has failed and MUST NOT attempt to reissue the WebFinger request 
> using HTTP.
>
> 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.
>
> Paul
>
>
>

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 21:49:02 +0100

+1 totally agree here. Keep things simple and flexible and let the
developers worry about client implementation.

The only, BUT, I have is the case where we decide there are 'secure' links
that shouldn't be divulged over HTTP (Brad proposed this the other day). IF
that moves forward then I think we should have server-side filtering of
that data over HTTP. I otherwise completely agree with what Evan proposes
below.

On Sat, Dec 15, 2012 at 9:35 PM, Evan Prodromou <[email-masked]> wrote:

>  -1
>
> Well-written implementations are going to fallback to HTTP, to HostMeta +
> LRDD, and possibly to SWD because that's what's right for the users.
> Very-well-written implementations will carefully choose which combination
> of SSL and non-SSL makes sense for their application.
>
> the information that the user has requested, versus various security risks,
> is something that implementers do.
>
> technically the spec says MUST NOT right here in section 5.1.2.  However, a
> good cluster of convoluted MUST/MUST NOT language will be enough to keep
> people from ever implementing the spec in the first place.
>
> Clients SHOULD request Webfinger documents via /.well-known/webfinger over
> HTTPS. Clients MAY request Webfinger documents via /.well-known/webfinger
> over HTTP.
>
> There are a class of attacks on HTTP-only requests listed in the Security
> Considerations. There are additional potential attacks on mixed HTTPS and
> HTTP requests. Where possible, it is RECOMMENDED that clients and servers
> use HTTPS only.
>
> take the time to build liberally-licensed Open Source libraries for Python,
> Perl, Java, C++, JavaScript and Ruby. Code is law.
>
> -Evan
>
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
>

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sat, 15 Dec 2012 21:08:23 +0000

> that data over HTTP. I otherwise completely agree with what Evan proposes
Nick, again I have impression that you may talk about different scenario...

To my understanding Brad proposal didn't have anything to do with server but only with client. In scenario with MITM attack, client using HTTP talks to server under full control of an attacker, we can NOT expect any support from server side code in this case. So client which made request over HTTP needs to take into account receiving spoofed response and don't use it for anything serious!

Maybe instead of secure/non-secure we can use terms serious/non-serious content ;D

All the data we publish at our webfinger endpoints stays publicly accessible so I see no need for any filtering on a server...

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 22:25:03 +0100

> To my understanding Brad proposal didn't have anything to do with server but only with client. In scenario with MITM attack, client using HTTP talks to server under full control of an attacker, we…

Yes I completely understand the scenario. Brads' proposal was for
marking 'security related' links as 'secure' (which is why I
used the word 'secure' in single quotes), then mandating that the
client implement filtering of these 'security related' links if they
were retrieved over HTTP. I was adding that, if we do this, the server
should also filter this data when sending a response over HTTP as a
precaution against a poorly written client library.

We discussed this in-depth in other threads, and I was trying to keep
the comment short so as not to distract / carry on about things we
already hashed out.

> Maybe instead of secure/non-secure we can use terms serious/non-serious content ;D

Sure, that works for me.

> All the data we publish at our webfinger endpoints stays publicly accessible so I see no need for any filtering on a server...

Because if we differentiate between 'serious' and 'non-serious' links,
then we serve out 'serious' links over HTTP, inevitably lazy client
code will use that to retrieve authentication related links. If we
mark links as 'serious' then we should implement accordingly on both
ends (IMO).

I think about this in terms of my own server. If someone retrieves
something 'serious' from my server and acts on it. I have the peace of
mind they got that via. HTTPS because my server does not send it out
for HTTP requests.

---

From: Nick Jennings <[email-masked]>
Date: Sat, 15 Dec 2012 22:28:11 +0100

>> In scenario with MITM attack

Don't you mean (Wo)MITM ? :)

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sat, 15 Dec 2012 21:54:29 +0000

> Don't you mean (Wo)MITM ? :)
** Affirmative

i guess we all may want to work more on gender neutrality... how about AITM - Attacker In The Middle ?

** Out

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 01:32:54 -0500

The secure links idea is separate from the problem at hand: when does a device use HTTPS vs HTTP and when is it acceptable to query HTTP?

The secure links idea (which I don’t particularly like) helps the server decide what to return.  At least as I understand it.  Since there is nothing secure about a link in and of itself, I don’t see any reason to classify link types.  But, a server is certainly free to return whatever it likes over HTTP, and that might be different than what it returns over HTTP.  But, why bother?  If we ensure proper client behavior, it’s not an issue. And by “proper”, that means ensuring that clients that absolutely need to ensure that data is not modified in flight must only use HTTPS.  Any client that does not have that restriction could do what it wants, but with some reasonable guidance … that we’re trying to hammer out.

Paul

From: Nick Jennings [mailto:[email-masked]] 
Sent: Saturday, December 15, 2012 11:05 AM
To: [email-masked]
Cc: Paul E. Jones; [email-masked]
Subject: Re: Current HTTP/HTTPS Language

On Sat, Dec 15, 2012 at 5:02 PM, Kingsley Idehen <[email-masked]> wrote:

Folks,

Current language:

Paul

+1

-- 
 
Regards,
 
Kingsley Idehen             
Founder & CEO 
OpenLink Software

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 01:50:49 -0500

James,

But the client should automatically switch to using HTTP if security is not an issue.  Again, if I’m running a blog and I really don’t care if the avatar link I grab for you gets “hacked” in flight, I might issue this query:

   wf.query("acct:[email-masked]", WF_NON_SECURE);

This would query using HTTPS, but if it failed, try HTTP automatically.

Someone suggested the second parameter should default to SECURE, meaning the client ONLY uses HTTP.  That’s reasonable.  So, if either of these calls were made:

   wf.query("acct:[email-masked]");

   wf.query("acct:[email-masked]", WF_SECURE);

Then only HTTPS wouyld be queried and no attempt would be made via HTTP.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Saturday, December 15, 2012 12:45 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] Current HTTP/HTTPS Language

On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones <[email-masked]> wrote:

Folks,

Current language:

 

Note that there is a different between a user-agent automatically falling back to http and a user issuing a second request after failing. The former involves no user-interaction with the second step, the latter requires it. Client implementations ought to be forbidden from automatic fallbacks. Require intentional intervention to issue the secondary request. This is no different really than the issues involved in automatic redirection of unsafe HTTP methods (see [1] section 7.4). 

[1] http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/?include_text=1

"If a query is issued using HTTPS and the server has an invalid certificate, the server returns a 4xx or 5xx status code, or the HTTPS connection cannot be established for any reason, the client MUST accept that the WebFinger query has failed and SHOULD NOT attempt to automatically reissue the WebFinger request using HTTP. This failure condition SHOULD be reported to the user. Following such a failure, a client MAY attempt to issue a separate subsequent query over HTTP if an application's security requirements permit."

This would require that any subsequent HTTP fallbacks would occur only after human intervention (either the user reissues the request or a developer specifically handles the failure and sends a new request). In either case, fallback requires a conscious choice to accept the fallback risks.

- James

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 15 Dec 2012 22:52:33 -0800

On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones <[email-masked]>wrote:

>
> The secure links idea (which I don’t particularly like) helps the server
> decide what to return.  At least as I understand it.
>

No, you misunderstand it.

Maybe you don't like it because you don't understand it.  I'll try to
rephrase:

> Since there is nothing secure about a link in and of itself, I don’t see
> any reason to classify link types.
>

The point was to encode classification (a rel type's "requires-HTTPS"
property) into the rel type itself, so clients could be free of any
configuration (nobody has to say "I want secure" or "sure, HTTP works I
guess?") and clients can then safely failover from HTTPS to HTTP, since the
*client* (again! the client, NOT the server) does the filtering.

>   But, a server is certainly free to return whatever it likes over HTTP,
> and that might be different than what it returns over HTTP.  But, why
> bother?
>

I think your "why bother?" might be about a line of confusion that's
unrelated to my bother:  I'm bothered by webfinger being vulnerable to
MITM, and users having to opt-in to security.

> If we ensure proper client behavior, it’s not an issue. And by “proper”,
> that means ensuring that clients that absolutely need to ensure that data
> is not modified in flight must only use HTTPS.  Any client that does not
> have that restriction could do what it wants, but with some reasonable
> guidance … that we’re trying to hammer out.
>

I'm fine with people using HTTP to fetch certain links.

What I am NOT fine with is people telling their webfinger client, "Please
fetch me the https://openid.net/connect/server link for [email-masked].
Oh, wait, what?  I have to pick HTTPS or HTTP now?  Oh, whatever, HTTP."
 And then it doesn't matter what your server returned, because the user's
already been MITMed.

HTTPS-only avoids this complication, but if we're going to permit HTTP, I
was at least hoping we could make secure uses of WebFinger have a much
higher likelihood of being secure but classifying rel types (NOT
classifying links) and teaching clients that some rel types are HTTPS-only
and the rest are whatever (since a lot of people don't seem to care about
the security of their avatar or name).

I'm willing to draw pictures or write such a client in the language of your
choice to demonstrate this, if it's still unclear.

---

From: James M Snell <[email-masked]>
Date: Sat, 15 Dec 2012 22:57:58 -0800

On Sat, Dec 15, 2012 at 10:50 PM, Paul E. Jones <[email-masked]>wrote:

> James,****
>
> ** **
>
> But the client should automatically switch to using HTTP if security is
> not an issue.  Again, if I’m running a blog and I really don’t care if the
> avatar link I grab for you gets “hacked” in flight, I might issue this
> query:****
>
>    wf.query("acct:[email-masked]", WF_NON_SECURE);****
>
> **
>
**
>
> This would query using HTTPS, but if it failed, try HTTP automatically.***
> *
>
> **
>

Question... if fallback is automatic.. what happens in the following
situation:

1. Client sends a request to HTTPS... server responds with a 5xx...
2. Client sends a request to HTTP automatically.. server responds with a
3xx redirect to HTTPS, because the server says HTTPS is required.
3. Client follows the redirect and sends a request to HTTPS... server
responds with a 5xx... rinse, repeat

Second question, if security really isn't an issue, why would I issue the
request over HTTPS in the first place? Why wouldn't I just try HTTP first
and hope for the best?

- James

>  **
>
> Someone suggested the second parameter should default to SECURE, meaning
> the client ONLY uses HTTP.  That’s reasonable.  So, if either of these
> calls were made:****
>
> ** **
>
>    wf.query("acct:[email-masked]");****
>
>    wf.query("acct:[email-masked]", WF_SECURE);****
>
> ** **
>
> Then only HTTPS wouyld be queried and no attempt would be made via HTTP.**
> **
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Saturday, December 15, 2012 12:45 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [webfinger] Current HTTP/HTTPS Language****
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Dec 14, 2012 at 11:56 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> Folks,****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> unsafe HTTP methods (see [1] section 7.4). ****
>
> ** **
>
> [1]
> ****
> So rather than removing that paragraph, try this:****
>
> ** **
>
> requirements permit."****
>
>  ****
>
> risks.****
> - James****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/webfinger****
>
> ** **
>

---

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

Evan,

Maybe I'm confused a bit, but I thought we were saying the same thing,
really.  What I proposed was the we simplify the text to this:

 

We still seem to be stuck at the "do we require TLS only" or "do we not".
If we do not mandate TLS, then I think the above rules are OK.

Separate from this, we need to have that bit of text that explains that a
client that needs to guarantee that data is not modified while being
transmitted from the server to the client MUST only use HTTPS.  Perhaps give
an example of where a client's security requirements might vary from another
client.  And we need to explain a bit about how client libraries should
support such clients (having a "secure" request being the default).

Dare I suggest it again, but we could just explain that there are two types
of clients: those that need security and those that do not.  In all cases,
HTTPS should be queried first.  If an HTTPS query fails and the client can
accept a non-secure reply, then the client may issue an HTTP query.  So,
just write the procedures explicitly leaving no room for alternate possible
ways of issuing a query.  We want predictable results, after all.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Evan Prodromou
Sent: Saturday, December 15, 2012 3:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [webfinger] Current HTTP/HTTPS Language

-1

Well-written implementations are going to fallback to HTTP, to HostMeta +
LRDD, and possibly to SWD because that's what's right for the users.
Very-well-written implementations will carefully choose which combination of
SSL and non-SSL makes sense for their application.

We need to stop backseat driving. Balancing the requirements of getting the
information that the user has requested, versus various security risks, is
something that implementers do.

Servers SHOULD provide a /.well-known/webfinger endpoint over HTTPS. Servers
MAY provide a /.well-known/webfinger endpoint over HTTP.

Those of us who care about micromanaging the client request flow should take
the time to build liberally-licensed Open Source libraries for Python, Perl,
Java, C++, JavaScript and Ruby. Code is law.

-Evan 

Folks,

Current language:

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sat, 15 Dec 2012 23:16:53 -0800

On Sat, Dec 15, 2012 at 11:12 PM, Paul E. Jones <[email-masked]>wrote:

> Evan,****
>
> ** **
>
> Maybe I’m confused a bit, but I thought we were saying the same thing,
> really.  What I proposed was the we simplify the text to this:****
>
> ** **
>
> We still seem to be stuck at the “do we require TLS only” or “do we not”.
> If we do not mandate TLS, then I think the above rules are OK.****
>
> ** **
>
> transmitted from the server to the client MUST only use HTTPS.  Perhaps
> give an example of where a client’s security requirements might vary from
> another client.  And we need to explain a bit about how client libraries
> should support such clients (having a “secure” request being the default).
> ****
>
> ** **
>
> Dare I suggest it again, but we could just explain that there are two
> types of clients: those that need security and those that do not.  In all
> cases, HTTPS should be queried first.  If an HTTPS query fails and the
> client can accept a non-secure reply, then the client may issue an HTTP
> query.  So, just write the procedures explicitly leaving no room for
> alternate possible ways of issuing a query.  We want predictable results,
> after all.****
>
> **
>

If HTTPS queries are first and HTTP fallback happens if and only if the
user has opted-in to an insecure mode, I could live with that.  It's not my
ideal, but I recognize that a lot of people want to use HTTP.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 02:44:38 -0500

Brad,

I really thought I understood this.  I think I still do, but I’ll admit that I might be missing something.

Let me explain how I expected the WF client to work.  First, I would never expect the end user ever selects a transport on a case-by-case basis.  Rather, the WF client would be integrated in software like my email client, my blog (for fetching visitor’s avatars), or perhaps on my web forums where users log into the system.

In my email client, I would expect a configuration option where WF queries are secure or they are not.  By default, I’d expect those to not be secure, since most users that would use WF from an email client don’t care.  If I get the right picture for you, good. If not, no big deal.  Some users would care, though: they would not want to fetch a vcard and get the wrong telephone number.  So, the email client would operate in either “secure” or “non-secure” mode.

Behavior for “secure mode”:

·         TLS query

·         Fail for any reason? Stop.

Behavior for “non-secure mode”:

·         TLS query

·         Failure?  Try HTTP.

My blog where you might post comments and I want to grab your avatar might operate in “non-secure” mode.  Security is not so important.  This would be provisioned by the blog admin.

The web forums where users log in would use “secure mode”.  That client would not want to be directed to the wrong IdP.

Now, some would argue that “non-secure” mode should start with HTTP and the server could re-direct the client to HTTPS or just reply.  That’s reasonable, IMO.  Either way, the “non-secure” mode is susceptible to MITM attacks, and leading with HTTP could result in a fast response.

If we allow the non-secure mode, then it’s truly non-secure.  And, it could introduce some serious problems if users blindly trust it.  Let’s say I get an email from my bank.  My email client (operating in non-secure mode) automatically grabs the contact info for [email-masked].  Somebody (not my bank) actually served the reply (blocking port 443 and providing a bogus answer on 80).  I see their phone number and call, getting some very professional-sounding person who collects information from me and then cleans out my bank account.

Without mandating HTTPS, WF might never be adopted for anything except casual stuff.  My bank would never support it, yet they would still be subject to a MITM attack!  That’s really scary.  So, there is a lot of value in the HTTPS only approach.

However, what I don’t understand in your proposal is how you would prevent this MITM attack.  If it does, I’m missing that and perhaps a pretty picture is needed.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 1:53 AM
To: Paul E. Jones
Cc: Nick Jennings; [email-masked]; [email-masked]
Subject: Re: [webfinger] Current HTTP/HTTPS Language

On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones <[email-masked]> wrote:

The secure links idea (which I don’t particularly like) helps the server decide what to return.  At least as I understand it. 

Maybe you don't like it because you don't understand it.  I'll try to rephrase:

Since there is nothing secure about a link in and of itself, I don’t see any reason to classify link types.

The point was to encode classification (a rel type's "requires-HTTPS" property) into the rel type itself, so clients could be free of any configuration (nobody has to say "I want secure" or "sure, HTTP works I guess?") and clients can then safely failover from HTTPS to HTTP, since the *client* (again! the client, NOT the server) does the filtering.

  But, a server is certainly free to return whatever it likes over HTTP, and that might be different than what it returns over HTTP.  But, why bother? 

I think your "why bother?" might be about a line of confusion that's unrelated to my bother:  I'm bothered by webfinger being vulnerable to MITM, and users having to opt-in to security.

If we ensure proper client behavior, it’s not an issue. And by “proper”, that means ensuring that clients that absolutely need to ensure that data is not modified in flight must only use HTTPS.  Any client that does not have that restriction could do what it wants, but with some reasonable guidance … that we’re trying to hammer out.

What I am NOT fine with is people telling their webfinger client, "Please fetch me the https://openid.net/connect/server link for [email-masked].   Oh, wait, what?  I have to pick HTTPS or HTTP now?  Oh, whatever, HTTP."  And then it doesn't matter what your server returned, because the user's already been MITMed.

HTTPS-only avoids this complication, but if we're going to permit HTTP, I was at least hoping we could make secure uses of WebFinger have a much higher likelihood of being secure but classifying rel types (NOT classifying links) and teaching clients that some rel types are HTTPS-only and the rest are whatever (since a lot of people don't seem to care about the security of their avatar or name).

I'm willing to draw pictures or write such a client in the language of your choice to demonstrate this, if it's still unclear.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 02:47:07 -0500

James,

This happens even today for various web services and could happen with just HTTPS as the transport, where server A points to B who points to C who points to A.  Clients always have to watch for loops.  I always put loop detection logic into client code I write.

Paul

From: James M Snell [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 1:58 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] Current HTTP/HTTPS Language

On Sat, Dec 15, 2012 at 10:50 PM, Paul E. Jones <[email-masked]> wrote:

James,

   wf.query("acct:[email-masked] <mailto:[email-masked]> ", WF_NON_SECURE);

Question... if fallback is automatic.. what happens in the following situation:

2. Client sends a request to HTTP automatically.. server responds with a 3xx redirect to HTTPS, because the server says HTTPS is required.

3. Client follows the redirect and sends a request to HTTPS... server responds with a 5xx... rinse, repeat

Second question, if security really isn't an issue, why would I issue the request over HTTPS in the first place? Why wouldn't I just try HTTP first and hope for the best?

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 02:50:42 -0500

Braid,

I’d expect that, but do note (as I mentioned in my last message) that a hacker can hack that, too.  They block port 443 and then rob you blind through port 80.  Non-secure really means non-secure, unless the user is explicitly told “this data is protected with HTTPS” – like a lock icon visible in my email client so I don’t call the scammers who want to rob my bank account.

Paul

Brad said…

If HTTPS queries are first and HTTP fallback happens if and only if the user has opted-in to an insecure mode, I could live with that.  It's not my ideal, but I recognize that a lot of people want to use HTTP.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 02:53:14 -0500

Damn typos…  don’t be offended.  I don’t know if you wear braids or not ;-)

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 2:51 AM
To: 'Brad Fitzpatrick'; [email-masked]'
Cc: [email-masked]'; 'Evan Prodromou'
Subject: RE: [webfinger] Current HTTP/HTTPS Language

Braid,

Paul

Brad said…

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sun, 16 Dec 2012 10:50:50 +0000

Excerpts from Brad Fitzpatrick's message of 2012-12-16 06:52:33 +0000:
[snip]
> choice to demonstrate this, if it's still unclear.
+1 for drawing pictures!
+1 for writing a .js implementation of client which one can use both in browser and in node.js

---

From: Evan Prodromou <[email-masked]>
Date: Sun, 16 Dec 2012 11:35:01 -0500

+1

I like the wording and the spirit.

-Evan

On 12-12-16 02:16 AM, Brad Fitzpatrick wrote:
>
>
> On Sat, Dec 15, 2012 at 11:12 PM, Paul E. Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Evan,
>
>     Maybe I’m confused a bit, but I thought we were saying the same
>     thing, really.  What I proposed was the we simplify the text to this:
>
>     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, though use of HTTPS is RECOMMENDED
>     in most situations.
>
>     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.
>
>     We still seem to be stuck at the “do we require TLS only” or “do
>     we not”.  If we do not mandate TLS, then I think the above rules
>     are OK.
>
>     Separate from this, we need to have that bit of text that explains
>     that a client that needs to guarantee that data is not modified
>     while being transmitted from the server to the client MUST only
>     use HTTPS. Perhaps give an example of where a client’s security
>     requirements might vary from another client.  And we need to
>     explain a bit about how client libraries should support such
>     clients (having a “secure” request being the default).
>
>     Dare I suggest it again, but we could just explain that there are
>     two types of clients: those that need security and those that do
>     not.  In all cases, HTTPS should be queried first.  If an HTTPS
>     query fails and the client can accept a non-secure reply, then the
>     client may issue an HTTP query.  So, just write the procedures
>     explicitly leaving no room for alternate possible ways of issuing
>     a query.  We want predictable results, after all.
>
>
> If HTTPS queries are first and HTTP fallback happens if and only if 
> the user has opted-in to an insecure mode, I could live with that. 
>  It's not my ideal, but I recognize that a lot of people want to use HTTP.
>
>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 16 Dec 2012 13:04:40 -0800

My proposal doesn't prevent MITM on HTTP fallback (because you can't);
rather, it neuters it:

In my secure rel proposal, after the client tries HTTPS and it fails, the
client then tries HTTP, but the client knows it's using HTTP.  It doesn't
know who the remote party is anymore (since it's just using HTTP), but the
client knows that it's speaking HTTP and not speaking HTTPS.

So, when the client receives the HTTP response, it treats it suspiciously.
 Any link rel that's security-related MUST NOT be present.  If it's
present, the server is dumb or somebody's fucking with us.  Either way,
discard that link or abort.  But if the rel is for something "unimportant"
(this mailing list seems to have concluded that names and pictures are
insecure, so let's use that example), then it can happily report: rel
"avatar" => href "http://evil.example.com/goatse.jpg", or whatever.

But how does the client know which link rels are security-related (ala
"HTTPS-only")?  Not a database, because that's hard to keep all clients
updated over time, as new link rels go into use and/or get registered with
the IANA.  Rather, we encode the HTTPS-only property into the rel type
itself: if the "rel" value begins with "https:" or begins with "secure-",
clients must never respect it when seen over an HTTP connection.  That's
the neutering.

So a MITM can stop webfinger, but can't inject fake results.

And if you want extra security for "avatar" (which isn't "secure-avatar"),
you tell your WebFinger client to go into HTTPS-only mode.  But even with
no configuration, all WebFinger clients must neuter (filter) secure rels
when seen in HTTP responses.

Here's a picture: http://i.imgur.com/rvMtk.png (also attached)

On Sat, Dec 15, 2012 at 11:44 PM, Paul E. Jones <[email-masked]>wrote:

> Brad,****
>
> ** **
>
> I really thought I understood this.  I think I still do, but I’ll admit
> that I might be missing something.****
>
> ** **
>
> Let me explain how I expected the WF client to work.  First, I would never
> expect the end user ever selects a transport on a case-by-case basis.
> Rather, the WF client would be integrated in software like my email client,
> my blog (for fetching visitor’s avatars), or perhaps on my web forums where
> users log into the system.****
>
> ** **
>
> In my email client, I would expect a configuration option where WF queries
> are secure or they are not.  By default, I’d expect those to not be secure,
> since most users that would use WF from an email client don’t care.  If I
> get the right picture for you, good. If not, no big deal.  Some users would
> care, though: they would not want to fetch a vcard and get the wrong
> telephone number.  So, the email client would operate in either “secure” or
> “non-secure” mode.****
>
> ** **
>
> Behavior for “secure mode”:****
>
> **·         **TLS query****
>
> **·         **Fail for *any* reason? Stop.****
>
> ** **
>
> Behavior for “non-secure mode”:****
>
> **·         **TLS query****
>
> **·         **Failure?  Try HTTP.****
>
> ** **
>
> My blog where you might post comments and I want to grab your avatar might
> operate in “non-secure” mode.  Security is not so important.  This would be
> provisioned by the blog admin.****
>
> ** **
>
> The web forums where users log in would use “secure mode”.  That client
> would not want to be directed to the wrong IdP.****
>
> ** **
>
> Now, some would argue that “non-secure” mode should start with HTTP and
> the server could re-direct the client to HTTPS or just reply.  That’s
> reasonable, IMO.  Either way, the “non-secure” mode is susceptible to MITM
> attacks, and leading with HTTP could result in a fast response.****
>
> ** **
>
> If we allow the non-secure mode, then it’s truly non-secure.  And, it
> could introduce some serious problems if users blindly trust it.  Let’s say
> I get an email from my bank.  My email client (operating in non-secure
> mode) automatically grabs the contact info for [email-masked].
> Somebody (not my bank) actually served the reply (blocking port 443 and
> providing a bogus answer on 80).  I see their phone number and call,
> getting some very professional-sounding person who collects information
> from me and then cleans out my bank account.****
>
> ** **
>
> Without mandating HTTPS, WF might never be adopted for anything except
> casual stuff.  My bank would never support it, yet they would still be
> subject to a MITM attack!  That’s really scary.  So, there is a lot of
> value in the HTTPS only approach.****
>
> ** **
>
> However, what I don’t understand in your proposal is how you would prevent
> this MITM attack.  If it does, I’m missing that and perhaps a pretty
> picture is needed.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Brad Fitzpatrick [mailto:[email-masked]]
> *Sent:* Sunday, December 16, 2012 1:53 AM
> *To:* Paul E. Jones
> *Cc:* Nick Jennings; [email-masked]; [email-masked]
>
> On Sat, Dec 15, 2012 at 10:32 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> ** **
>
> decide what to return.  At least as I understand it. ****
>
> ** **
>
> No, you misunderstand it.****
>
> ** **
>
> rephrase:****
> any reason to classify link types.****
>
> ** **
>
> *client* (again! the client, NOT the server) does the filtering.****
>
>  ****
>
> bother? ****
> MITM, and users having to opt-in to security.****
>
>  ****
>
> guidance … that we’re trying to hammer out.****
>
> ** **
>
> I'm fine with people using HTTP to fetch certain links.****
>
> ** **
>
> already been MITMed.****
> the security of their avatar or name).****
>
> ** **
>
> I'm willing to draw pictures or write such a client in the language of
> your choice to demonstrate this, if it's still unclear.****
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 16:21:08 -0500

Brad,

Yep, I did understand that correctly.  It would certainly address issues of certain rel types, but this approach still worries me.

Let’s say I operate that bank to which I referred in my last examples.  I want to provide contact information to my customers, but I will only provide the contact information via HTTPS.  A client looking for contact information must now look for either “secure-vcard” or “vcard”.  The client may not know which one it should use.  It gets “vcard” the “bad server” and offers that to the user.  User volunteers his personal information to some person who then robs the person blind.

So, we end up possibly creating more names (vcard vs. secure-vcard), clients do not always know exactly which form should be accepted, etc.

Given all of the complexity, I think we should go with HTTPS only for now and then work on an HTTP fallback in a WF working group.  Somebody suggested something like that earlier this week (sorry, forgot who), and I’m now of the mind that that is the way to go forward.  Start secure, introduce non-secure modes later.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 4:05 PM
To: Paul E. Jones
Cc: Nick Jennings; [email-masked]; [email-masked]
Subject: Re: [webfinger] Current HTTP/HTTPS Language

My proposal doesn't prevent MITM on HTTP fallback (because you can't); rather, it neuters it:

In my secure rel proposal, after the client tries HTTPS and it fails, the client then tries HTTP, but the client knows it's using HTTP.  It doesn't know who the remote party is anymore (since it's just using HTTP), but the client knows that it's speaking HTTP and not speaking HTTPS.

So, when the client receives the HTTP response, it treats it suspiciously.  Any link rel that's security-related MUST NOT be present.  If it's present, the server is dumb or somebody's fucking with us.  Either way, discard that link or abort.  But if the rel is for something "unimportant" (this mailing list seems to have concluded that names and pictures are insecure, so let's use that example), then it can happily report: rel "avatar" => href "http://evil.example.com/goatse.jpg", or whatever.

But how does the client know which link rels are security-related (ala "HTTPS-only")?  Not a database, because that's hard to keep all clients updated over time, as new link rels go into use and/or get registered with the IANA.  Rather, we encode the HTTPS-only property into the rel type itself: if the "rel" value begins with "https:" or begins with "secure-", clients must never respect it when seen over an HTTP connection.  That's the neutering.

And if you want extra security for "avatar" (which isn't "secure-avatar"), you tell your WebFinger client to go into HTTPS-only mode.  But even with no configuration, all WebFinger clients must neuter (filter) secure rels when seen in HTTP responses.

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Sun, 16 Dec 2012 21:25:58 +0000

> clients must never respect it when seen over an HTTP connection.  That's
personally i find using URIs more attractive than just text labels, what one gains by registering link relation with IANA?

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 16 Dec 2012 13:31:55 -0800

On Sun, Dec 16, 2012 at 1:21 PM, Paul E. Jones <[email-masked]>wrote:

> Brad,****
>
> ** **
>
> Yep, I did understand that correctly.  It would certainly address issues
> of certain rel types, but this approach still worries me.****
>
> ** **
>
> Let’s say I operate that bank to which I referred in my last examples.  I
> want to provide contact information to my customers, but I will only
> provide the contact information via HTTPS.  A client looking for contact
> information must now look for either “secure-vcard” or “vcard”.  The client
> may not know which one it should use.
>
...

> So, we end up possibly creating more names (vcard vs. secure-vcard),
> clients do not always know exactly which form should be accepted, etc.
>

I never proposed that for every "foo" there exists "secure-foo".  But let's
imagine that's the case:  why would a client ever pick "foo" over
"secure-foo"?  The choice seems obvious.

But if the client DOES know it's doing a secure operation (it's a banking
client), it goes into HTTPS-only mode.  The secure relations are just a
mechanism to say "regardless of what the client thinks, these relation
types must be HTTPS-only".  I don't think a bank would ever use any
relation type which wasn't secure, though.  Further, I don't think it would
use any relation type "secure-X" for which "X" was widely in use, lest
existing clients treat X as secure-X.

But to be realistic: banks don't have public APIs because of this and so
many other reasons. They write their own clients, because they know/imagine
everybody sucks.

****
>
> Given all of the complexity, I think we should go with HTTPS only for now
> and then work on an HTTP fallback in a WF working group.  Somebody
> suggested something like that earlier this week (sorry, forgot who), and
> I’m now of the mind that that is the way to go forward.  Start secure,
> introduce non-secure modes later.
>

Yes, please!  :-)  I was hoping that would be the result of this thread.

DirtyFinger could introduce secure rels or maybe dirty rels.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 16 Dec 2012 13:40:18 -0800

On Sun, Dec 16, 2012 at 1:25 PM, ☮ elf Pavlik ☮ <
[email-masked]> wrote:

> personally i find using URIs more attractive than just text labels, what
> one gains by registering link relation with IANA?
>

One might ask the same question about writing an RFC for the WebFinger
protocol.  Writing an RFC or registering a link relation is a formalization.

I only proposed the "secure-" prefix for IANA-registered relations in
response to a criticism that IANA-registered links could not begin with
"https://".

I personally don't care either way about which namespace rel types are in.

---

From: Nick Jennings <[email-masked]>
Date: Sun, 16 Dec 2012 23:33:04 +0100

On Sun, Dec 16, 2012 at 10:31 PM, Brad Fitzpatrick <[email-masked]> wrote:
>> and then work on an HTTP fallback in a WF working group.  Somebody suggested
>> something like that earlier this week (sorry, forgot who), and I’m now of
>> the mind that that is the way to go forward.  Start secure, introduce
>> non-secure modes later.
>
>

I'm OK with it as well, it makes sense to keep things secure, and
moving this process
along is more important to me than the downsides of no HTTP option.

However, I really hope that not only does StartSSL stay operational,
but that other free cert providers pop up. I'm a little uneasy about
that for the indieweb community. I certainly don't want to pay
$50-100/year for a cert on my personal domain just to serve WF traffic
(that would be a little silly).

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 16 Dec 2012 14:38:19 -0800

> (that would be a little silly).

FWIW, I'm in the same boat.  My personal email address is at danga.com,
which doesn't currently serve on https, so I'll have to do the Startcom
dance for that, just for WebFinger.

I likewise hope that more free SSL options become available, so we're not
reliant on them or the other "30-day-free" options.

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Mon, 17 Dec 2012 00:00:25 +0000

> clients must never respect it when seen over an HTTP connection.  That's
just for the record...
Open Graph Protocol has bit similar 'secure' notion in image, audio and video properties, from http://ogp.me
"The og:image property has some optional structured properties:

    og:image:url - Identical to og:image.
    og:image:secure_url - An alternate url to use if the webpage requires HTTPS.
"

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Mon, 17 Dec 2012 00:03:15 +0000

> reliant on them or the other "30-day-free" options.
i hope we can join forces with folks from CAcert and other related project to help fixing current situation with CAs... any suggestion in which corner of cyberspace we can collaborate on this issue?

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Dec 2012 01:14:03 +0100

On 17 December 2012 01:03, ☮ elf Pavlik ☮ <[email-masked]>wrote:

> > On Sun, Dec 16, 2012 at 2:33 PM, Nick Jennings <[email-masked]
> >wrote:
> >
> > >
> i hope we can join forces with folks from CAcert and other related project
> to help fixing current situation with CAs... any suggestion in which corner
> of cyberspace we can collaborate on this issue?
>

http://convergence.io/
https://www.eff.org/sovereign-keys
http://web.monkeysphere.info/

---

From: Blaine Cook <[email-masked]>
Date: Mon, 17 Dec 2012 00:25:00 +0000

What are the chances browsers (e.g., Chrome) are going to support any of
those non-corporate CAs? If we're planning webfinger to be supported in the
browser, that's going to be essential (c.f., CORS support), and I for one
am not keeping my hopes up.

*No-one* has said *anything* about my Github Pages example. As I've said
before, there are loads of people using that (and other, similar, less
progressive hosting options). The reason I raise Github Pages is explicitly
because they're the most progressive web host, and they don't support SSL.
I'd like to see *one* person from this community reach out to Github and
ask if they'd be willing to support SSL. If they come back and so much as
say "we'd like to support it in the future", then I'm all for going
SSL-only.

For the record, I'm totally opposed to Paul's recent suggestion that we
should just ignore deployment realities and hope webfinger drags the rest
of the web along. Most webfinger deployments are going to be
Server-to-Server anyways, so I for one think the threat model being MITM
attacks is totally blown out of proportion (a rooted server is far more
likely), and the only thing forcing SSL is going to do is slow adoption.

b.

On 17 December 2012 00:14, Melvin Carvalho <[email-masked]> wrote:

>> i hope we can join forces with folks from CAcert and other related
>> project to help fixing current situation with CAs... any suggestion in
>> which corner of cyberspace we can collaborate on this issue?
>>
>
> http://convergence.io/

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 19:51:57 -0500

Blaine,

I was not suggesting we do TLS only and stop.  First, define TLS-only signaling in the current RFC.  This allows for services like OpenID Connect to use it.  There will be others who can and will use it.

But, we then continue the dialog on how to introduce a non-secure mode.  There are several approaches on the table and there are various security considerations that we need to address for each.  There is also the user interface aspect.  I don’t want to query my bank and get the phone number of a scammer.  That might be an extreme example, but similar other examples exist.  So, we need to work through the language on UI and trust issues.

I’m only proposing we split the problem into two pieces.  There are those who want TLS only, so we offer a solution for that right away.  For the non-secure / fallback option, we take a little more time to define procedures.  We’re holding up everything on this one issue, but it ought not be the gaiting factor it is.

Paul

From: Blaine Cook [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 7:25 PM
To: [email-masked]
Cc: Brad Fitzpatrick; Nick Jennings; Paul E. Jones; webfinger
Subject: Re: [webfinger] Current HTTP/HTTPS Language

What are the chances browsers (e.g., Chrome) are going to support any of those non-corporate CAs? If we're planning webfinger to be supported in the browser, that's going to be essential (c.f., CORS support), and I for one am not keeping my hopes up.

*No-one* has said *anything* about my Github Pages example. As I've said before, there are loads of people using that (and other, similar, less progressive hosting options). The reason I raise Github Pages is explicitly because they're the most progressive web host, and they don't support SSL. I'd like to see *one* person from this community reach out to Github and ask if they'd be willing to support SSL. If they come back and so much as say "we'd like to support it in the future", then I'm all for going SSL-only.

For the record, I'm totally opposed to Paul's recent suggestion that we should just ignore deployment realities and hope webfinger drags the rest of the web along. Most webfinger deployments are going to be Server-to-Server anyways, so I for one think the threat model being MITM attacks is totally blown out of proportion (a rooted server is far more likely), and the only thing forcing SSL is going to do is slow adoption.

b.

On 17 December 2012 01:03, ☮ elf Pavlik ☮ <[email-masked]> wrote:

http://convergence.io/