On Sat, 16 Aug 2014, Nico Williams wrote:
But yes, HTTP w/ OS is something we'll definitely want. At the most
basic level if a server advertises TLSA RRs in DNS, verifiable with
DNSSEC. Then HTTP clients that support OS should (MUST!) use HTTPS for
all HTTP requests to such a server.
Excellent. If only people had listed to me when I proposed this meaning
to the TLSA record, and people had not gone the HASTLS/nowhere route :)
I'd be happy to write an update to RFC 6698 with such text :P
The tricky issue is: how can users and hypermedia authors denote "no
fallback to cleartext" -- adding a new URI scheme is the first thought
that comes to mind about that, but it seems likely not to be that
simple.
URI's are for software, not humans. Humans cannot do "http" vs "https".
Admittedly a "no fallback to cleartext" indication may prove
unnecessary: eventually support for unauthenticated encryption may reach
a large enough proportion of servers that clients can begin disabling
fallback to cleartext. But you see my concern: it's too soon to tell
whether we'll need to do anything about indicating no fallbackto
cleartext.
I would leave that to the UI people. Personally, having the red glow
over my page instead of a warning box I'll just click away seems a
reasonable override for "protocol hardfail".
Paul