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