RE: Review of: Opportunistic Security -03 preview for comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am uncomfortable with the MUST.

fallback to cleartext is often helpful (web caching and performance proxying of graphics/noncritical items), useful for debugging, and does not inadvertently prevent communication when the security apparatus inevitably screws up.

I view fallback to cleartext as a feature, not a bug. (I often edit https to http in urls - if the server wants to serve https, fine, but I am not going to demand it - and dnssec is just another point of failure.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Nico Williams <nico@xxxxxxxxxxxxxxxx>
Sent: Sunday, 17 August 2014 6:16:08 AM
To: Wood L  Dr (Electronic Eng)
Cc: stephen.farrell@xxxxxxxxx; fred@xxxxxxxxx; dcrocker@xxxxxxxx; presnick@xxxxxxxxxxxxxxxx; paul@xxxxxxxxx; ietf@xxxxxxxx
Subject: Re: Review of:  Opportunistic Security -03 preview for comment

On Sat, Aug 16, 2014 at 02:21:18AM +0000, l.wood@xxxxxxxxxxxx wrote:
> I'd like to see this draft discuss http early on - redirecting any http
> request to https (via 301/302/303/307 redirection) for login pages etc.
> is transparent, opportunistic, and easy to do, and a widespread example
> that gets the opportunistic idea across; I've explained this to Stephen
> previously.

OS should be applied to HTTP, but there may be enough to discuss there
that we'd never finish with this I-D if we had to deal with it now.

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.

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.  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.

Nico
--






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]