Subject: [websec] Well-known URIs

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Aug 2013 14:35:46 +0200

Hi,

I see there's discussion of well-known URIs for Websec over here.

Just a few points that may help… or not.

1. Well-known URIs are designed for cases where the client wants to get a bunch of *related* data together; as such, a general framework is encouraged, as long as the use cases are similar. 

This is why I don't like hostmeta; it's a bucket for anything you want to throw in there, which means that over time, the client will be getting a lot of information they don't want, which will necessitate a query language, which is just nasty overkill. At the other end of the spectrum, having a single-use well-known URI in the critical path (or even not) for a browser is similarly Not A Good Idea.

2. Discovering whether a well-known URI is present on a given host without much overhead is the use case for browser hints: <http://tools.ietf.org/html/draft-nottingham-http-browser-hints-05>.  Looking for a better name for that one…

3. Alternatively, if browsers are pre connecting, they could use the conn to fetch a well-known URI, as long as it was cheap to fetch. That policy file could even control how aggressively the browser pre-connects (two birds, one stone…).

Hope this helps,

--
Mark Nottingham   http://www.mnot.net/

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 12:31:58 -0700

> This is why I don't like hostmeta; it's a bucket for anything you want to throw in there, which means that over time, the client will be getting a lot of information they don't want, which will nec…

Can you say clearly what else we should stuff into the W-K URI for
HPKP? What other working groups and standards bodies are we going to
have to reach consensus with?

> 3. Alternatively, if browsers are pre connecting, they could use the conn to fetch a well-known URI, as long as it was cheap to fetch. That policy file could even control how aggressively the brows…

You just said it should *not* become a catch-all bucket.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Aug 2013 20:27:26 +0000

Hi Chris

> have to reach consensus with?

The answer to those questions is "nothing" and "none".

let's assume the format is JSON, we could call the resource https://www.example.com/.well-known/TransportSecurity.json , and it could be formatted like this:
{
    "HPKP": {
        "max_age": 2592000,
	"include_subdomains": "false",
	"pins": [
            {
                "alg": "sha1"
                "hash": "aQWqfl0MQRwcM+3uffZ08Rttods="
            },
            {
                "alg": "sha256"
                "hash": "Lbl5D9eR4PLiaOUSeO6sue2QrSvpB31F4mte/4D75xM="
            },
        ]
    }
}

Then if someone wants to add HSTS into this, they're welcome to it, but they'll need their own document to do it.

Yoav

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 14:18:07 -0700

> The answer to those questions is "nothing" and "none".

Sounds good to me.

> Then if someone wants to add HSTS into this, they're welcome to it, but they'll need their own document to do it.

I was thinking maybe we could get rid of max_age and have the max age
be simply the lifetime of the resource as defined by the Cache-Control
header. Maybe that's a bad idea, I don't know.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Aug 2013 21:45:23 +0000

> header. Maybe that's a bad idea, I don't know.

[no hats]

I don't like it. Especially if we keep it extensible, and something else (HSTS?) might need a different value. Besides, adding this resource to a server is easy - just place a file in the right directory. Changing the Cache-control properties of one particular resource on the server is harder if at all possible - it depends on the server software.

Yoav

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Aug 2013 18:01:51 +0800

> have to reach consensus with?

Um, implementers?

> You just said it should *not* become a catch-all bucket.

It's a subtle thing. You want things that tend to be accessed at the same time, by the same clients; that's the shape of the bucket. They may or may not be related conceptually; it's all about audience (sort of like user-centred design).

Cheers,