"Ted" == Ted Lemon <ted(_dot_)lemon(_at_)nominum(_dot_)com> writes:
Ted> On 07/13/2015 10:08 AM, Sam Hartman wrote:
>> My concern about this advice is that no one will implement it
>> because it will break portals. Modern web pages use scripts for
>> a lot of things. If I were writing such a portal, I'd almost
>> certainly use scripts for some things and probably if I were
>> writing it as a new app use a client-side framework like angular
>> where the entire thing was one script. So, it's great security
>> advice, but entirely impractical.
Ted> I don't think it's that impractical to write your web page so
Ted> that it works with or without javascript, and this is a clear
Ted> case where it makes a lot of sense to do so.
Speaking as someone who manages web development projects and web
authentication software projects. Increasingly, writing an application
to work without javascript doubles the software development costs and
reduces the quality of the user experience.
(You choosing to use the term web page begins to chart the boundaries of
the chasm across which we're failing to speak.)
In addition, if you want any sort of security beyond usernames and
passwords, you're probably going to want to use javascript. That's
right; there is a tradeoff between better authentication technology and
dependence of your sandboxing technology.
I agree with your advice about certs and cert validation.
I think it would be desirable in addition to suggest that servers for
these portals staple OCSP responses to their certs. That's something
people actually could implement and that software would sometimes take
advantage of if they did.
Since no browsers support DANE, I don't think it's fair to give an
operational recommendation in favor of DNSsec. I don't think it buys
you anything with today's software.
We could say something like the combination of DANEsupport in the
browsers and DNssec/TLSA records would provide a good way to establish
trust in websites in this situation. It's true at least.