Policy vs. URI (Re: Semantics of HTTPS)

On Sep 13, 2012, at 12:39, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:

> "we are secure, but don't really think we need to be".

Security is not a binary thing.

There are historical reasons why we only have a binary flag to express security policy in a URI.

It is not quite clear that the URI is the right place for expressing security policy.
We are developing out-of-band mechanisms to express security policy that attach to the URI (e.g., HSTS).

Where we continue to put policy into the URI, the following things seem to be pretty much cast in concrete:
-- a different scheme means a different namespace (so you can't change the policy separately from changing the resource as well),
-- the https scheme is used both by people, where we have achieved some basic awareness and consensus about its meaning, and in a programmatic way,
-- the latter is largely broken in practice (e.g., see the recent brouhaha about Apple in-app payments),
-- the wide deployment in a user-visible fashion means that we have to curate the scheme with a dominant objective of avoiding security-relevant surprises.

So the question is less "what should be the semantics", but "how can we evolve the semantics without breaking too much".
It seems clear to me that the conservative thing is to stick with a narrow "end-to-end" understanding for https://

More interesting to me right now is how HTTP over TLS *should* be used in programmatic usage.
We are about to copy over the present unsatisfactory status quo from https to coaps, and I'm deeply concerned about that.
What part of the security policy should be encoded in the URI, what should be out-of-band, and what are the preferred mechanisms to deliver that out-of-band information securely?  E.g., how does HATEOAS obtain its security stance?
This question probably goes beyond the current charter of this group, but it would be worthwhile to look at the bigger picture.
It is probably impossible to do this for both the programmatic (web-services, M2M, ...) and user-visible domains, so I'd start with the former, very well knowing that there is some overlap.

Grüße, Carsten

Received on Thursday, 13 September 2012 13:46:06 UTC