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