On 03/23/2014 06:32 PM, Michael Richardson wrote:
Keith Moore <[email protected]> wrote:
> Note that as far as I can tell, it will still be possible to implement a
> client that supports only OE; it just doesn't bother verifying the cert /
> DNSSEC + TLSA record / pinned key / whatever. Whether that client will
> conform to the recommendations that this group produces, is a different
> question. But offhand I don't know of a way to keep such clients from
> working (though for new protocols, it might be nice if there were one).
Well, that's not really correct advice.
As Eliot Lear pointed out, it's not intended as advice; it's just a
recognition of the inherent limitations of the situation that we face.
However...
The correct advice is that:
If the client is unable to verify the cert via (some set of methods,
locally determined), that it treats the connection as if it was
unencrypted, according the same level of (un)privileges.
The "correct" advice is highly dependent on the needs of each particular
application, AND for existing applications, on the current expectations
of users and the difficulty of changing those expectations.
This is the important part of OE (the spirit of 4322, if you like).
It isn't that one doesn't verify, it's that one doesn't fail if
one is unable to verify.
I strongly doubt that this is appropriate advice for all (or even most)
applications or protocols. In particular, if there's some reason to
believe that a server intended to provide a verifiable cert, if that
cert is in fact not verifiable, this is an error condition that
shouldn't (inherently) be masked by silently treating the connection as
if it were cleartext.
The biggest reason that cleartext is still so widely used today in some
protocols that support TLS, is that in practice for those protocols,
cleartext is sufficient to get clients to work without complaint. If
clients continue to work without complaint for sites that support TLS
with self-signed certs, there will be no incentive for services to
provide anything other than self-signed certificates.
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. If
clients don't complain when given invalid certs, providing CA-signed
certs will widely be seen as an unnecessary nuisance.
We should of course realize that for some cases (perhaps ordinary web
sites, or SMTP servers serving as mail exchangers) there is so much
inertia around cleartext operation, and so little affinity between
clients and servers, that it will be very difficult to do better than
OE. Perhaps in those cases treating TLS with a self-signed cert as
equivalent to cleartext will be the best we can ever do, though even in
these cases I think we should carefully consider other options. But we
should not lull ourselves into thinking that this is appropriate as a
general rule, so that we fail to examine the potential alternatives for
other situations or protocols.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
