On 03/24/2014 12:20 PM, Daniel Kahn Gillmor wrote:
On 03/24/2014 10:36 AM, Keith Moore wrote:
Yes, it's more work and expense for a site to maintain valid CA-signed
certs. But if clients complain when they're not there, providing
CA-signed certs becomes "part of the cost of doing business", just like
maintaining DNS records, keeping software up-to-date, and so forth.
I think you're making an argument about visibility to the user, not
about actual best practices.
I'm making multiple arguments. One of them is that if users don't know
the difference, there's less incentive for services to use encryption or
upgrade their encryption. Another is that user expectations (among
other things of course) help determine the "cost of doing business" for
services.
I note that many large organizations regularly do *not* pay "the cost of
doing business", especially in terms of keeping software up-to-date,
witness the huge deployments of Windows XP and Windows Server 2003
expected to still be in use long after Microsoft's long-delayed
end-of-life of the OS. Keeping software up-to-date is generally *not*
visible to the user, and thus isn't considered a "cost of doing business".
You're talking about workstation software, I'm talking about the
software used to run servers, so they're not the same thing. In
today's hostile network environment, if you don't bother keeping your
servers up-to-date, you will be attacked (often, and often
successfully), and for one reason or another, you will find it difficult
to keep operating. It's hard enough to cope with zero-day exploits,
but if you don't cope with widely-documented exploits for which ready
fixes exist you deserve to lose.
Keeping accurate DNS records *is* part of the cost of doing business,
because users can't see an organization's network services if they can't
find the address.
Yup. And so is keeping your servers running and not swamped by attacks
of various kinds; hence the need to keep them up to date. Hope that
helps clarify what I was talking about; sorry if I wasn't sufficiently
clear earlier.
Since all of the "opportunistic" proposals i've seen indicate that the
use of opportunistic crypto will not be visible to the user, the
incentives for well-authenticated endpoints will remain the same as they
currently are: services which fail to get some flavor of strong
authentication (whether that's PKIX or DANE or something else) will not
get to see any "this connection is secure" UI decorations. That is,
this *is* a visibilty-to-the-user issue, and the user sees the same old
insecure state. So if "having a visibly secure connection" is the cost
of doing business, opportunistic encryption is not enough.
Users should *not* be told that communications are "secure" when they
are vulnerable to trivial active attack.
I certainly agree with the last sentence.
So, what's the incentive for either clients or servers to support OE if
clients just silently accept it without any indication to the user?
Just for the good of mankind? While I agree that pervasive OE would be
better than pervasive cleartext, and also agree that the use of OE
shouldn't give users any indication that the connection is "secure", I
think we should be realistic about the likelihood of clients
implementing OE and services using it. And while I'm sure that
sometimes implementors and operators will do things "for the good of
mankind", I suspect there's a limit to how much effort and expense
they'll go to for this reason. This doesn't mean "don't even bother
recommending OE", but it seems like something we should keep in mind.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta