--On Friday, August 26, 2011 16:15 -0400 Eric Burger
<eburger(_at_)standardstrack(_dot_)com> wrote:
Two thoughts.
On the one hand, Ned is absolutely correct: the thing we want
to make absolutely sure of is the integrity of the object. The
way of doing that is making sure the object itself can prove
its integrity. In the messaging world, we do this with
S/MIME. The use of TLS for SMTP or IMAP does not convey any
integrity assertions for the object. Note this object should
be signed by me when you receive it, by the way.
And it verifies too... sort of. Note that the IETF mailing list
machinery tries to prevent it from doing so by appending a
footer to tell everyone who it is (independent of the standard
List-* headers that contain the same information). Another
separate problem, but definitely falling into the "dogfood...
yum" category.
On the other hand, while TLS is not at all sufficient for the
integrity of the object, it is necessary to protect the
individual accessing the object. There are a number of
countries where asking for the RFCs relating to privacy,
security, and threats to such too many times could get you
arrested.
Yes, although it isn't entirely clear that TLS actually provides
enough protection in practice. A sufficiently paranoid
government with those concerns would either force the
connections through proxies that it controlled (see Keith's
note) or would notice connections to IETF servers and "inquire",
through out-of-band means, about what was being retrieved.
There are ways to protect against that risk, but assuming that
unadorned https is sufficient is almost certainly naive.
Likewise, the presumption is the object might be
signed, but it would be insane and useless to encrypt the
object. However, there are many, many times one would want
the object encrypted, even if only to compress it.
Sure. If TLS actually worked for its intended purpose in the
overwhelming number of cases, nothing that Ned or I have said
would argue against using it. In that regard, the problems are
that it is assumed to solve several problems for which it is
useless and several others, including your example above, for
which its effectiveness is dubious against an attacker with
sufficient non-network resources.
Given that, the question should not be, "Why are we using TLS
if the object is not private?," but "What are we not using
secure connections for all IETF access, over any modality?"
One of the answers seems to be, "Because it sucks." That is
the sentiment of the message below.
So we are eating our dog food, and we are getting indigestion.
Sounds like an opportunity to fix it!
I think it is more than that. If we (and the Secretariat and
IASA) cannot get it together to keep certs up to date, or at
least to get them updated _very_ quickly when someone notices
that they have expired (note that it is now only a few minutes
short of 24 hours since the thing expired), we are sending a
pretty strong message to the community that we don't care and no
one else should either. Remember that the message browsers pop
up when an invalid or expired certificate is encountered is
totally incomprehensible to a typical luser, offering only
choices of not accessing a site that contains useful information
and that was valid before and accepting the cert, errors and
all. The more valid sites there are with invalid certificates,
the more we train the user to accept those invalid certificates,
rendering the whole certificate idea (and TLS with it)
pointless. By choosing to contribute to that problem, the IETF
undermines the utility of TLS for addressing the real issues of
server authentication and client-> server encryption that it was
primarily intended to address.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf