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

> 
>