Re: IETF mail server and SSLv3
John C Klensin <john-ietf@jck.com> Mon, 22 February 2016 09:02 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5601B2C59 for <ietf@ietfa.amsl.com>; Mon, 22 Feb 2016 01:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Level:
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.006] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rvpd7-6YB5Wo for <ietf@ietfa.amsl.com>; Mon, 22 Feb 2016 01:02:02 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A883A1B2C3F for <ietf@ietf.org>; Mon, 22 Feb 2016 01:02:02 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aXmNK-0005Em-Ee; Mon, 22 Feb 2016 04:01:50 -0500
Date: Mon, 22 Feb 2016 04:01:45 -0500
From: John C Klensin <john-ietf@jck.com>
To: Lixia Zhang <lixia@cs.ucla.edu>, ned+ietf@mauve.mrochek.com
Subject: Re: IETF mail server and SSLv3
Message-ID: <9D5AC0F779B5EF8671F1C705@JcK-HP8200.jck.com>
In-Reply-To: <C648693E-F23F-4129-A790-70474357ADCC@cs.ucla.edu>
References: <F38A9FEF-7DBB-4F40-860E-6CB425E5EEE3@ietf.org> <000a01d1585b$60b68e60$4001a8c0@gateway.2wire.net> <FD83B269-D641-4207-B4EE-922747449B2E@piuha.net> <4EF78885-B743-4134-A30E-AC7F38D5D6D1@cs.ucla.edu> <01PWFPHYMSA800008P@mauve.mrochek.com> <C648693E-F23F-4129-A790-70474357ADCC@cs.ucla.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/kQPAQ9M8gHNS9FAMM4ies_T-VYM>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Feb 2016 09:02:03 -0000
--On Sunday, February 21, 2016 09:08 -0800 Lixia Zhang <lixia@cs.ucla.edu> wrote: > There has probably been no idea more damaging to the security > of the Internet than the idea that end-to-end is the only way > to do security. > > Email is an intrinsically store and forward system. Every > network mail system has had at least three parties and > Internet mail has had a four corner model since the early 90s. > > I'd also add that this issue is not limited to just email (a > cisco forecast claims that "Sixty-two percent of all Internet > traffic will cross content delivery networks by 2019 > globally", note that today's CDN traffic is not limited to > videos, but includes other more critical contents). Lets > recognize the fact that "Internet achieves end-to-end security > by end-to-end encrypted channel" is an illusion, as data is > not delivered through an end-to-end connection in many cases > today, and it is likely to become more so with more mobiles > and DTN-style apps. Lixia, While I agree with everything you say above, I am not clear about where you think it takes us. In particular, there is a layering issue involved with, e.g., "end to end" meaning something different for IP and TCP than it does for, e.g., mail payloads. Precisely because of the comments you make above in combination with the observation that there is a much more extensive history of compromised servers (including those that relay mail)than of compromises to the long-haul network, where the latter is involved, I'm aware of only two alternatives: (i) Encryption of content on what the email community often describes as an end-to-end basis. (ii) More or less explicitly trusting every system involved in the transmission of the message. In most cases, the second alternative should be treated with derision. As with packet headers at lower levels in the system, the above does nothing to protect against those whose interest is in the information about where traffic is originated and where it is bound. john > >
- Re: IETF mail server and SSLv3 Lixia Zhang
- Re: IETF mail server and SSLv3 John C Klensin
- Re: IETF mail server and SSLv3 John Levine
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- IETF mail server and SSLv3 IETF Chair
- Re: IETF mail server and SSLv3 tom p.
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- Re: IETF mail server and SSLv3 Jari Arkko
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- Re: IETF mail server and SSLv3 Jari Arkko
- Re: IETF mail server and SSLv3 Derek Atkins
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 John C Klensin
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- Re: IETF mail server and SSLv3 John C Klensin
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 ned+ietf
- Re: IETF mail server and SSLv3 Lixia Zhang
- Re: IETF mail server and SSLv3 John C Klensin
- Re: IETF mail server and SSLv3 Martin Rex
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Solarus
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Solarus
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Martin Rex
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Russ Housley
- Re: IETF mail server and SSLv3 Randy Bush
- Re: IETF mail server and SSLv3 Stephen Farrell
- Re: IETF mail server and SSLv3 Phillip Hallam-Baker
- Re: IETF mail server and SSLv3 Viktor Dukhovni
- Re: IETF mail server and SSLv3 Doug Barton
- RE: IETF mail server and SSLv3 Christian Huitema