Re: Security issues with draft-ietf-tsvwg-iana-ports-08
Eliot Lear <lear@cisco.com> Thu, 04 November 2010 09:41 UTC
Return-Path: <lear@cisco.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7083A69DA for <tsvwg@core3.amsl.com>; Thu, 4 Nov 2010 02:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vStFuoi4TrA for <tsvwg@core3.amsl.com>; Thu, 4 Nov 2010 02:41:35 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0591E3A6A02 for <tsvwg@ietf.org>; Thu, 4 Nov 2010 02:37:51 -0700 (PDT)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIDAF8b0kyQ/khMgWdsb2JhbACDKJ5MFQEBFiIioiSKLpB+gSKDMXMEilU
X-IronPort-AV: E=Sophos;i="4.58,294,1286150400"; d="scan'208";a="12604580"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Nov 2010 09:36:56 +0000
Received: from ams3-vpn-dhcp6931.cisco.com (ams3-vpn-dhcp6931.cisco.com [10.61.91.18]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oA49atZS001976; Thu, 4 Nov 2010 09:36:55 GMT
Message-ID: <4CD27ECF.1010500@cisco.com>
Date: Thu, 04 Nov 2010 10:37:19 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Security issues with draft-ietf-tsvwg-iana-ports-08
References: <4CCD6B0B.5040804@isode.com> <p06240842c8f7b9ba2577@[10.20.30.150]>
In-Reply-To: <p06240842c8f7b9ba2577@[10.20.30.150]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Nov 2010 09:41:40 -0000
Paul, Thanks for taking the time to review the document. A few thoughts, which may seem somewhat discombobulated at first, but bear with me: > First, I should probably apologize. I am the author of RFC 2487 (updated by RFC 3207), the now-infamous "STARTTLS" option for SMTP. It seemed like a good idea at the time, it really did. No need for a second port and possible delays due to port-probing: just do an in-band security upgrade. And it could work with other common application protocols like POP and IMAP as well (RFC 2595)! > > History has shown us wrong, but draft-ietf-tsvwg-iana-ports ignores that history. History hasn't entirely shown you were wrong. I think history has shown that getting certificates in place is a difficult administrative task for mail, and in general. I don't think port separation has anything to do with it. I think you ought not apologize for the work you have done. Rather it was very useful to highlight the difficulties of configuring the application, quite frankly, and that HAS improved over time (using sendmail as my benchmark). > In short: > > - There are serious security drawbacks to doing in-band upgrades within SMTP. Notice the large number of new attack descriptions and warnings in RFC 3207. One thing I note is that it may be time for an update to 3207. In particular, you wrote: > A publicly-referenced SMTP server MUST NOT require use of the > STARTTLS extension in order to deliver mail locally. This rule > prevents the STARTTLS extension from damaging the interoperability of > the Internet's SMTP infrastructure. That should be a deployment choice, right? If I choose to reject your mail because I don't want to receive unencrypted mail over the Internet, that is my choice. Otherwise you are actually encouraging a downgrade attack. But to this end, I would also suggest that when viewed in the light of what has gone on with DKIM, some of your security analysis provides for an interesting path forward. You write, for instance: > A man-in-the-middle attack can be launched by deleting the "250 > STARTTLS" response from the server. This would cause the client not > to try to start a TLS session. Another man-in-the-middle attack is > to allow the server to announce its STARTTLS capability, but to alter > the client's request to start TLS and the server's response. In > order to defend against such attacks both clients and servers MUST be > able to be configured to require successful TLS negotiation of an > appropriate cipher suite for selected hosts before messages can be > successfully transferred. The additional option of using TLS when > possible SHOULD also be provided. An implementation MAY provide the > ability to record that TLS was used in communicating with a given > peer and generating a warning if it is not used in a later session. As we have seen with DKIM it is now possible to express policies out of band. I wonder whether we should generalize this approach, and would be interested in your views. I'll note that in the case of SMTP and publicly facing servers, for instance, there really is no alternative for a second port at the moment because there is no way to express the security desire in an MX record. Food for thought. This is less the case, of course, through the common use of "s" or ".tls" or the like in a URI schema, but the reason that Joe, Magnus, and others have taken the position they have is not simply one of stewardship (although in my opinion that is good enough), but also simply because time has passed, our capabilities have evolved, and we really ought to be able to get this right. > - POP and IMAP have well-known upgrade semantics as well as each having a second port for TLS. Nearly all implementations use the second port, and interoperability for the upgrade mechanism was not widespread when it was last tested. > > - SIP's two-port scheme has worked incredibly well. The above two statements ring true to the point of concern for me with regard to the current draft. Do we have sufficient infrastructure in place to provide a best practice for those future services such that the 2nd port isn't needed? And this is where I think we tie the above point together. Should we have better generalized OOB mechanisms like ADSP for instance to indicate security policy FIRST? And this relates of course to another problem we have with port allocation, which is discovery. That chews up even more ports. Do we have infrastructure in place to put an end to that, and should we before proceeding further? > - Having multiple code paths for "now you are in the clear" and "now you are under TLS" has proven to expose some serious security risks that do not exist for when a second port is used. I think you will agree that multiple code paths exist, no matter whether a separate port is used, but perhaps you could say more about the threat here. > - Attempts to create TLS-like encryption and/or integrity protection without actually doing TLS usually ends up with security holes not in TLS. +1 but I don't see how it relates to your other points. > - The number of new application protocols created over the past decade is significantly lower than was expected. By whose measure? Thanks, Eliot
- Security issues with draft-ietf-tsvwg-iana-ports-… Paul Hoffman
- Re: Security issues with draft-ietf-tsvwg-iana-po… Gorry Fairhurst
- Re: Security issues with draft-ietf-tsvwg-iana-po… Eliot Lear
- Re: Security issues with draft-ietf-tsvwg-iana-po… Paul Hoffman
- Re: Security issues with draft-ietf-tsvwg-iana-po… Paul Hoffman
- Re: Security issues with draft-ietf-tsvwg-iana-po… Eliot Lear
- Re: Security issues with draft-ietf-tsvwg-iana-po… Magnus Westerlund
- Re: Security issues with draft-ietf-tsvwg-iana-po… Paul Hoffman
- Re: Security issues with draft-ietf-tsvwg-iana-po… Magnus Westerlund
- Re: Security issues with draft-ietf-tsvwg-iana-po… Paul Hoffman
- Re: Security issues with draft-ietf-tsvwg-iana-po… Eliot Lear
- Re: Security issues with draft-ietf-tsvwg-iana-po… Joe Touch
- Re: Security issues with draft-ietf-tsvwg-iana-po… Joe Touch
- Re: Security issues with draft-ietf-tsvwg-iana-po… Joe Touch
- Re: Security issues with draft-ietf-tsvwg-iana-po… Joe Touch