On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote:
I'm sorry I'm late, this thread was in my backlog.
We now have an obscurity-interest(_at_)ietf(_dot_)org list for further
discussion if you wish to join us there.
On 12.03.2011 19:48, Dean Willis wrote:
On a related note, we've developed what we think is a secured mail
protocol suite. Yet we don't use it, instead subjecting our list members
(and more so the administrators) to having to deal with an endless barrage
of spam. We probably don't use our secured mail protocol because it is too
cumbersome. Maybe that should be a wake-up call for us to develop a better
way to secure mail.
What secured mail suite? I have some difficulty in recognizing whether
you're talking about SMTP + Submission + DKIM + whatever else or some other
messaging system. I agree that current Internet mail, with its one-figure
legitimate traffic percentage, is a conspicuous representative of IETF's hall
of shame.
We have this whole S/MIME thing that nobody uses. We tried to replicate it to
real-time communications, like SIP and Instant Messaging. Oddly enough, nobody
uses it there either. Maybe that's because it doesn't deploy very well.
Most critically, we've recognized that Internet users may have needs for
privacy [...] And having recognized these principles, we need to start
taking much more aggressive steps in protocol design to assure that they
are actually being met in a useful way.
I also heartily agree with this, and with all the motivations that inspired
this thread. However, I have difficulties resolving my feelings on this
point: Freedom activists in my country bring out a whole load of grievances
every time Berlusconi attempts to restrict usage of wiretapping. In facts,
this tool is a requirement for carrying out investigations at a sustainable
cost.
I'm not necessarily against wiretapping. I think it's a great way to build a
criminal enterprise, if that's your goal.
However, I am against explicitly designing exploitable weaknesses into our
protocols. I'm even against implicitly designing in exploitable weaknesses by
leaving compliance-test requirements for security as "SHOULD" strength issues,
or by writing the specs in such a way that we can expect the security functions
to never be implemented or used.
I think the IETF must substantiate its position against wiretapping by
providing alternative practical means to counter crime.
Weak security doesn't counter crime -- it creates it. For example, the US
government recently illegally tapped lots and lots of phone calls and Internet
traffic at an AT&T switching center. Had the traffic been properly secured,
this criminal behavior could have been prevented.
Do you want to counter crime, or prevent criminals from communicating with each
other? One is laudable. The other is prior restraint of freedom of speech.
Failing to do so
would recast ourselves as proposers of Utopian designs. And, yes, after more
than a decade of spam supremacy, email would certainly be a convincing
test-bed for our ability at providing such alternative means.
We can start by:
1) deprecating the non-secured variant of every core protocol that has
both secure and non-secure variants
Among SMTP variations, RFC 4409 is the more promising requisite for solving a
number of authentication issues. Note that it conflicts with peer-to-peer
visions à la mondonet, though.
Well, it's better than nothing. It's got my spam load down to a bit less than
98% of my incoming mail.
But we can't expect every IETFer to SMTP-auth with the IETF server for every
message they send to an IETF list. Nor can we detect whether remote domains
used RFC 4409, nor can we filter on that knoweldge. Consequently, our lists get
spammed.
Perhaps every server-to-server SMTP transmission should be authenticated and
authorized. We tried this (authorizing intermediaries) with SIP's "Consent
model". See RFC 5360. That didn't work either; the genie was already out of
the bag, and having too much fun running around in his pajamas.
2) not writing any more protocols with secured and non-secured variants
3) analyzing existing protocols that are fundamentally non-secured and
determine which, if any, security enhancements should be made normative
While these are certainly correct, ensuring implementation and deployment is
also fundamental. I accept and respect the limits of IETF's action, and
consider non-enforcement a key feature in the volunteer-oriented design that
is being carried out. However, we should pay more attention to the full
protocol life cycle.
I believe that from a security perspective, the most important part of the
protocol life cycle is the development and testing phase. People tend to rush
right to deployment once something is "basically working". If "security" is
deferred to a follow-on exercise, it just doesn't happen.
Consequently, we need to make sure that every protocol we write includes its
security solutions in the base protocol, not in a layer to be added later.
Phase 1 should be establishing a secured channel -- phase 2 is getting the
application to work over that channel.
Perhaps we should just have Google host a Gmail-four-our-domain setup, have
everybody use that, and preclude external email addresses from participation?
4) Doing a much better job of really analyzing the security considerations
of new work, taking fully into account the principles of privacy,
integrity, and obscurity. Keep in mind that every protocol has the "good
citizenship" responsibility not just of addressing these principles
itself, but of also helping its fellow citizens meet them.
I understand this as a recommendation to provide means for users of a
protocol --either another protocol or the "end" user-- to discover in some
meaningful way what are the relevant characteristics of the current
communication. By "meaningful" I mean the opposite of those audible but
unidentifiable beeps that all too frequently infest work rooms :-)
It's your responsibility to lock your doors even if you have nothing to steal,
because if criminals get used to thinking of all doors as locked they aren't
likely to keep rattling doorknobs to check.
What I'm saying is that even if your traffic isn't "sensitive", that you should
treat it as if it were. This makes the traffic for people who ARE worried about
being overheard not stand out. It's your responsibility to make your traffic
look like gibberish to an intercepter, so that MY traffic (which looks like
gibberish even when not encrypted) won't draw undue attention. Be a good
neighbor, and help me blend in!
5) Incorporating the principles of Privacy, Integrity, and Obscurity
directly into our core mission statement, into the very fabric of our
belief system, just as "Liberté, égalité, fraternité" became the driving
motto of the Third Republic of France, ending much of the abuse of
Privilege that preceded the revolution.
Yes, and, like for points 2-3 above, we must take care of how these
principles are understood by the community at large. Skepticism,
opportunism, and thoughtlessness have spread too much.
That's a great tripartate slogan for the counter-revolution. I would happily
buy a reasonable T-shirt that proclaims "Skepticism, Opportunism,
Thoughtlessness!"
--
Dean
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf