The 's' in https: more trouble than it's worth? [metadataInURI-31]

I think that one of the main arguments for the separate port number and 
URI scheme
for https was that the client software needed to know to make a secure 
connection;
upgrading from a clear connection to a secure connection is subject to 
man-in-the-middle
attacks.

At the workshop this week, the focus was on the "last two feet", i.e. 
between
the client software and the human operator, and from this perspective, 
it
seemed that the 's' is more trouble than it's worth. There's a failure 
mode
where
   User follows a link to https://example.com/pg
    - example.com is under attack; doesn't respond
  User tries http://example.com/ instead.
   - bad guy has gotten in the middle, and fleeces user

The argument might have been more subtle than that. I hope somebody can 
help
me re-create it.

There are, of course, problems of aliasing and such.

There was some argument that http: is enough, combined with...

   Upgrading to TLS Within HTTP/1.1 Khare and Lawrence May 2000
   http://www.ietf.org/rfc/rfc2817.txt

I think this is one of the more subtle cases of metadata in URIs.
I was happy to let it sleep indefinitely, but with renewed work on 
security,
it's perhaps time to take another look.

I don't see this case discussed in either of
   http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
   http://www.w3.org/2001/tag/2006/02/metadatainURI31Roadmap.html

I see that Noah concludes Roadmap with a nice short 4-point list.
Maybe the case of https should be treated in a separate document.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 17 March 2006 23:32:39 UTC