----- Original Message -----
From: "Randall Gellens" <randy(_at_)qti(_dot_)qualcomm(_dot_)com>
To: <l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk>;
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>; <ietf(_at_)ietf(_dot_)org>
Sent: Friday, April 04, 2014 12:24 AM
Subject: RE: Security for various IETF services
My reaction is also to ask "Why?" Security and privacy involve
trade-offs where various costs (including operational difficulty) are
weighed against the benefits, such as protecting information from
unauthorized disclosure or modification. So, I'd suggest that a
blanket statement isn't a good idea, but rather, a service-by-service
decision should be made. For example, XMPP and document submission
may justify requiring encryption while email and document retrieval
might not.
Yes, it is a trade off, a more secure service, for some meaning of
security, but a worse service for some users or usages.
Setting up a TLS session takes time; I notice every time I access
e-mail, ever since my ISP required the use of TLS. It is only a few
seconds, but it means that I batch my usage rather than doing it
promptly, and every so often forget and shut down without having sent a
message in reply. And certainly with that e-mail access, it is forever
tearing down the TLS session and creating a new one, e.g. between
sending e-mail on an account and receiving it from the same account, so
one (unmet) requirement is that having gone to the cost of setting up a
session, it stays up and is reused.
And then there is CRL checking. I would assume that that would be
recommended as part of a secure system, yet with the IETF website, that
hangs the session. The CRL is downloaded and ...... hours later, the
web page has yet to display. There is something weird about the IETF's
use of certificates which other websites do not share. Surmountable no
doubt but it means that a secure service is a worse service than that
obtainable via HTTP.
And what threat is this trying to counter? a corrupted DNS directing me
to a phishing website of a foreign power?
Tom Petch
--
Randall Gellens