Subject: [webfinger] secure links with https rels

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 12 Dec 2012 09:44:10 -0800

Thinking about the current HTTPS impasse, I thought of another avenue which
I don't recall having been discussed:

What if we,

* define some links as "secure links" (any link whose with a "rel" value
beginning with the substring "https:")

* say WebFinger servers can run on HTTPS or HTTP (making the $5/month
hosting & RootCA hater camp happy), but noting that HTTPS is recommended
and then required if "secure links" need to be returned

* say WebFinger clients MUST try to hit HTTPS first (either serially first
or in parallel with HTTP), with a fallback to HTTP (if HTTPS is
unreachable, but NOT if bad cert).

* (new) say WebFinger clients using plain HTTP MUST filter out any "secure
links" from the "links" list before giving it to their caller.

So a caller that wanted, say, "OpenID Connect" (a secure user of WebFinger)
could just write code like:

     wc = new WebFingerClient()
     server = wc.LookupHref("[email-masked]", "
https://openid.net/connect/server")  // Note "https:" prefix
     // use server, if non-empty

So rather than configuring the WebFingerClient with a requested fallback
policy, the policy is implicit in the rel requested.

This still leaves the HTTPS-only camp arguing that "there will be so many
crappy WebFinger client implementations out there" (those not doing the
secure link filtering), but the counter-argument from earlier swayed me
sufficiently: they're easily auditable, and anybody writing security
software should audit their dependencies anyway.  The "client" code is also
so simple in the grand scheme of things, this mailing list could go bust
out proper implementations in all popular languages and advertise them
loudly.

This is a bit of a compromise personally (it adds client complexity), but
I'm willing to give some of that up in exchange for WebFinger being used
more widely, for all sorts of applications.

Thoughts?

---

From: Blaine Cook <[email-masked]>
Date: Wed, 12 Dec 2012 18:35:15 +0000

Works for me.

On 12 December 2012 18:34, Breno <[email-masked]> wrote:

> Works for me.
> On Dec 12, 2012 9:44 AM, "Brad Fitzpatrick" <[email-masked]> wrote:
>
>> Thinking about the current HTTPS impasse, I thought of another avenue
>> which I don't recall having been discussed:
>>
>> What if we,
>>
>> * say WebFinger clients MUST try to hit HTTPS first (either serially
>> first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is
>> * (new) say WebFinger clients using plain HTTP MUST filter out any
>> "secure links" from the "links" list before giving it to their caller.
>>
>>
>> So a caller that wanted, say, "OpenID Connect" (a secure user of
>> WebFinger) could just write code like:
>>

---

From: Nick Jennings <[email-masked]>
Date: Wed, 12 Dec 2012 19:47:03 +0100

Brad,
I actually had a somewhat similar thought the other day (about
specifying 'secure' links) and I agree it makes sense. I don't
understand why there still has to be the "you must try HTTPS first"
rule? It defeats the purpose  of most cases where you'd want to use
HTTP.
-Nick

On Wed, Dec 12, 2012 at 7:35 PM, Blaine Cook <[email-masked]> wrote:
>>> hosting & RootCA hater camp happy), but noting that HTTPS is recommended and
>>> then required if "secure links" need to be returned
>>>
>>>      server = wc.LookupHref("[email-masked]",
>>> "https://openid.net/connect/server")  // Note "https:" prefix
>>> so simple in the grand scheme of things, this mailing list could go bust out
>>> proper implementations in all popular languages and advertise them loudly.
>>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 12 Dec 2012 10:53:02 -0800

> rule? It defeats the purpose  of most cases where you'd want to use

The order doesn't matter so much.  What matter is that the client MUST try
both to find one that succeeds.  It can't fail just after finding that just
HTTP is down or just HTTPS is down.

If you have two parties (server & client) and two options, you can't write
specs that let both parties choose just one.  If we're having two options
(HTTP and HTTPS), we either need the server to MUST listen on both HTTP and
HTTPS (which we've seen was undesirable), or we need to push the complexity
to the client (unfortunate, but less offensive to many here).

---

From: Breno <[email-masked]>
Date: Wed, 12 Dec 2012 10:34:24 -0800

Works for me.

---

From: John Panzer <[email-masked]>
Date: Wed, 12 Dec 2012 12:19:01 -0800

Does this handle property data too?  (I think so.)

On first reading I thought you were saying that the value of the target
starting with https:// would trigger this, so I was confused.  Then I
re-read and realized you were saying that rel="https://foo" is secure but
rel="http://foo" is not, which makes sense.

How would a non-http rel value be treated?  (E.g., rel="canonical").

---

From: Nick Jennings <[email-masked]>
Date: Wed, 12 Dec 2012 21:24:49 +0100

> to the client (unfortunate, but less offensive to many here).

If the order doesn't matter so much, then I'm OK with it.

Another thought about specifying secure links. What about the idea of
filtering this data on the server when it's responding to the request?
ie. if the request is coming in over HTTP, filter out the 'secure'
links.

-Nick

---

From: Brad Fitzpatrick <[email-masked]>
Date: Wed, 12 Dec 2012 12:29:25 -0800

> ie. if the request is coming in over HTTP, filter out the 'secure'

That can be a SHOULD if people really want.  It's unnecessary, adds
complexity (more words in spec, more things for server authors to do), and
doesn't solve the downgrade attack problem.  Only a client MUST can fix
that.

But outside of extra words & effort, it doesn't hurt to also filter out
secure links on the server.

---

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

But what if I’m not looking for a specific link, but just want all of the links related to [email-masked]?  I might be building a “profile” type page or I might accept a number of different pieces of data (vcard, hcard, xcard, portable contact, avatar, “preferred name”, etc.).  Then what?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Wednesday, December 12, 2012 12:44 PM
To: [email-masked]; [email-masked]
Subject: secure links with https rels

Thinking about the current HTTPS impasse, I thought of another avenue which I don't recall having been discussed:

What if we,

* define some links as "secure links" (any link whose with a "rel" value beginning with the substring "https:")

* say WebFinger servers can run on HTTPS or HTTP (making the $5/month hosting & RootCA hater camp happy), but noting that HTTPS is recommended and then required if "secure links" need to be returned

* say WebFinger clients MUST try to hit HTTPS first (either serially first or in parallel with HTTP), with a fallback to HTTP (if HTTPS is unreachable, but NOT if bad cert).

* (new) say WebFinger clients using plain HTTP MUST filter out any "secure links" from the "links" list before giving it to their caller.

So a caller that wanted, say, "OpenID Connect" (a secure user of WebFinger) could just write code like:

     server = wc.LookupHref("[email-masked]", "https://openid.net/connect/server")  // Note "https:" prefix

So rather than configuring the WebFingerClient with a requested fallback policy, the policy is implicit in the rel requested.

This still leaves the HTTPS-only camp arguing that "there will be so many crappy WebFinger client implementations out there" (those not doing the secure link filtering), but the counter-argument from earlier swayed me sufficiently: they're easily auditable, and anybody writing security software should audit their dependencies anyway.  The "client" code is also so simple in the grand scheme of things, this mailing list could go bust out proper implementations in all popular languages and advertise them loudly.

This is a bit of a compromise personally (it adds client complexity), but I'm willing to give some of that up in exchange for WebFinger being used more widely, for all sorts of applications.

Thoughts?

---

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

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

> But what if I’m not looking for a specific link, but just want all of the
> links related to [email-masked]?  I might be building a “profile” type
> page or I might accept a number of different pieces of data (vcard, hcard,
> xcard, portable contact, avatar, “preferred name”, etc.).  Then what?
>

If a successful connection to HTTPS was made, all the links would be
returned.

If plain HTTP was used, all links beginning with "https:" would be filtered
out by the client.  (just like in the single rel lookup case)

I thought that followed obviously from the proposal, sorry.

---

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

Oh, I don’t like that.  Suppose I want to provide a URL to my profile page on Google+.  There’s no security-related issues with that (as far as I’m concerned), but the URL scheme is ‘https’ for Google+.  (And I say “as far as I’m concerned”, since if you issue a query for my profile page and end up at the wrong place due to a hacker’s actions, it’s no different than visiting my homepage today.  I don’t secure that, either.)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [webfinger] secure links with https rels

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

If a successful connection to HTTPS was made, all the links would be returned.

If plain HTTP was used, all links beginning with "https:" would be filtered out by the client.  (just like in the single rel lookup case)

---

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

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

> Oh, I don’t like that.  Suppose I want to provide a URL to my profile page
> on Google+.  There’s no security-related issues with that (as far as I’m
> concerned), but the URL scheme is ‘https’ for Google+.  (And I say “as far
> as I’m concerned”, since if you issue a query for my profile page and end
> up at the wrong place due to a hacker’s actions, it’s no different than
> visiting my homepage today.  I don’t secure that, either.)
>

Okay, so denote a "secure rel" with a new "secure: true" attribute instead
of using the href's "https:" prefix?

---

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

Let me add…

If you wish to define “secure links” within the server itself, I’d be OK with that.  That’s what I thought you meant.  For example, when I put in my OpenID Provider URI, I would indicate whether that content should be returned over a secure link or not.  The server can return only the links that are not marked “secure” internally.  The server can even automatically classify some link relation types as “secure”.

It’s not automatic, but servers could definitely choose to serve different content over different transports.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Thursday, December 13, 2012 10:59 AM
To: 'Brad Fitzpatrick'; [email-masked]
Cc: [email-masked]
Subject: RE: [webfinger] secure links with https rels

Paul

---

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

On Thu, Dec 13, 2012 at 8:00 AM, Brad Fitzpatrick <[email-masked]>wrote:

>> Oh, I don’t like that.  Suppose I want to provide a URL to my profile
>> page on Google+.  There’s no security-related issues with that (as far as
>> I’m concerned), but the URL scheme is ‘https’ for Google+.  (And I say “as
>> far as I’m concerned”, since if you issue a query for my profile page and
>> end up at the wrong place due to a hacker’s actions, it’s no different than

duh, of course this doesn't work.   a MITM downgrading this to HTTP just
wouldn't put that attribute in.  This proposal only works if security is
part of the rel.

Paul, you were confused by where I meant looking for "https:" --- it's not
in the href (not the link target), but the link rel itself.

         {
           "rel" : "my_blog",
           "type" : "text/html",
           "href" : "https://plus.google.com/...."
         },

.... is not secure, because "my_blog" doesn't start with "https:".

But:

         {
           "rel" : "https://openid.net/connect/server",
           "type" : "text/html",
           "href" : "http://insecure.com/"
         },

... *is* a secure link (because the OpenID Connect rel starts with
"https:"), regardless of where the target is.

or even:

         {
           "rel" : "https://openpgp.net/public-key",
           "href" : "data:xxxxxxxxxxxxxxxxxxxxxx"
         },

Sorry, I'm sick and out of it and got confused by your confusion and sent
the stupid email proposing a "secure" attribute, which is totally broken.

---

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

On Thu, Dec 13, 2012 at 8:17 AM, Zellyn Hunter <[email-masked]> wrote:

> The http links seem to work okay...
> http://profiles.google.com/zellyn
> http://plus.google.com/110196407167832022215
>

See my previous email.  This isn't the issue.

---

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

On Thu, Dec 13, 2012 at 5:07 PM, Paul E. Jones <[email-masked]> wrote:
> Let me add…
>
> If you wish to define “secure links” within the server itself, I’d be OK
> with that.  That’s what I thought you meant.  For example, when I put in my
> OpenID Provider URI, I would indicate whether that content should be
> returned over a secure link or not.  The server can return only the links
> that are not marked “secure” internally.  The server can even automatically
> classify some link relation types as “secure”.

Yes, this is how I would like it as well. I think it' solves a lot of
these issues, and even helps to take less burden off the client.

---

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

> these issues, and even helps to take less burden off the client.

A server can do whatever it wants but it doesn't help if the client is
talking to a different server.  (after a downgrade attack)

If you want security in the whole system, it needs to have a client
component.

---

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

> If you want security in the whole system, it needs to have a client

Can you give me an example of the downgrade attack where an HTTP call
is made initially to a server?

---

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

On Thu, Dec 13, 2012 at 8:32 AM, Nick Jennings <[email-masked]>wrote:

> >> > with that.  That’s what I thought you meant.  For example, when I put
> in
> >> > my

There's no example of a downgrade attack with HTTP-only because there's
nowhere "down" to go... you're already at the bottom and can't trust
anything.

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 13 Dec 2012 11:38:11 -0500

Brad,

Some quick impressions.

 1. I'm happy to live with this compromise if it's what it takes to get
    us finished.
 2. I continue to be uncomfortable with specifying function signatures
    for "Open Source client libraries". First, because I think it's the
    wrong level of abstraction for this specification, and second,
    because I think it's a narrow view of how people are going to use
    Webfinger.
 3. The compromise proposal feels like something you do with a
    well-established protocol that you can't change. That seems
    different from what we're doing here. The signal of using an
    "https://" url for the rel is clever, but could we have a more
    explicit signal?

-Evan

On 12-12-12 12:44 PM, Brad Fitzpatrick wrote:
> * define some links as "secure links" (any link whose with a "rel" 
> value beginning with the substring "https:")
>
> hosting & RootCA hater camp happy), but noting that HTTPS is 
> recommended and then required if "secure links" need to be returned
>
>      server = wc.LookupHref("[email-masked] 
> <mailto:[email-masked]>", "https://openid.net/connect/server")  // 
> Note "https:" prefix
> So rather than configuring the WebFingerClient with a requested 
> fallback policy, the policy is implicit in the rel requested.
>
> This still leaves the HTTPS-only camp arguing that "there will be so 
> many crappy WebFinger client implementations out there" (those not 
> doing the secure link filtering), but the counter-argument from 
> earlier swayed me sufficiently: they're easily auditable, and anybody 
> writing security software should audit their dependencies anyway.  The 
> "client" code is also so simple in the grand scheme of things, this 
> mailing list could go bust out proper implementations in all popular 
> languages and advertise them loudly.
>
> This is a bit of a compromise personally (it adds client complexity), 
> but I'm willing to give some of that up in exchange for WebFinger 
> being used more widely, for all sorts of applications.
>
> Thoughts?
>
>
>
> _______________________________________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

---

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

> nowhere "down" to go... you're already at the bottom and can't trust

That's kind of my point. I was saying, that if the server filters out
secure links during HTTP requests, then it takes out a lot of client
complexity (ie. you make an HTTP request, you get only trivial data).
The client doesn't need to worry about it.

---

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

Yeah, though it would not have to be in the protocol.  In my database, I could mark each link relation as “secure” or I could classify certain link relations as “secure”.   Those so marked would only be sent via HTTPS.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 11:00 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] secure links with https rels

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

Okay, so denote a "secure rel" with a new "secure: true" attribute instead of using the href's "https:" prefix?

---

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

Don’t put it on the wire.  You want the server to filter before sending a reply.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 11:19 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] secure links with https rels

On Thu, Dec 13, 2012 at 8:00 AM, Brad Fitzpatrick <[email-masked]> wrote:

duh, of course this doesn't work.   a MITM downgrading this to HTTP just wouldn't put that attribute in.  This proposal only works if security is part of the rel.

Paul, you were confused by where I meant looking for "https:" --- it's not in the href (not the link target), but the link rel itself.

         {

           "rel" : "my_blog",

           "type" : "text/html",

         },

But:

         {

           "type" : "text/html",

         },

... *is* a secure link (because the OpenID Connect rel starts with "https:"), regardless of where the target is.

or even:

         {

         },

Sorry, I'm sick and out of it and got confused by your confusion and sent the stupid email proposing a "secure" attribute, which is totally broken.

---

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

On Thu, Dec 13, 2012 at 8:38 AM, Evan Prodromou <[email-masked]> wrote:

>    for "Open Source client libraries". First, because I think it's the wrong
>    level of abstraction for this specification, and second, because I think
>    it's a narrow view of how people are going to use Webfinger.
>
> No, quite the contrary:  this proposal doesn't advocate ANY client API
signatures.  There's no "secure-only" or "fallback-policy" configuration
like before.  You just get all links or get a specific link, however you
want your API to work.  But the webfinger client MUST not return rels
beginning with "https:" if they were retrieved over HTTP.

I think you're only thinking this because I showed pseudocode in my earlier
email.  Please confirm?

>
>    1. The compromise proposal feels like something you do with a
>    well-established protocol that you can't change. That seems different from
>    what we're doing here. The signal of using an "https://" url for the
>    rel is clever, but could we have a more explicit signal?
>
> Anything more explicit could be tweaked by an HTTPS->HTTP downgrade
attack.  Putting it in the rel is the only safe place I can think of.

---

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

> Don’t put it on the wire.  You want the server to filter before sending a

I'm concerned you're still confused about how a downgrade attack works.

Again: it DOES NOT MATTER what the server thinks it's filtering if the
client has been tricked into talking to a DIFFERENT SERVER which is then
returning malicious results.

Such as:

-- client wants "all links" for [email-masked].
-- client requests secure
https://example.com/.well-known/webfinger?resource=acct:[email-masked]
-- EVIL HIJACKER BLOCKS PORT 443
-- client then requests plain
http://example.com/.well-known/webfinger?resource=acct:[email-masked]
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:

         {
           "rel" : "https://openid.net/connect/server",
           "type" : "text/html",
           "href" : "https://attacker.openid.server/"
         },

See what happened there?

We need the *client* to say "whoa whoa, wait a minute... I contacted this
webfinger server over HTTP---- what's it doing returning rels starting with
https:? I'm gonna skip over those (or just return an error)."

The real webfinger server _was never even contacted_, so it doesn't matter
whether it was filtering or not.

---

From: John Panzer <[email-masked]>
Date: Thu, 13 Dec 2012 09:18:19 -0800

Right.  This is also why you need this attribute as part of the official
"name" of the link relation, so the client knows which ones are supposed to
be secure with a simple .startsWith("https") type of check.  Anything more
complicated will create more security issues.  (A registry of relations
which tells you which link relations are secure-only might work but only if
it could be kept up to date on all clients...)

I still don't understand what the client will do with rel="canonical"
though.  Does WebFinger exclude registered rel-values?  They don't have to
be URIs.
--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 13 Dec 2012 18:21:51 +0100

Indeed « href » should be checked instead of « rel » in order to support registered values as well. Plus some link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sips:, wss:, accts:?
Although I can understand the issue I'm starting to get confused as well...

Da: [email-masked] [mailto:[email-masked]] Per conto di John Panzer
Inviato: giovedì 13 dicembre 2012 18.18
A: [email-masked]
Cc: Paul E. Jones; [email-masked]
Oggetto: Re: [webfinger] secure links with https rels

Right.  This is also why you need this attribute as part of the official "name" of the link relation, so the client knows which ones are supposed to be secure with a simple .startsWith("https") type of check.  Anything more complicated will create more security issues.  (A registry of relations which tells you which link relations are secure-only might work but only if it could be kept up to date on all clients...)

I still don't understand what the client will do with rel="canonical" though.  Does WebFinger exclude registered rel-values?  They don't have to be URIs.
--
John Panzer / Google
[email-masked]<mailto:[email-masked]> / abstractioneer.org<http://www.abstractioneer.org/> / @jpanzer

On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Dec 13, 2012 at 8:45 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
Don't put it on the wire.  You want the server to filter before sending a reply.

Again: it DOES NOT MATTER what the server thinks it's filtering if the client has been tricked into talking to a DIFFERENT SERVER which is then returning malicious results.

Such as:
-- client wants "all links" for [email-masked]<mailto:[email-masked]>.
-- client requests secure https://example.com/.well-known/webfinger?resource=acct:[email-masked]
-- EVIL HIJACKER BLOCKS PORT 443
-- client then requests plain http://example.com/.well-known/webfinger?resource=acct:[email-masked]
-- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:
         {
           "rel" : "https://openid.net/connect/server",
           "type" : "text/html",
           "href" : "https://attacker.openid.server/"
         },

See what happened there?
We need the *client* to say "whoa whoa, wait a minute... I contacted this webfinger server over HTTP---- what's it doing returning rels starting with https:? I'm gonna skip over those (or just return an error)."

The real webfinger server _was never even contacted_, so it doesn't matter whether it was filtering or not.

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

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

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

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

On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  Indeed « href » should be checked instead of « rel » in order to support
> registered values as well. Plus some link rels may not be http (think at
> acct:, sip:, ws:, ecc). So the client may need to check as well for sips:,
> wss:, accts:? ****
>
> Although I can understand the issue I’m starting to get confused as well…
>

No, the key (the link.rel) is what is secure, not the value (the link.href).

So all of acct:, sip:, ws:, data:, etc can be used as as the value, since
that's not the part that is checked for an "https:" prefix.

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Dec 2012 18:16:45 +0000

I think some people want to use acct: ass the link relation between WF documents.

That is probably a bad idea for other reasons but I think that might be confusing some people about the rel https: filter.

Having the server filter https: rels out of responses from http: endpoints is nice but as was pointed out won't on it's own stop a downgrade.

The only effective rule would be to have the client do the filtering.

I still think https: only is the only way to not make the client a horrible mess and have acceptable security.

I would rather see WF as http only than try and do both.

John B.

On 2012-12-13, at 5:28 PM, Brad Fitzpatrick <[email-masked]> wrote:

> On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <[email-masked]> wrote:
> So all of acct:, sip:, ws:, data:, etc can be used as as the value, since that's not the part that is checked for an "https:" prefix.
>

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Thu, 13 Dec 2012 18:19:08 +0000

> The client doesn't need to worry about it.
to my understanding we talk about situation when *(wo)man in the middle* controls which server your HTTP requests goes to and (s)he has full control over it!

in such case client needs to take care of security *on it's own* and  would use logic:

if I get profile from request made over HTTP, i should disregard any links which have /^https/ in their *rel* attribute...

otherwise please count me in as yet another confused person ;D

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:20:32 -0800

Huh? This particular conversation is extremely confusing at this point.
Link rel values are neither secure nor insecure. They're JUST labels. They
provide no information at all about the security requirements of the linked
resource.

If I have...

(A)
{
  "rel": "canonical",
  "href": "http://example.org/foo"
}

(B)
{
  "rel": "canonical",
  "href": "https://example.org/foo"
}

Then (A) is insecure and (B) is secure. It's that simple. All this talk of
checking rel values for "https:" is nonsense.

The real question here appears to be one of integrity: how does the client
know that the information provided in the WebFinger document is the right
information from a trusted source? HTTPS isn't enough to verify that. If
you want to do it right, you add a cryptographic signature to the document
generated with a key that the client trusts. Once the client verifies that
the information is trustworthy, it can scan through looking for the links
it wants. If it needs a secure link, it looks for ones whose href
attributes specify "https".

- James

On Thu, Dec 13, 2012 at 9:28 AM, Brad Fitzpatrick <[email-masked]>wrote:

>>  Indeed « href » should be checked instead of « rel » in order to
>> support registered values as well. Plus some link rels may not be http
>> (think at acct:, sip:, ws:, ecc). So the client may need to check as well
>> for sips:, wss:, accts:? ****
>>

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 13 Dec 2012 19:24:52 +0100

Bill (Mills) is proposing to register some oauth* link rels that would be useful for autoconfiguration. These would not be prefixed by https as keys, but the values certainly... (And I'd like considering them as 'secure links')

Le 13 déc. 2012 à 18:28, "Brad Fitzpatrick" <[email-masked]<mailto:[email-masked]>> a écrit :

On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <[email-masked]<mailto:[email-masked]>> wrote:
Indeed « href » should be checked instead of « rel » in order to support registered values as well. Plus some link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sips:, wss:, accts:?
Although I can understand the issue I’m starting to get confused as well…

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:25:34 -0800

> https:? I'm gonna skip over those (or just return an error)."
No... that's just nonsense. The real issue here is that the client has
absolutely no way of detecting that the evil hijacker intercepted the
request and provided false information in the first place. It should not
matter at all if the returned document contains link rels with "https:" in
them or not.

- James

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 10:30:39 -0800

> matter at all if the returned document contains link rels with "https:" in

You can never detect with HTTP that the connection was intercepted.  That
doesn't matter, because the client does know one thing:  that it used HTTP
(and not HTTPS).  So the client can filter out links which should not ever
appear over plain HTTP.  I'm proposing that rels which begin with "https:"
should never go over HTTP, and I've started calling those "secure rels".
 Maybe that's a bad name, if enough people (including you now, in your
earlier email) assume that I'm talking about the value (the href).

I'm open to alternative name suggestions.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 10:33:45 -0800

On Thu, Dec 13, 2012 at 10:24 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  Bill (Mills) is proposing to register some oauth* link rels that would
> be useful for autoconfiguration. These would not be prefixed by https as
> keys, but the values certainly... (And I'd like considering them as 'secure
> links')
>

That wouldn't work.  Try it out with the downgrade attack scenario I
described earlier to Paul.

The client is only looking for and assigning meaning to keys (the "rel"
values), so marking a rel as "secure" in the value can be faked by the
attacker, and marking the rel as secure in a new attribute can also be
faked by the attacker.

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:36:24 -0800

On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <[email-masked]>wrote:

> [snip]
I'm -1 on the whole proposal. The notion of "insecure" and "secure" link
relations makes absolutely no sense at all. It may not be possible to
detect if the HTTP connection was intercepted, but it is possible to
determine if the information provided is trustworthy. That is what
cryptographic signatures are for.

- James

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 10:36:59 -0800

> provide no information at all about the security requirements of the linked

That has been the case so far.

This thread is a proposal about changing that, and now assigning meaning to
the labels.  If the label beings with "https:", we consider it a "secure
rel" and never expect it to be transmitted over plain HTTP.  That means
servers SHOULD filter it from their responses over HTTP, but most
importantly, and paramount to the security: clients MUST NOT accept secure
rels over HTTP.  If they see one, they must filter it out.

If I have...
> Then (A) is insecure and (B) is secure. It's that simple.
>

That's not my proposal at all.  Maybe I should use a new term.  My proposal
is attaching meaning to the "rel", not the "href".

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 10:39:45 -0800

On Thu, Dec 13, 2012 at 10:36 AM, James M Snell <[email-masked]> wrote:

> relations makes absolutely no sense at all.
>

I'd like to ask that you think about and understand it before being so
negative on it.

I promise it makes sense.

> It may not be possible to detect if the HTTP connection was intercepted,
> but it is possible to determine if the information provided is trustworthy.
> That is what cryptographic signatures are for.
>

That is outside the scope of WebFinger, and may be used in subsequent hops.
 We're trying to provide a secure basis for the first hop.  If we can't get
any attribute securely for [email-masked], where are we getting the public
key from to verify subsequent use of "cryptographic signatures".

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Thu, 13 Dec 2012 18:40:59 +0000

Excerpts from James M Snell's message of 2012-12-13 18:20:32 +0000:
<snip /> 
> attributes specify "https".
how do you see implementing such cryptographic signatures from your scenario?

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 13 Dec 2012 19:43:03 +0100

Are you suggesting James to add a 'signature' property to each link rel created with the server private key? At least for the secure ones when provided over plain http?
This way a client retrieving a wf jrd over http MUST check the signature property for 'secure' hrefs and MUST discard them if such signature is not provided ?
In this case though the public key should be provided somewhere (if we're not using https)...

I remember something similar with xrd signature check in the original wf 'explanation' some years ago, but that was for the whole doc if I remember correctly. We would then need enhance jrd with a new property, if all this makes sense.

Walter

Le 13 déc. 2012 à 19:20, "James M Snell" <[email-masked]<mailto:[email-masked]>> a écrit :

Huh? This particular conversation is extremely confusing at this point. Link rel values are neither secure nor insecure. They're JUST labels. They provide no information at all about the security requirements of the linked resource.

If I have...

(A)
{
  "rel": "canonical",

(B)
{
  "rel": "canonical",

Then (A) is insecure and (B) is secure. It's that simple. All this talk of checking rel values for "https:" is nonsense.

The real question here appears to be one of integrity: how does the client know that the information provided in the WebFinger document is the right information from a trusted source? HTTPS isn't enough to verify that. If you want to do it right, you add a cryptographic signature to the document generated with a key that the client trusts. Once the client verifies that the information is trustworthy, it can scan through looking for the links it wants. If it needs a secure link, it looks for ones whose href attributes specify "https".

- James

On Thu, Dec 13, 2012 at 9:28 AM, Brad Fitzpatrick <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Dec 13, 2012 at 9:21 AM, Goix Laurent Walter <[email-masked]<mailto:[email-masked]>> wrote:
Indeed « href » should be checked instead of « rel » in order to support registered values as well. Plus some link rels may not be http (think at acct:, sip:, ws:, ecc). So the client may need to check as well for sips:, wss:, accts:?
Although I can understand the issue I’m starting to get confused as well…

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

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Thu, 13 Dec 2012 18:47:16 +0000

> cryptographic signatures are for.
-1 on statements like *makes absolutely no sense at all* unless explicitly stating in them *TO ME* ;)

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 13 Dec 2012 19:50:47 +0100

Then it means that no iana-registered link rel could ever be considered as secure, correct? That seems way too limiting to me...

Le 13 déc. 2012 à 19:33, "Brad Fitzpatrick" <[email-masked]<mailto:[email-masked]>> a écrit :

On Thu, Dec 13, 2012 at 10:24 AM, Goix Laurent Walter <[email-masked]<mailto:[email-masked]>> wrote:
Bill (Mills) is proposing to register some oauth* link rels that would be useful for autoconfiguration. These would not be prefixed by https as keys, but the values certainly... (And I'd like considering them as 'secure links')

That wouldn't work.  Try it out with the downgrade attack scenario I described earlier to Paul.

The client is only looking for and assigning meaning to keys (the "rel" values), so marking a rel as "secure" in the value can be faked by the attacker, and marking the rel as secure in a new attribute can also be faked by the attacker.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 10:52:54 -0800

On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  Then it means that no iana-registered link rel could ever be considered
> as secure, correct? That seems way too limiting to me...
>

Correct, unless iana-registered can include those with an "https:" prefix.
 Any technical reason we couldn't register full URL rels with the IANA?

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:54:15 -0800

What I'm saying is that there should be an option of adding a signature to
the JRD document as a whole, generated using a key trusted by both the
client and server. This can be provided either within the JRD document
itself (perhaps leveraging JSON Web Signatures [1]) or using an external
mechanism such as the proposed Integrity header [2]. Providing this
information would be entirely optional on the part of the server. If it is
provided, however, the client SHOULD verify it prior to consuming the data.
A client could choose not to process any JRD unless the integrity check it
provided.

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07
[2] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02

How the client and server determine which key to use to generate the
signature is out of scope but for security purposes it cannot be the same
key used to secure the HTTPS connection (if https is used at all)... since
that would rather defeat the purpose of the check and could easily be
spoofed by an attacker.

Once the integrity of the document has been verified, the client can look
for whichever links it wants in the document and ignore the ones it doesn't
want.

- James

On Thu, Dec 13, 2012 at 10:43 AM, Goix Laurent Walter <
[email-masked]> wrote:

>  Are you suggesting James to add a 'signature' property to each link rel
> created with the server private key? At least for the secure ones when
> provided over plain http?
> This way a client retrieving a wf jrd over http MUST check the signature
> property for 'secure' hrefs and MUST discard them if such signature is not
> provided ?
>  I remember something similar with xrd signature check in the original wf
> 'explanation' some years ago, but that was for the whole doc if I remember
> correctly. We would then need enhance jrd with a new property, if all this
> makes sense.
>
>  Walter
>
>
> Le 13 déc. 2012 à 19:20, "James M Snell" <[email-masked]> a écrit :
>
>  Then (A) is insecure and (B) is secure. It's that simple. All this talk
> of checking rel values for "https:" is nonsense.
>
>  The real question here appears to be one of integrity: how does the
> client know that the information provided in the WebFinger document is the
> right information from a trusted source? HTTPS isn't enough to verify that.
> If you want to do it right, you add a cryptographic signature to the
> document generated with a key that the client trusts. Once the client
> verifies that the information is trustworthy, it can scan through looking
> for the links it wants. If it needs a secure link, it looks for ones whose
> href attributes specify "https".
>
>  - James
>
>
>>  So all of acct:, sip:, ws:, data:, etc can be used as as the value,
>> since that's not the part that is checked for an "https:" prefix.
>>
>>
>     Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> *This e-mail and any attachments** is **confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.*
> *Rispetta l'ambiente. Non stampare questa
> mail se non è necessario.*
>
>

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 10:58:50 -0800

>  Any technical reason we couldn't register full URL rels with the IANA?
http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation type
names MUST conform to the reg-rel-type rule"

LOALPHA        = <any US-ASCII lowercase letter "a".."z">
reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )

You would have to update and obsolete RFC 5988 to register full URLs. I
certainly would be -1 on any effort to do so.

- James

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 11:01:31 -0800

On Thu, Dec 13, 2012 at 10:58 AM, James M Snell <[email-masked]> wrote:

>>>  Then it means that no iana-registered link rel could ever be
>>> considered as secure, correct? That seems way too limiting to me...
>>>
>>
>> Correct, unless iana-registered can include those with an "https:"
>> prefix.  Any technical reason we couldn't register full URL rels with the
>> IANA?
>>
>>

Okay: begins with "https:" or begins with "secure-".

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 11:05:42 -0800

On Thu, Dec 13, 2012 at 10:54 AM, James M Snell <[email-masked]> wrote:

> signature is out of scope but
>

Which means nobody will use this.  You can't just say "Here's a big
optional mechanism, but key details are missing... figure it out, maybe."

Also, what about this webfinger-specific?  If you want to work on signing
HTTP responses (a noble goal), that's great, but there's no reason it needs
to be lumped into WebFinger.

HTTPS, on the other hand, is well-understood and widely implemented.

WebFinger isn't supposed to be about designing a new PKI or crypto system.
 It's supposed to be a simple mechanism to read some key/value pairs.

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 11:11:02 -0800

Per RFC5988, you are certainly free to register individual link relations
that add constraints around the resources being linked to. Registering
something like "secure-canonical" that indicates that the href must always
point to an https: url would certainly be possible and well within what
rfc5988 allows. Whether or not it's a good idea is separate issue. I don't
believe it is.

Consider:

{
  "rel": "secure-canonical",
  "href": "https://example.org"
}

is no more or less secure in practice than

{
  "rel": "canonical",
  "href": "https://example.org"
}

In either case, the browser still has to ultimately look at the href value.
Further, it's not even clear exactly which problem would be addressed by
this. Introducing some notion of a "Secure" link rel will not prevent or
mitigate an attack. From the examples given in this thread, the attack
occurs well before the client processes the JRD document at all. In such
cases, *none* of the information in the JRD can be trusted and the client
should simply refuse to process it at all.

- James

On Thu, Dec 13, 2012 at 11:01 AM, Brad Fitzpatrick <[email-masked]>wrote:

>> http://tools.ietf.org/html/rfc5988#section-4.1, "Registered relation
>> type names MUST conform to the reg-rel-type rule"
>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 11:19:31 -0800

On Thu, Dec 13, 2012 at 11:11 AM, James M Snell <[email-masked]> wrote:

> In either case, the browser still has to ultimately look at the href
> value. Further, it's not even clear exactly which problem would be
> addressed by this.
>

Please see the previous messages in this thread, particularly the one where
I give an example of how a MITM https-to-http  downgrade attack works.

In the case of "secure-key-server" (or e.g. "
https://webfinger.net/rel/key-server"), the application using WebFinger
knows that if they get a link for "secure-key-server", it arrived over
HTTPS.  Because their WebFinger client software filtered out any secure
rels that arrived over HTTP.

Whether the client application then trusts the href and the href's scheme
depends on the rel & the application.

Introducing some notion of a "Secure" link rel will not prevent or mitigate
> an attack.

I've been arguing the opposite, actually.

> From the examples given in this thread, the attack occurs well before the
> client processes the JRD document at all. In such cases, *none* of the
> information in the JRD can be trusted and the client should simply refuse
> to process it at all.
>

You can't trust anything with HTTP.  Which is why I'm proposing that
clients filter out secure rels if HTTP was used.

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 11:21:55 -0800

On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick <[email-masked]>wrote:

>> What I'm saying is that there should be an option of adding a signature
>> to the JRD document as a whole, generated using a key trusted by both the
>  It's supposed to be a simple mechanism to read some key/value pairs.
Last post on the topic because I've said basically everything I think needs
to be said on it: I never said this is WebFinger specific. I'm not
suggesting that anything be "lumped into WebFinger". Nor am I suggesting
that WF be "about designing a new PKI or crypto system". If, however,
WebFinger is going to be used in cases where verifying the integrity of the
provided information is critical, then the specification needs to properly
address how the integrity of the information can be verified. HTTPS does
not provide for that. Neither does any notion of a "secure link relation".

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 14:29:43 -0500

No, I understand the downgrade attack, but that is totally unrelated to what we were talking about.

What we were discussing is that a query to an HTTPS URL might return a different set of link relations than a query to an HTTP URL.  More specifically, a query to an HTTPS URL might return things the server believes should only be returned over HTTPS, such as links to an OpenID Provider.

Nowhere in the currently proposed “compromise” text is there a proposal to fall back as you’re showing it.  A client either requests WF via HTTPS or HTTP, not both.  In the case of the latter, it’s not looking for secure content or security is a non-issue.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 11:54 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] secure links with https rels

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

Such as:

         {

           "type" : "text/html",

         },

See what happened there?

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 14:35:52 -0500

But starts with "https" does not mean security is important.  We can't use
that as the measuring stick.

And what about other URI schemes that will be used by WF?

"What is secure" needs to be determined by the WF server internally.  If
adding an OpenID link relation, as an example, the server knows (or the
server admin knows) to mark this as "deliver only via HTTPS".

The best solution, though, is if you support HTTPS have all HTTP queries
redirected to HTTPS.  This makes life so much simpler.  And if you only
support HTTP, you know you there is no security.  Clients (e.g., an client
trying to perform an OpenID login) would never even try HTTP.

Paul

From: John Panzer [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 12:18 PM
To: [email-masked]
Cc: Paul E. Jones; [email-masked]
Subject: Re: [webfinger] secure links with https rels

On Thu, Dec 13, 2012 at 8:54 AM, Brad Fitzpatrick <[email-masked]>
wrote:

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

Don't put it on the wire.  You want the server to filter before sending a
reply.

Such as:

         {

           "type" : "text/html",

         },

See what happened there?

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 13 Dec 2012 14:36:32 -0500

Fetching 
"https://example.com/.well-known/webfinger?resource=[email-masked]", 
and requiring a valid cert, I can be reasonably sure* that the entity in 
control of "example.com" asserts that the "avatar" for 
"[email-masked]" is "http://example.com/avatar/user.jpg" (or whatever).

I think this is good enough. I trust example.com to control accounts 
@example.com, more or less by definition.

Is there a counter-example I'm missing here?

-Evan

On 12-12-13 02:21 PM, James M Snell wrote:
>
>
>
> On Thu, Dec 13, 2012 at 11:05 AM, Brad Fitzpatrick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Thu, Dec 13, 2012 at 10:54 AM, James M Snell <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         What I'm saying is that there should be an option of adding a
>         signature to the JRD document as a whole, generated using a
>         key trusted by both the client and server. This can be
>         provided either within the JRD document itself (perhaps
>         leveraging JSON Web Signatures [1]) or using an external
>         mechanism such as the proposed Integrity header [2]. Providing
>         this information would be entirely optional on the part of the
>         server. If it is provided, however, the client SHOULD verify
>         it prior to consuming the data. A client could choose not to
>         process any JRD unless the integrity check it provided.
>
>         [1]
>         http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07
>         How the client and server determine which key to use to
>         generate the signature is out of scope but
>
>
>     Which means nobody will use this.  You can't just say "Here's a
>     big optional mechanism, but key details are missing... figure it
>     out, maybe."
>
>     Also, what about this webfinger-specific?  If you want to work on
>     signing HTTP responses (a noble goal), that's great, but there's
>     no reason it needs to be lumped into WebFinger.
>
>     WebFinger isn't supposed to be about designing a new PKI or crypto
>     system.  It's supposed to be a simple mechanism to read some
>     key/value pairs.
>
>
> Last post on the topic because I've said basically everything I think 
> needs to be said on it: I never said this is WebFinger specific. I'm 
> not suggesting that anything be "lumped into WebFinger". Nor am I 
> suggesting that WF be "about designing a new PKI or crypto system". 
> If, however, WebFinger is going to be used in cases where verifying 
> the integrity of the provided information is critical, then the 
> specification needs to properly address how the integrity of the 
> information can be verified. HTTPS does not provide for that. Neither 
> does any notion of a "secure link relation".
>
>
>
>

-- 
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: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 11:42:38 -0800

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

> But starts with “https” does not mean security is important.  We can’t use

No, I've been arguing that we can.

Let me see how many ways I can say the exact same thing:

Rather than say that all of WebFinger is HTTPS-only (an earlier proposal),
we say that certain rel values are HTTPS-only, and certain rel values are
either (HTTP or HTTPS).

These "HTTPS-only rels" I've been calling "secure rels", and are denoted by
the rel value (NOT the "href" value) beginning with "https:" (for those not
registered with the IANA), or beginning with "secure-" (for those
registered with the IANA).

>  And what about other URI schemes that will be used by WF?

hrefs don't matter.  Only the rel part.  "https:" or "secure-" prefix.
 Note that "secure-" isn't a scheme, because a rel is just a string, which
may be a URL or may be some token.

> ** “What is secure” needs to be determined by the WF server internally.
>

No, false.  It's determined by the use case.  An application using
WebFinger makes that call.  OpenID is secure (rel "secure-openid-server" or
something), but Evan's Status.net may want to not use secure rels, if they
do their own security some other way, so they use "http://status.net/rel/foo",
which then works over HTTPS or HTTP webfinger queries.

> redirected to HTTPS.

That's a terrible solution, since anybody can MITM that and redirect the
query to an attacker's HTTP or HTTPS server.

This makes life so much simpler.  And if you only support HTTP, you know
> you there is no security.  Clients (e.g., an client trying to perform an
> OpenID login) would never even try HTTP.
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* John Panzer [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 12:18 PM
> *To:* [email-masked]
> *Cc:* Paul E. Jones; [email-masked]
>
> *Subject:* Re: [webfinger] secure links with https rels****
>
> ** **
>
> it could be kept up to date on all clients...)****
>
> ** **
>
> ****
> [email-masked] / abstractioneer.org <http://www.abstractioneer.org/>/ @jpanzer
> ****
>
>
>
> ****
>
> wrote:****
> wrote:****
> Don’t put it on the wire.  You want the server to filter before sending a
> reply.****
>
> ** **
>
> I'm concerned you're still confused about how a downgrade attack works.***
> *
>
> ** **
>
> returning malicious results.****
>
> ** **
>
> Such as:****
>
> -- client wants "all links" for [email-masked].****
>
> https://example.com/.well-known/webfinger?resource=acct:[email-masked]***
> *
>
> -- EVIL HIJACKER BLOCKS PORT 443****
>
> http://example.com/.well-known/webfinger?resource=acct:[email-masked]****
>
> -- EVIL HIJACKER MITMs that HTTP request and RETURNS WHATEVER THEY WANT:**
> **
>
>          {****
>
>            "rel" : "https://openid.net/connect/server",****
>
>            "type" : "text/html",****
>
>            "href" : "https://attacker.openid.server/"****
>
>          },****
>
> ** **
>
> See what happened there?****
>
> https:? I'm gonna skip over those (or just return an error)."****
>
> ** **
>
> whether it was filtering or not.****
>
> ** **
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 14:51:49 -0500

Brad,

I agree the idea of marking a “rel” as secure using https makes sense.  That said, is my profile page to be marked secure or not?  Do we define to rel values for a profile page, one that’s secure and one that’s not, then let the user specify the rel type based on preference?

What I think makes more sense if for the WF server admin to select what information to convey via HTTP or HTTPS.  I would have no objection to certain things (e.g., the URI used to identify the OpenID Provider) to be specified using https, thereby aiding in helping the server (and admin) in making that decision.

But, many rel values are just simple token strings.  How do we deal with those?

I still think this should be a server-side decision to filter.  Better, have the HTTP server redirect to HTTPS.  HTTPS servers NEVER redirect to HTTP.  And clients that need security NEVER use HTTP.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 1:40 PM
To: James M Snell
Cc: Paul E. Jones; [email-masked]; [email-masked]
Subject: Re: [webfinger] secure links with https rels

 

On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <[email-masked]> wrote:

[snip]

No... that's just nonsense. The real issue here is that the client has absolutely no way of detecting that the evil hijacker intercepted the request and provided false information in the first place. It should not matter at all if the returned document contains link rels with "https:" in them or not. 

You can never detect with HTTP that the connection was intercepted.  That doesn't matter, because the client does know one thing:  that it used HTTP (and not HTTPS).  So the client can filter out links which should not ever appear over plain HTTP.  I'm proposing that rels which begin with "https:" should never go over HTTP, and I've started calling those "secure rels".  Maybe that's a bad name, if enough people (including you now, in your earlier email) assume that I'm talking about the value (the href).

 

I'm -1 on the whole proposal. The notion of "insecure" and "secure" link relations makes absolutely no sense at all.

I'd like to ask that you think about and understand it before being so negative on it.

It may not be possible to detect if the HTTP connection was intercepted, but it is possible to determine if the information provided is trustworthy. That is what cryptographic signatures are for.

That is outside the scope of WebFinger, and may be used in subsequent hops.  We're trying to provide a secure basis for the first hop.  If we can't get any attribute securely for [email-masked], where are we getting the public key from to verify subsequent use of "cryptographic signatures".

---

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

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

> Brad,****
>
> ** **
>
> I agree the idea of marking a “rel” as secure using https makes sense.
> That said, is my profile page to be marked secure or not?  Do we define to
> rel values for a profile page, one that’s secure and one that’s not, then
> let the user specify the rel type based on preference?
>

rel values are selected per-application.  "secure-openid-connect-server" is
secure, and the OpenID Connect spec would say "look up the
'secure-openid-connect-server' rel".

If you're using a "blog" rel, that is not secure (it does not begin with
"secure-"), just v1 of this whole webfinger spec, where there was no
security.

> ****
>
> ** What I think makes more sense if for the WF server admin to select
> what information to convey via HTTP or HTTPS.
>

Downgrade attack.  See my and Zellyn's emails elsewhere.

> I would have no objection to certain things (e.g., the URI used to
> identify the OpenID Provider) to be specified using https, thereby aiding
> in helping the server (and admin) in making that decision.
>
> ** **
>

If they start with "secure-", they're HTTPS-only.  If they're like "blog"
or "avatar", HTTP is acceptable, like earlier drafts of the spec.

> ****
>
> ** I still think this should be a server-side decision to filter.
> Better, have the HTTP server redirect to HTTPS.  HTTPS servers NEVER
> redirect to HTTP.  And clients that need security NEVER use HTTP.
>

What if the client doesn't know what it wants yet?  Imagine: the client
wants to query all links for [email-masked] to see what it can do with
[email-masked].  Maybe it can show a pretty picture.  Maybe it can do
OpenID connect.

So what do you use?  HTTP or HTTPS?

The proposal is that you do both, either serially or in parallel,
preferring a valid HTTPS response, but filtering out secure rels if you end
up using the HTTP connection.

Then the client gets back some list of rels (and href values, not shown):

           "blog", "avatar", "secure-openid-connect-server", "
https://webfinger.net/rel/key-server"

Or, if HTTP was used:

           "blog", "avatar", "http://status.net/rel/foo"

---

From: Tim Bray <[email-masked]>
Date: Thu, 13 Dec 2012 12:00:40 -0800

Watching these threads, it seems like people aren’t hearing each other:

Team A: We really need a way to use WF in a way that’s guaranteed to be
HTTPS-only.
Team B: HTTPS is too hard for some people and unnecessary for some apps.

> let the user specify the rel type based on preference?

Why not?

> ****
>
>  What I think makes more sense if for the WF server admin to select what
> information to convey via HTTP or HTTPS.  I would have no objection to
> certain things (e.g., the URI used to identify the OpenID Provider) to be
> specified using https, thereby aiding in helping the server (and admin) in
> making that decision.
>

This doesn't meet the needs of Team A. They need a way to fetch a resource
that doesn't leave it up to the server.

> But, many rel values are just simple token strings.  How do we deal with

Well, the idea is that a group like OpenID Connect could specify a required
rel value that is marked as secure.  Existing rel values aren't. This seems
OK to me.

> ****
>
>  I still think this should be a server-side decision to filter.  Better,
> have the HTTP server redirect to HTTPS.  HTTPS servers NEVER redirect to
> HTTP.  And clients that need security NEVER use HTTP.
>

Team A really think they need to impose HTTPS-only from the request side.
You may not have such a need, or even agree that it exists, but there are
people who really think they need it, and that won't go away.

> ** **
>
> Paul****
>
> ** **
>
> *From:* Brad Fitzpatrick [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 1:40 PM
> *To:* James M Snell
> *Cc:* Paul E. Jones; [email-masked]; [email-masked]
>
> On Thu, Dec 13, 2012 at 10:30 AM, Brad Fitzpatrick <[email-masked]>
> wrote:****
>
> [snip]****
>
> ** **
>
> ** **
>
> them or not. ****
> earlier email) assume that I'm talking about the value (the href).****
>
> ** **
>
> I'm open to alternative name suggestions.****
>
> ** **
>
> ** **
>
> relations makes absolutely no sense at all.****
>
> ** **
>
> negative on it.****
> I promise it makes sense.****
>
>  ****
>
> That is what cryptographic signatures are for.****
>
> ** **
>
> That is outside the scope of WebFinger, and may be used in subsequent
> hops.  We're trying to provide a secure basis for the first hop.  If we
> can't get any attribute securely for [email-masked], where are we
> getting the public key from to verify subsequent use of "cryptographic
> signatures".****
>
> ** **
>

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Dec 2012 20:04:19 +0000

Paul. The server side filter is a distraction. It provides no security. 

The client needs to filter on the secure flag, whatever that is. 

John B. 

Sent from my iPhone

---

From: John Bradley <[email-masked]>
Date: Thu, 13 Dec 2012 20:04:54 +0000

+1

Sent from my iPhone

On 2012-12-13, at 7:55 PM, Zellyn Hunter <[email-masked]> wrote:

> Paul,
> 
> It has to happen on the client.
> 
> 1. Application code tries to look up "secure-openid-server" 
> 2. Client tries to connect to https://www.zellyn.com/
> 3. Evil adversary blocks the request.
> 4. Client falls back to HTTP.
> 5. Evil adversary returns a response that includes a value for rel="secure-openid-server"
> 6. Profit.
> 
> 
> 
> On Thu, Dec 13, 2012 at 11:51 AM, Paul E. Jones <[email-masked]> wrote:
>> Brad,
>> 
>>  
>>

---

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

> that doesn't leave it up to the server.

A. Client fetches request using HTTPS... if it fails, oh well, don't fall
back to HTTP.
B. If the response contains a JRD, look for the specific link rels the
client is interested in. If href is "https://..." great, if not, ignore.
There's no reason the link relations themselves need to be specifically
marked as "secure" or not.
C. If the response redirects to non https resource... ignore the redirect.
D. If the response redirects to https resource, go to step B

> Well, the idea is that a group like OpenID Connect could specify a
> required rel value that is marked as secure.  Existing rel values aren't.
> This seems OK to me.
>
>

This can be done without introducing some generalized notion of a "secure
link relation". Specifically, ANY registered link relation can be defined
such that being served over https is a requirement (refer to the rules for
registered link relations in rfc5988). If the client needs rel="foobar" to
be secure only, then it would send the request over https, only pay
attention to responses returned over https, and would only use those links
if href="https://..."... it's that simple.

> people who really think they need it, and that won't go away.

Already possible. The client is already in charge of whether it sends http
or https requests, regardless of what the server sends it.

- James

>> On Thu, Dec 13, 2012 at 10:36 AM, James M Snell <[email-masked]>
>> wrote:****
>>
>> ** **
>>
>> ** **
>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 12:17:46 -0800

James,

Your proposal seems to require clients to explicitly specify http or https
requests, and/or maintain a client database of which rels should be
https-only.  Both seem incredibly error-prone.  How do the rels stay in
sync?  Do you keep a whitelist of http-okay rels, or a blacklist of
https-only rels?  Is an unknown rel allowed over plain http?

My secure rel proposal makes that much simpler:  you can tell statically
from the rel's prefix whether it's secure:  does it start with "secure-" or
"https:"?

And then WebFinger client applications can still just say "give me all link
relations for [email-masked]", without specifying the transport.

On Thu, Dec 13, 2012 at 12:08 PM, James M Snell <[email-masked]> wrote:

>> This doesn't meet the needs of Team A. They need a way to fetch a
>> resource that doesn't leave it up to the server.
>>
>>
>
>> Team A really think they need to impose HTTPS-only from the request
>> side.  You may not have such a need, or even agree that it exists, but
>> there are people who really think they need it, and that won't go away.
>>
>
>>> You can never detect with HTTP that the connection was intercepted.
>>>  That doesn't matter, because the client does know one thing:  that it used
>>> HTTP (and not HTTPS).  So the client can filter out links which should not
>>> ever appear over plain HTTP.  I'm proposing that rels which begin with
>>> "https:" should never go over HTTP, and I've started calling those "secure
>>> rels".  Maybe that's a bad name, if enough people (including you now, in
>>> your earlier email) assume that I'm talking about the value (the href).*
>>> ***
>>>
>>> ** **
>>>

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 12:47:13 -0800

On Dec 13, 2012 12:17 PM, "Brad Fitzpatrick" <[email-masked]> wrote:
>
> James,
>
> Your proposal seems to require clients to explicitly specify http or
https requests, and/or maintain a client database of which rels should be
https-only.  Both seem incredibly error-prone.  How do the rels stay in
sync?  Do you keep a whitelist of http-okay rels, or a blacklist of
https-only rels?  Is an unknown rel allowed over plain http?

Link relations have no notion of http-ok or not-ok. They are just labels. A
client requesting webfinger data will know exactly which link relations it
is looking for and will determine on its own if it needs to request the
webfinger document securely or not. There is no requirement to maintain any
client side database or blacklist. That makes absolutely zero sense to me.

Specifically, for example, if I want to know the oauth provider for a given
user, and I want to know that "securely", I would send the request over
HTTPS and look for the specific rel="oauth-authenticator" once I'm sure I
can trust the document the server returned. If the initial HTTPS connection
cannot be established, I give up. If I cannot be sure the returned jrd is
trustworthy, I give up.

No you can't. Any registered link relation can be defined such that HTTPS
is required, with or without any kind of prefix.

- james

> And then WebFinger client applications can still just say "give me all
link relations for [email-masked]", without specifying the transport.
>>>
>>
>>
>> A. Client fetches request using HTTPS... if it fails, oh well, don't
fall back to HTTP.
>>>
>>
>>
>> This can be done without introducing some generalized notion of a
"secure link relation". Specifically, ANY registered link relation can be
defined such that being served over https is a requirement (refer to the
rules for registered link relations in rfc5988). If the client needs
rel="foobar" to be secure only, then it would send the request over https,
only pay attention to responses returned over https, and would only use
those links if href="https://..."... it's that simple.
>>
>>>>
>>>>  I still think this should be a server-side decision to filter.
>>
>>
>> Already possible. The client is already in charge of whether it sends
http or https requests, regardless of what the server sends it.
wrote:
>>>>>> No... that's just nonsense. The real issue here is that the client
has absolutely no way of detecting that the evil hijacker intercepted the
request and provided false information in the first place. It should not
matter at all if the returned document contains link rels with "https:" in
them or not.
your earlier email) assume that I'm talking about the value (the href).
>>>>> I'm -1 on the whole proposal. The notion of "insecure" and "secure"
link relations makes absolutely no sense at all.
negative on it.
>>>>> It may not be possible to detect if the HTTP connection was
intercepted, but it is possible to determine if the information provided is
trustworthy. That is what cryptographic signatures are for.
hops.  We're trying to provide a secure basis for the first hop.  If we
can't get any attribute securely for [email-masked], where are we getting
the public key from to verify subsequent use of "cryptographic signatures".

---

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

On Thu, Dec 13, 2012 at 12:47 PM, James M Snell <[email-masked]> wrote:

> Link relations have no notion of http-ok or not-ok.
>
I'm proposing that they should.  Without relations having an implicit
http-okayness, we can't do fallback (notably on * requests).  And without
fallback, we can't reliably do a lookup, if servers have a choice of HTTP
or HTTPS.

> They are just labels. A client requesting webfinger data will know exactly
> which link relations it is looking for and will determine on its own if it
> needs to request the webfinger document securely or not. There is no
> requirement to maintain any client side database or blacklist. [ ... ] Any
> registered link relation can be defined such that HTTPS is required, with
> or without any kind of prefix.
>

Those two statements seem to contradict each other.  You said that we don't
need a client-side database, but then you said IANA labels can be defined
to be HTTPS-only.  That's a database.  Maybe not a big one, but it's a set
of data that clients would need to know.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 17:18:30 -0500

No, the client should not fall back to HTTP.  That's not written in the
current proposal.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zellyn Hunter
Sent: Thursday, December 13, 2012 2:56 PM
To: [email-masked]
Cc: Brad Fitzpatrick; James M Snell; [email-masked]
Subject: Re: [webfinger] secure links with https rels

Paul,

5. Evil adversary returns a response that includes a value for
rel="secure-openid-server"

6. Profit.

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

Brad,

I agree the idea of marking a "rel" as secure using https makes sense.  That
said, is my profile page to be marked secure or not?  Do we define to rel
values for a profile page, one that's secure and one that's not, then let
the user specify the rel type based on preference?

But, many rel values are just simple token strings.  How do we deal with
those?

I still think this should be a server-side decision to filter.  Better, have
the HTTP server redirect to HTTPS.  HTTPS servers NEVER redirect to HTTP.
And clients that need security NEVER use HTTP.

Paul

 

[snip]

 

It may not be possible to detect if the HTTP connection was intercepted, but
it is possible to determine if the information provided is trustworthy. That
is what cryptographic signatures are for.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:27:37 -0800

On Thu, Dec 13, 2012 at 2:18 PM, Paul E. Jones <[email-masked]>wrote:

> No, the client should not fall back to HTTP.  That’s not written in the
> current proposal.
>

If the server is allowed to serve on either HTTPS or HTTP, I think the
client needs to do fallback.

HTTPS-only makes this all easier.

If we want to allow HTTP, we need more complexity in the client.

---

From: Nick Jennings <[email-masked]>
Date: Thu, 13 Dec 2012 23:32:38 +0100

> If we want to allow HTTP, we need more complexity in the client.

Why not HTTPS and HTTP for the server? (not either-or)

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 17:34:25 -0500

What I am suggesting is that *if*we want to do any kind of URL filtering
that we do it based on server configuration, not "rel" type.  I don't like
the "secure-cat-picture" idea.

If you are an HTTP-only client and the only cat picture I have I want served
only via HTTPS, then I tell my WF server "serve this only via HTTPS".  So, a
query to the HTTP server will never see that.

However, I don't even like that.  If the HTTP server has this rule that it
follows, it means it can do HTTPS.  So, rather than filtering, just redirect
the client to the HTTPS server.

The concern, of course, is that some client writer might write a client that
SHOULD have requested WF content securely in the first place and is looking
for secure content.  That insecure request ends up getting redirected to the
wrong place.   So clients that need security should never use HTTP.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zellyn Hunter
Sent: Thursday, December 13, 2012 2:37 PM
To: [email-masked]
Cc: Brad Fitzpatrick; [email-masked]
Subject: Re: [webfinger] secure links with https rels

Only if by "query to an HTTPs URL" and "query to an HTTP URL", you mean a
"webfinger client query" rather than a plain old "http(s) query". The onus
is on the *client* to reject "secure" items retrieved over HTTP. The server
can return the same content in both cases.

In other words, if you ask the webfinger client for my "secure-cat-picture",
you will never get an answer unless the answer was retrieved over HTTPS,
regardless of whether it's in the HTTP response or not.

Zellyn

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

No, I understand the downgrade attack, but that is totally unrelated to what
we were talking about.

What we were discussing is that a query to an HTTPS URL might return a
different set of link relations than a query to an HTTP URL.  More
specifically, a query to an HTTPS URL might return things the server
believes should only be returned over HTTPS, such as links to an OpenID
Provider.

Nowhere in the currently proposed "compromise" text is there a proposal to
fall back as you're showing it.  A client either requests WF via HTTPS or
HTTP, not both.  In the case of the latter, it's not looking for secure
content or security is a non-issue.

Paul

To: Paul E. Jones

Such as:

         {

           "type" : "text/html",

         },

See what happened there?

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:35:01 -0800

> Why not HTTPS and HTTP for the server? (not either-or)

There are a number of people on this list who want to run WebFinger servers
over HTTP without the pain and expense of setting up HTTPS.  HTTP fallback
was a compromise for them.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 14:43:22 -0800

On Thu, Dec 13, 2012 at 2:34 PM, Paul E. Jones <[email-masked]>wrote:

> that we do it based on server configuration, not “rel” type.  I don’t like
> the “secure-cat-picture” idea.****
>
> ** **
>
> If you are an HTTP-only client and the only cat picture I have I want
> served only via HTTPS, then I tell my WF server “serve this only via
> HTTPS”.  So, a query to the HTTP server will never see that.
>

MITM.  The client gets rerouted by the attacker that serves "cat-picture"
=> href: "evil-cat.jpg".  The real server was never contacted, so all your
server filtering is useless.

Security needs to be in the client too.

> ****
>
> ** However, I don’t even like that.  If the HTTP server has this rule
> that it follows, it means it can do HTTPS.  So, rather than filtering, just
> redirect the client to the HTTPS server.
>
> ** **
>
> The concern, of course, is that some client writer might write a client
> that SHOULD have requested WF content securely in the first place and is
> looking for secure content.  That insecure request ends up getting
> redirected to the wrong place.   So clients that need security should never
> use HTTP.
>

I don't want to make applications choose between security and not.
 That significantly increases the amount of code to audit, most of it not
visible.  The security camp won't like it.

You need to make the client library always results that are trustworthy.
 Again, I'm not mandating the client interface (any API is acceptable),
only the behavior.  In fact, I want zero configuration on the client side.

If an application queries "all links for [email-masked]" and gets back a
set of 10 links, one of which is:

     rel "https://openid.net/rel/connect/server", href: "
https://myopenid.example.com/"

... I want that to be trustworthy, without the webfinger client being
configured "correctly".

---

From: Goix Laurent Walter <[email-masked]>
Date: Fri, 14 Dec 2012 00:04:44 +0100

I think we're all loosing focus with this thread....
Why not simply state that:
- servers must support http and should support https
- clients should try https first (but may have options not to do it for specific purposes)
- servers must not include 'secure' *href* over plain http + clients must ignore those hrefs if present anyway (to avoid the attack suggested earlier)

This I believe accommodates all:
- we don't mention fallback explicitly. Clients may fallback since servers may not support https but know that in that case won't get any secure href (implied: won't probably get those rels that are sensitive like oauth or openid connect endpoints etc).
- we don't mention the concept of secure link rels but secure href
- plain http solution still works and it is clear that it does not return secure endpoints (I don't think anyone wants this)
- https is still recommended at first hit to get a maximum number of rels
- https queries are not limited to return secure links only but any...
- secure link filtering over plain http is ensured both at server and client side

Walter

Le 13 déc. 2012 à 23:40, "Kingsley Idehen" <[email-masked]<mailto:[email-masked]>> a écrit :

On 12/13/12 5:35 PM, Brad Fitzpatrick wrote:

There are a number of people on this list who want to run WebFinger servers over HTTP without the pain and expense of setting up HTTPS.  HTTP fallback was a compromise for them.
+1

Very important. The Web is inherently loosely coupled, we have to keep it that way.

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca<http://Identi.ca> handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

---

From: Nick Jennings <[email-masked]>
Date: Fri, 14 Dec 2012 00:08:36 +0100

+1 that's what I just suggested in a different thread. I think it makes the
most sense, keeps things flexible AND secure, and makes servers /want/ to
setup HTTPS in order to participate in providing secure data

On Fri, Dec 14, 2012 at 12:04 AM, Goix Laurent Walter <
[email-masked]> wrote:

> - servers must not include 'secure' *href* over plain http + clients must
> ignore those hrefs if present anyway (to avoid the attack suggested earlier)
>
> - we don't mention fallback explicitly. Clients may fallback since servers
> may not support https but know that in that case won't get any secure href
> (implied: won't probably get those rels that are sensitive like oauth or
> openid connect endpoints etc).
> - plain http solution still works and it is clear that it does not return
> secure endpoints (I don't think anyone wants this)
> Le 13 déc. 2012 à 23:40, "Kingsley Idehen" <[email-masked]> a
> écrit :
>
> There are a number of people on this list who want to run WebFinger
> servers over HTTP without the pain and expense of setting up HTTPS.  HTTP
> fallback was a compromise for them.
>
> +1
>
> Twitter/Identi.ca handle: @kidehen

---

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

Walter,

No, this will not work.  People want to have secure content and what is secure might be determined by the server admin or user.  One might consider his avatar should be served over HTTPS only.

And people do not want to have to write clients that do fallback.

We either have to do HTTPS only or we have to live with the fact that some client requests are going to fail if a WF provider does not provide WF services over HTTPS.

So,

1)      Servers SHOULD implement HTTPS and clients SHOULD use HTTPS

2)      Servers and clients MAY implement HTTP

3)      Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as secure since it allows for a MITM attack)

4)      Servers MUST NOT redirect from HTTPS to HTTP

All works well, except for the case where you have an HTTPS-only client.  But, I bet that will be the majority of clients, which will then drive the majority of the servers to support HTTPS.

Still, it leaves the option on the table for some clients and servers to use HTTP if they wish.

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 6:05 PM
To: [email-masked]
Cc: [email-masked]; Brad Fitzpatrick; Paul E. Jones; James M Snell; [email-masked]
Subject: Re: [webfinger] secure links with https rels

Walter

Le 13 déc. 2012 à 23:40, "Kingsley Idehen" <[email-masked]> a écrit :

+1

-- 
 
Regards,
 
Kingsley Idehen       
Founder & CEO 
OpenLink Software     

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 15:15:26 -0800

On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <[email-masked]>wrote:

> Walter,****
>
> ** **
>
> No, this will not work.  People want to have secure content and what is
> secure might be determined by the server admin or user.  One might consider
> his avatar should be served over HTTPS only.****
>
> ** **
>

I never saw any strong opposition against fallback.  People disliked the
extra complexity, but for quite awhile everybody assumed that fallback
would be involved, and I think it was considered acceptable.

Who was strongly anti-fallback?

****
>
> We either have to do HTTPS only *or* we have to live with the fact that
> some client requests are going to fail if a WF provider does not provide WF
> services over HTTPS.
>

I strongly disagree that those are the only two options.

But if you really believe that, I hope you realize that flakiness is
unacceptable, which leaves you with HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with
HTTPS-only.

> ** So,
>
> **1)      **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS***
> *
>
> **2)      **Servers and clients MAY implement HTTP****
>
> **3)      **Servers MAY redirect from HTTP to HTTPS (this MUST NOT be
> treated as secure since it allows for a MITM attack)****
>
> **4)      **Servers MUST NOT redirect from HTTPS to HTTP****
>
> ** **
>
> All works well, except for the case where you have an HTTPS-only client.
> But, I bet that will be the majority of clients, which will then drive the
> majority of the servers to support HTTPS.
>

This is a terrible cop-out.  Flakiness in the spec is unacceptable.

> ****
>
> ** Still, it leaves the option on the table for some clients and servers
> to use HTTP if they wish.
>

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 15:16:37 -0800

+1... This also leaves the door open to the kind of integrity checking
mechanism I suggested earlier to deal with the vulnerabilities in your #3.
It's ok if some requests fail. HTTPS-to-HTTP fallback should NEVER be done.

- James

On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <[email-masked]>wrote:

> And people do not want to have to write clients that do fallback.****
>
> ** **
>
> services over HTTPS.****
> So,****
> majority of the servers to support HTTPS.****
>
> ** **
>
> Still, it leaves the option on the table for some clients and servers to
> use HTTP if they wish.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* Goix Laurent Walter [mailto:[email-masked]]
> *Sent:* Thursday, December 13, 2012 6:05 PM
> *Cc:* [email-masked]; Brad Fitzpatrick; Paul E. Jones; James
> M Snell; [email-masked]
>
> I think we're all loosing focus with this thread....****
>
> Why not simply state that:****
>
> - servers must support http and should support https****
>
> - clients should try https first (but may have options not to do it for
> specific purposes)****
>
> This I believe accommodates all:****
>
> openid connect endpoints etc).****
>
> - we don't mention the concept of secure link rels but secure href****
>
> secure endpoints (I don't think anyone wants this)****
>
> - https is still recommended at first hit to get a maximum number of rels*
> ***
>
> - https queries are not limited to return secure links only but any...****
>
> - secure link filtering over plain http is ensured both at server and
> client side****
>
> ** **
>
> Walter
>
> écrit :****
> On 12/13/12 5:35 PM, Brad Fitzpatrick wrote:****
>
> On Thu, Dec 13, 2012 at 2:32 PM, Nick Jennings <[email-masked]>
> wrote:****
>
> >
> Why not HTTPS and HTTP for the server? (not either-or)****
>
> ** **
>
> fallback was a compromise for them.****
>
> +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****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie. ****
>
> advise the sender by return e-mail, Thanks.* ****
>
> mail se non è necessario.* ****
>
> ** **
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 13 Dec 2012 15:17:46 -0800

On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick <[email-masked]>wrote:

> Who was strongly anti-fallback?''''
>

Um, maybe me.  What is unacceptable for some applications is if I tell the
client “Fetch https://example.com/.well-known/whatever” and for some reason
it silently falls back to HTTP.   -T

>> **1)      **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS**
>> **
>>

---

From: James M Snell <[email-masked]>
Date: Thu, 13 Dec 2012 15:19:10 -0800

On Thu, Dec 13, 2012 at 3:17 PM, Tim Bray <[email-masked]> wrote:

> client “Fetch https://example.com/.well-known/whatever” and for some
> reason it silently falls back to HTTP.   -T
>

Raising my hand as well. If it hasn't been clear up to this point, I'm
hugely -1 on https-to-http fallback.

- James

>>> **1)      **Servers SHOULD implement HTTPS and clients SHOULD use HTTPS*
>>> ***
>>>
>>> All works well, except for the case where you have an HTTPS-only
>>> client.  But, I bet that will be the majority of clients, which will then
>>> drive the majority of the servers to support HTTPS.
>>>
>>
>>> ** Still, it leaves the option on the table for some clients and
>>> servers to use HTTP if they wish.
>>>
>>
>>
>>

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 15:20:18 -0800

> reason it silently falls back to HTTP.   -T

What if you knew ahead of time that your client wouldn't give you results
for important rels fetched over HTTP, and would only return them if they
came over HTTPS?  Would fallback be acceptable for "unimportant" rels?

(still trying to feel out everybody's varying concerns)

---

From: Brad Fitzpatrick <[email-masked]>
Date: Thu, 13 Dec 2012 15:21:46 -0800

On Thu, Dec 13, 2012 at 3:19 PM, James M Snell <[email-masked]> wrote:

>> Um, maybe me.  What is unacceptable for some applications is if I tell
>> the client “Fetch https://example.com/.well-known/whatever” and for some

Please explain why.  Saying "-1" and calling things insane without
justification doesn't lend as much credibility as presenting constructive
feedback.

---

From: Tim Bray <[email-masked]>
Date: Thu, 13 Dec 2012 15:35:05 -0800

> came over HTTPS?  Would fallback be acceptable for "unimportant" rels?

Yeah, that would be fine. It’s exactly why I proposed writing a “fallback”
parameter into the spec, allowing clients to assert HTTPS-or-nothing.   -T

---

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

Brad,

I really don’t like the secure-rels idea.  If a rel is secure or should be treated as secure, I can mark it as such on the server without creating more names and cluttering up the link relation name space with multiple variants of the same thing.

There were several people opposed to the client fall back text due to both security concerns and client-side complexity.  That was one of the main items we addressed with this latest proposal re-write.

I do realize the flakiness of the proposed solution.  Sometimes, the client just does not work.  You type in [email-masked] and it says “could not find a thing”, because the client only issued the query over HTTPS.  If one needs security, I see on other way.  However, if we’re willing to go back to the -07 text that has an allowance for fall back, the issue is addressed.  In the -07 text, a client MAY re-issue a request using HTTP.

Paul

From: Brad Fitzpatrick [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 6:15 PM
To: Paul E. Jones
Cc: Goix Laurent Walter; [email-masked]; James M Snell; [email-masked]
Subject: Re: [webfinger] secure links with https rels

On Thu, Dec 13, 2012 at 3:11 PM, Paul E. Jones <[email-masked]> wrote:

Walter,

I never saw any strong opposition against fallback.  People disliked the extra complexity, but for quite awhile everybody assumed that fallback would be involved, and I think it was considered acceptable.

 

But if you really believe that, I hope you realize that flakiness is unacceptable, which leaves you with HTTPS-only.

If the HTTPS-for-some-rels proposal still isn't clear, I'd be happy with HTTPS-only.

 So,

---

From: Breno <[email-masked]>
Date: Thu, 13 Dec 2012 20:00:21 -0800

On Thu, Dec 13, 2012 at 3:39 PM, Paul E. Jones <[email-masked]> wrote:
> Brad,
>
>
>
> I really don’t like the secure-rels idea.  If a rel is secure or should be
> treated as secure, I can mark it as such on the server without creating more
> names and cluttering up the link relation name space with multiple variants
> of the same thing.

As explained above, this does not address HTTP-fallback degrade attacks.

>
>
>
> There were several people opposed to the client fall back text due to both
> security concerns and client-side complexity.  That was one of the main
> items we addressed with this latest proposal re-write.

The proposal re-write does not seem to address any complexity. It
simply removes guidance that would ensure implementations that can be
'plugged in' both in insecure and secure contexts. The likely result
are simpler implementations that can't be used in secure contexts,
even if they may make a claim to the contrary.

>
>
>
> I do realize the flakiness of the proposed solution.

Yes. It's too flaky for the purposes of secure discovery.

> Sometimes, the client
> just does not work.  You type in [email-masked] and it says “could
> not find a thing”, because the client only issued the query over HTTPS.  If
> one needs security, I see on other way.  However, if we’re willing to go
> back to the -07 text that has an allowance for fall back, the issue is
> addressed.  In the -07 text, a client MAY re-issue a request using HTTP.
>
>
>
> Paul
>
>
>
> his avatar should be served over HTTPS only.
>
>
>
> extra complexity, but for quite awhile everybody assumed that fallback would
> be involved, and I think it was considered acceptable.
>
>
>
> We either have to do HTTPS only or we have to live with the fact that some
> client requests are going to fail if a WF provider does not provide WF
> services over HTTPS.
>
>
>
> 3)      Servers MAY redirect from HTTP to HTTPS (this MUST NOT be treated as
> secure since it allows for a MITM attack)
>
> use HTTP if they wish.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 13 Dec 2012 20:08:57 -0800

Also, I reject the notion that WF standard should be simple for
clients. If we want WF to be widely deployed, we make it easier for
servers so that the information is ubiquitously deployed even by users
and companies that are unsophisticated.

In contrast, standard-compliant WF clients are probably going to be
less common. Even if WF is not too complex, why wouldn't you use a
library if you want to have some guarantee like security? If you want
to simply write a few curl commands and mesh the data after applying
your homebrew parser, you neither care for standard compliance or
security, and you still can get things done because the underlying
data schema is simple.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 13 Dec 2012 20:19:33 -0800

I will go further:

Security is best served by simplicity: If HTTPS was only allowable
protocol, that'd be the best approach security-wise.

If simplicity is not available (and the decision to allow HTTPS and
HTTP means it isn't), then a fully specified behavior, in all it's
glorious complexity, is required for security. If that discourages the
proliferation of low-quality
I-whipped-this-in-1h-while-waiting-to-board compliant-claiming client
implementations, so much better for security. Put all eggs in one
basket and watch that basket.

The current compromise where we pretend that we can have simple client
specification that allows for both complex behavior and secure
operation is a smokescreen. Just add a disclaimer that WF is not
intended to use in secure contexts, at least it'd be honest.

-- 
Breno de Medeiros

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 23:36:27 -0500

> Also, I reject the notion that WF standard should be simple for clients.
> If we want WF to be widely deployed, we make it easier for servers so
> that the information is ubiquitously deployed even by users and
> companies that are unsophisticated.
> 
> In contrast, standard-compliant WF clients are probably going to be less
> common. Even if WF is not too complex, why wouldn't you use a library if
> you want to have some guarantee like security? If you want to simply
> write a few curl commands and mesh the data after applying your homebrew
> parser, you neither care for standard compliance or security, and you
> still can get things done because the underlying data schema is simple.

Your opinion conflicts with nearly every other statement on where complexity
should be.

I tend to agree with others on this one: we should strive for simplicity in
the client, though my own server is pretty darn simple.  There just isn't
much complexity to WF.  The *only* thing I think is complex is having to
query using HTTPS and then HTTP if the server does not reply.  It's not just
complexity, but also a matter of delay.  We should strive to reduce the time
it takes to return a WF reply.

Paul

---

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

I agree with Breno, in all his points and previous emails.

Again, I will repeat myself:  we can have at most two of these three:

1) security
2) support HTTP servers
3) simple clients

We don't get all 3.  We get at most 2.

I think everybody wants 1), so that leave us deciding between 2) and 3) as
our other feature.

Which is it?  HTTP servers or simple clients?

On Thu, Dec 13, 2012 at 8:19 PM, Breno <[email-masked]> wrote:

> would
> client.

---

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

Breno,

> specification that allows for both complex behavior and secure operation
> is a smokescreen. Just add a disclaimer that WF is not intended to use
> in secure contexts, at least it'd be honest.

I don't agree with that comment, either. :-)  (Let me apologize for sounding
so disagreeable.)

If a client needs to ensure that responses are delivered via HTTPS, it uses
that exclusively. Period.  There is nothing more we can do to ensure a more
secure transport from the WF protocol.

For all other clients that don't care too much whether a reply is delivered
over HTTP or HTTPS, there is no "smokescreen".  It's just a process of how
the client gets a response.  The client could send an HTTP query, since it
does not care about security.  The server might redirect the client to an
HTTPS server, which is fine.  It makes little difference whether the reply
comes back via HTTP or HTTPS, as both have to be treated as non-secure.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 13 Dec 2012 23:48:49 -0500

You’re right that we cannot have all three.  But, those who are still demanding HTTP as an option (and I’m still looking to hear from those folks) are not demanding security.

So, what we’re looking at presently are really two options for clients:

1)      Secure – HTTPS server

2)      Non-Secure – HTTP server

The client selects the transport based on its requirements.

In the case that the client needs a secure reply, it uses HTTPS and will not try HTTP.  If the server is not listening on HTTPS, then it fails.  And, that’s exactly what you want to avoid a security issue.

In the case that the client does not care about security of the response, it queries using HTTP.  The server might reply or it might redirect, but the reply is still considered non-secure (since the HTTP reply could be hacked).

In both cases, the client code is simple.  There’s no fall back logic in the client.  Either make a secure request or don’t.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 PM
To: Breno; [email-masked]
Cc: James M Snell; [email-masked]; Goix Laurent Walter
Subject: Re: [webfinger] secure links with https rels

1) security

2) support HTTP servers

3) simple clients

I think everybody wants 1), so that leave us deciding between 2) and 3) as our other feature.

 

I will go further:

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 13 Dec 2012 20:56:26 -0800

That requires everyone who uses WF to either write their own implementation
or if using some other implementation to get informed about how it behaves
regarding the network layer.

It requires protocols that want to build on WF for secure operations to
define a compatibility profile for WF clients that exceed the
specification. Or a separate spec possibly with heavy reference to WF

I'd prefer an HTTPS spec but HTTP proponents have made some reasoned
arguments. Is it too much to expect the client-simplicity components to do
the same? I am unconvinced that clients need both to be simple and spec
compliant. With Brad's secure rel proposal you can have either though not
in the same implementation. The only difference between the two is that
only compliant implementations are secure. What are we giving up exactly?

---

From: Breno <[email-masked]>
Date: Thu, 13 Dec 2012 20:59:51 -0800

Our messages crossed.

There's still some complexity. How does that interact  with caching?
On Dec 13, 2012 8:48 PM, "Paul E. Jones" <[email-masked]> wrote:

> You’re right that we cannot have all three.  But, those who are still
> demanding HTTP as an option (and I’m still looking to hear from those
> folks) are not demanding security.****
>
> ** **
>
> So, what we’re looking at presently are really two options for clients:***
> *
>
> **1)      **Secure – HTTPS server****
>
> **2)      **Non-Secure – HTTP server****
>
> ** **
>
> The client selects the transport based on its requirements.****
>
> ** **
>
> In the case that the client needs a secure reply, it uses HTTPS and will
> not try HTTP.  If the server is not listening on HTTPS, then it fails.
> And, that’s exactly what you want to avoid a security issue.****
>
> ** **
>
> In the case that the client does not care about security of the response,
> it queries using HTTP.  The server might reply or it might redirect, but
> the reply is still considered non-secure (since the HTTP reply could be
> hacked).****
>
> ** **
>
> In both cases, the client code is simple.  There’s no fall back logic in
> the client.  Either make a secure request or don’t.****
>
> ** **
>
> Paul****
>
> ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Brad Fitzpatrick
> *Sent:* Thursday, December 13, 2012 11:37 PM
> *To:* Breno; [email-masked]
> *Cc:* James M Snell; [email-masked]; Goix Laurent Walter
> I agree with Breno, in all his points and previous emails.****
>
> ** **
>
> Again, I will repeat myself:  we can have at most two of these three:****
>
> ** **
>
> 1) security****
>
> 2) support HTTP servers****
>
> 3) simple clients****
>
> ** **
>
> We don't get all 3.  We get at most 2.****
>
> ** **
>
> our other feature.****
> Which is it?  HTTP servers or simple clients?****
>
> ** **
>
> ** **
>
> intended to use in secure contexts, at least it'd be honest.****
>
>
> Breno de Medeiros****

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Dec 2012 01:36:13 -0500

Breno,

Comments are inline:

PEJ: No, not really. The WF library would offer that as a switch.  This has
been suggested and I have some draft text to integrate.  It would likely be
similar to what was suggested today on the list:
wf.query("acct:[email-masked]", "secure:true")

It requires protocols that want to build on WF for secure operations to
define a compatibility profile for WF clients that exceed the specification.
Or a separate spec possibly with heavy reference to WF

PEJ: This is true, but not as complex as you describe. The OpenID Connect
protocol, as one example, would have to specify that only HTTPS shall be
used when performing discovery.

I'd prefer an HTTPS spec but HTTP proponents have made some reasoned
arguments. Is it too much to expect the client-simplicity components to do
the same? I am unconvinced that clients need both to be simple and spec
compliant. With Brad's secure rel proposal you can have either though not in
the same implementation. The only difference between the two is that only
compliant implementations are secure. What are we giving up exactly?

PEJ: The secure rels proposal just creates a bunch more rels that help the
server in deciding whether to provide the content via TLS or not.  I can
have my server make the same decision by setting a field in the database or
having a list of link relations that I classify as "secure".  I actually
like a combination of both, since this allows me to classify the OpenID
Provider URL as "secure" for all users, but then if there are particular
users for which I need to guarantee that their avatar is secure, I do so by
setting the appropriate field for that user and avatar.  And, I can do that
without defining more protocol pieces.  There is one nice aspect to his
proposal, and that is that the server does not have to be provisioned to
know what is and is not to be conveyed via HTTP.  So, I would not be opposed
to the notion of saying "https:" rel types MUST be delivered only over TLS.
But, this does not address all other issues.  It's a bit orthogonal to the
problem of deciding whether a client issues a query via HTTP or HTTPS, or
whether a server shall respond to either HTTP or HTTPS.

Breno,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Dec 2012 01:38:49 -0500

TLS data isn't cached (except perhaps on the server side where there might
be a caching load balancer with the TLS certificates loaded).

HTTP data can and may be cached.  There is a small statement about that in
the spec, but at least one person suggested I should remove it since WF is
not changing the rules of how HTTP works and therefore they felt we don't
need to say anything about it.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Breno
Sent: Friday, December 14, 2012 12:00 AM
To: Paul E. Jones
Cc: [email-masked]; Goix Laurent Walter; Brad Fitzpatrick;
[email-masked]; James M Snell
Subject: RE: [webfinger] secure links with https rels

Our messages crossed. 

You're right that we cannot have all three.  But, those who are still
demanding HTTP as an option (and I'm still looking to hear from those folks)
are not demanding security.

So, what we're looking at presently are really two options for clients:

1)      Secure - HTTPS server

2)      Non-Secure - HTTP server

In the case that the client needs a secure reply, it uses HTTPS and will not
try HTTP.  If the server is not listening on HTTPS, then it fails.  And,
that's exactly what you want to avoid a security issue.

In the case that the client does not care about security of the response, it
queries using HTTP.  The server might reply or it might redirect, but the
reply is still considered non-secure (since the HTTP reply could be hacked).

In both cases, the client code is simple.  There's no fall back logic in the
client.  Either make a secure request or don't.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brad Fitzpatrick
Sent: Thursday, December 13, 2012 11:37 PM
To: Breno; [email-masked]
Cc: James M Snell; [email-masked]; Goix Laurent Walter
Subject: Re: [webfinger] secure links with https rels

1) security

2) support HTTP servers

3) simple clients

 

I will go further:

On Thu, Dec 13, 2012 at 8:08 PM, Breno <[email-masked]> wrote:
>>> I really don't like the secure-rels idea.  If a rel is secure or should
be
>>> just does not work.  You type in [email-masked] and it says
"could
>>> not find a thing", because the client only issued the query over HTTPS.
If
>>> one needs security, I see on other way.  However, if we're willing to go
would

--
Breno de Medeiros

---

From: John Panzer <[email-masked]>
Date: Thu, 13 Dec 2012 22:49:23 -0800

Why would TLS data marked with cache-control: public not be cacheable on
the client?  Or by trusted caching proxies?
On Dec 13, 2012 10:38 PM, "Paul E. Jones" <[email-masked]> wrote:

> TLS data isn’t cached (except perhaps on the server side where there might
> be a caching load balancer with the TLS certificates loaded).****
>
> ** **
>
> not changing the rules of how HTTP works and therefore they felt we don’t
> need to say anything about it.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Breno
> *Sent:* Friday, December 14, 2012 12:00 AM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; Goix Laurent Walter; Brad Fitzpatrick;
> *Subject:* RE: [webfinger] secure links with https rels****
>
> ** **
>
> Our messages crossed. ****
>
> There's still some complexity. How does that interact  with caching?****
>
> On Dec 13, 2012 8:48 PM, "Paul E. Jones" <[email-masked]> wrote:***
> *
>
> 1)      Secure – HTTPS server****
>
> 2)      Non-Secure – HTTP server****
>
>  ****
>
> “could

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 14 Dec 2012 02:07:30 -0500

Sure, the client can certainly cache it, but I figured that went without
saying.  What trusted proxies exist, except those service the data for the
server (e.g., load balancers)?  I sure as heck would not trust any entity
between me and my bank, for example.

In any case, WF does not change caching rules or anything else about HTTP.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Panzer
Sent: Friday, December 14, 2012 1:49 AM
To: [email-masked]
Cc: [email-masked]; James M Snell; Goix Laurent Walter; Brad Fitzpatrick
Subject: Re: [webfinger] secure links with https rels

Why would TLS data marked with cache-control: public not be cacheable on the
client?  Or by trusted caching proxies?

Paul

Our messages crossed. 

1)      Secure - HTTPS server

Paul

1) security

2) support HTTP servers

3) simple clients

 

I will go further:

be
"could
If
would

--
Breno de Medeiros

---

From: Zellyn Hunter <[email-masked]>
Date: Thu, 13 Dec 2012 08:17:20 -0800

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

> visiting my homepage today.  I don’t secure that, either.)****
>
> ** **
>
> Paul****
>
> ** **
>
> *Sent:* Thursday, December 13, 2012 10:30 AM
> *Cc:* [email-masked]
> On Wed, Dec 12, 2012 at 11:23 PM, Paul E. Jones <[email-masked]>
> wrote:****
>
> xcard, portable contact, avatar, “preferred name”, etc.).  Then what?****
>
> ** **
>
> returned.****
> If plain HTTP was used, all links beginning with "https:" would be
> filtered out by the client.  (just like in the single rel lookup case)****
>
> ** **
>
> I thought that followed obviously from the proposal, sorry.****
>

---

From: Zellyn Hunter <[email-masked]>
Date: Thu, 13 Dec 2012 09:00:47 -0800

Right you are. Color me temporarily confused too! :-)

---

From: Will Norris <[email-masked]>
Date: Thu, 13 Dec 2012 11:16:02 -0800

> rfc5988 allows. Whether or not it's a good idea is separate issue. I don't

You wouldn't specify that the "secure-canonical" link must *point* to
an https URL.  You're right that that provides no additional security.
 Rather you would specify that it must be *retrieved* from an https
URL.  For protocols where security is required, they would only ever
specify https rel values, meaning that clients should only ever trust
them when they are retrieved from a document that was transmited over
https.

>>>> On Thu, Dec 13, 2012 at 10:50 AM, Goix Laurent Walter
>>>> <[email-masked]> wrote:
>>>>>

---

From: Zellyn Hunter <[email-masked]>
Date: Thu, 13 Dec 2012 11:36:38 -0800

In other words, if you ask the webfinger client for my
"secure-cat-picture", you will never get an answer unless the answer was
retrieved over HTTPS, regardless of whether it's in the HTTP response or
not.

Zellyn

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

> No, I understand the downgrade attack, but that is totally unrelated to
> what we were talking about.****
>
> ** **
>
> Provider.****
> Nowhere in the currently proposed “compromise” text is there a proposal to
> fall back as you’re showing it.  A client either requests WF via HTTPS or
> HTTP, not both.  In the case of the latter, it’s not looking for secure
> content or security is a non-issue.****
>
> ** **
>
> Paul****
>
> ** **
>
> *Sent:* Thursday, December 13, 2012 11:54 AM
>
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]

---

From: Zellyn Hunter <[email-masked]>
Date: Thu, 13 Dec 2012 11:55:41 -0800

Paul,

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

> let the user specify the rel type based on preference?****
>
> ** **
>
> making that decision.****
>
> ** **
>
> those?****
> HTTP.  And clients that need security NEVER use HTTP.****
>
> ** **
>
> Paul****
>
> ** **
>

---

From: John Panzer <[email-masked]>
Date: Fri, 14 Dec 2012 07:18:18 -0800

OK good :).

Large server farms that do WF lookups will want to be able to cache the
results via proxy for scalability, the same as any other http request.

I think this means nothing really needs to be said, though people
misunderstand this enough that a "normal http caching rules apply" reminder
might make sense.
On Dec 13, 2012 11:07 PM, "Paul E. Jones" <[email-masked]> wrote:

> between me and my bank, for example.****
>
> ** **
>
> Behalf Of *John Panzer
> *Sent:* Friday, December 14, 2012 1:49 AM
> *Cc:* [email-masked]; James M Snell; Goix Laurent Walter; Brad
> Fitzpatrick
> the client?  Or by trusted caching proxies?****
>
> On Dec 13, 2012 10:38 PM, "Paul E. Jones" <[email-masked]> wrote:**
> **
>

---

From: Breno <[email-masked]>
Date: Fri, 14 Dec 2012 09:14:03 -0800

> client?  Or by trusted caching proxies?

TLS data is cached on the client if served with cache directives, as
long as cache is allowed. Even cache-control:private doesn't disable
caching, simply restricts it to the client. If the client is a trusted
caching proxy (a fairly common scenario) then that means that the
cache is used across individual clients.

>> demanding HTTP as an option (and I’m still looking to hear from those folks)
>> not try HTTP.  If the server is not listening on HTTPS, then it fails.  And,
>> that’s exactly what you want to avoid a security issue.
>>
>>
>>
>> it queries using HTTP.  The server might reply or it might redirect, but the
>> the client.  Either make a secure request or don’t.
>>
>>
>>
>> Paul
>>

-- 
Breno de Medeiros

---

From: John Bradley <[email-masked]>
Date: Fri, 14 Dec 2012 07:52:04 -0200

Yes silent fallback to http is unacceptable. 

Sent from my iPad

On 2012-12-13, at 9:17 PM, Tim Bray <[email-masked]> wrote:

> On Thu, Dec 13, 2012 at 3:15 PM, Brad Fitzpatrick <[email-masked]> wrote:
> Um, maybe me.  What is unacceptable for some applications is if I tell the client “Fetch https://example.com/.well-known/whatever” and for some reason it silently falls back to HTTP.   -T
> 
>  
>> 
>>

---

From: Breno <[email-masked]>
Date: Fri, 14 Dec 2012 17:21:16 -0800

Thinking about it again, as long as no silent fallback is NOT allowed
caching should not be an issue as HTTPS and HTTP URLs remain different
resources