On 22.03.2011 18:53, Dean Willis wrote:
On Mar 22, 2011, at 10:23 AM, Alessandro Vesely wrote:
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.
Not surprisingly, criminals are about as gullible as honest users. They
record on the phone phrases that can be used in a trial to prove their guilt
before a court. The symmetry-breaking originates from the commonly held
assumption that prosecuting criminals is useful to keep the community in an
orderly state. As humans, our job is to improve the definition of community
so that that works with current technologies. That is to say, although the
community is a self-defining entity, since we recognize it, we can and must
bring some technical consistency in its definition.
Let me quote SM here,
. There are technical problems and social or political problems. The IETF
. can only address the technical problems. It is up to the people who adopt
. the technical solutions to address the social and political problems.
. They do not do that. Instead, they pretend, or assume out of ignorance,
. that the IETF has solved all the problems and the magic of technology will
. do the rest.
It is harder to retro-fit policy issues in an already designed protocol.
However, that's the way things go. It would have been better to design SMTP
being well aware of spam. We didn't, and hence cannot claim that it is not
our problem if users fail to address our tentative remedies.
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.
SMTP-AUTH could also be used to authenticate relays of well identified
traffic, such as mailing lists or newsletters. It is not a problem for this
list, which is wonderfully maintained. Use of submission could be certified
according to Section 2.4.4 of RFC 5451; I, for one, don't do so in order to
avoid revealing the authenticated ID, as it can be used in distributed
dictionary attacks. DKIM and SPF provide something quite similar to
authentication, possibly simpler and slightly more used than S/MIME.
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.
Yes, explicit consensus is also mandated by EU privacy rules. Perhaps, we
should set up a mechanism to automatically grant consensus. At least, we
would then be able to easily identify the corresponding message stream.
Of course, the need to authenticate will not be felt until it is possible to
deliver mail without it. That raises the issue of how can you authenticate a
client with no prior arrangements, as required by SMTP. Thus, we are back to
the definition of community, and that's why I consider mail a good test- bed.
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.
But that won't help if the protocol is not deployed. Requirements analysis,
promotion, deployment, training, and education are equally important.
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.
Ideally, yes. However, if we manage to push the genie back into the bottle,
we may end up with a generic recipe for securing protocols after-the-fact.
Perhaps we should just have Google host a Gmail-four-our-domain setup,
have everybody use that, and preclude external email addresses from
participation?
Walled gardens and private enclosures are an obvious alternative to
democracy. I think we'd prefer free range humans over intensive (battery)
people. The boundary is quite fuzzy, though, and that solution is good as
far as Google /is/ a community.
On a related point, is the end-users' computing equipment --possibly
including their brains-- an integral part of their personal belonging, or is
it the property of some private/public enterprise? I know this is not a
technical question, but if the IETF has to address the issue of retro-fitting
privacy into communication protocols, it had better know whether to target
Google or their users.
The whole standardization process assumes a community with certain
characteristics, that supports such work and deploys its results. The IETF
sometimes adapts to community changes, retains sound principles, sometimes
resists yielding up to the market, tracks the outcomes of its work, but does
not structurally resonate with the community because of those social/
political barriers.
That's a great tripartate slogan for the counter-revolution. I would
happily buy a reasonable T-shirt that proclaims "Skepticism, Opportunism,
Thoughtlessness!"
Now that you've said it, I'd buy it too :-)
This sort of "general theory" considerations still belong to this list.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf