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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf