Re: Security issues with draft-ietf-tsvwg-iana-ports-08

[Paul Hoffman <[e-mail]>]

At 10:37 AM +0100 11/4/10, Eliot Lear wrote:
>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).

The still-difficult task of getting certificates in place is orthogonal to whether protocols should be restricted to a single port. History has shown that foo-over-TLS does work, and can be done securely.

> > 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.

Correct. But this argues for a two-port solution, not an inline-upgrade requirement.

>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.

This brings to the fore the question of launch-by-URI vs. launch-by-app-configuration. Today, it is very rare for someone to retrieve their email by double-clicking on a pop or pops URI: it is done in a POP client application that has some configuration about security preferences.

> > - 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?

Given that the only well-deployed protocol that does *not* have two ports is SMTP, and given how poorly that has gone, the best practice seems like a second port. I don't believe that will always be true; I can envision an IESG that says "you cannot run that without TLS, you only get one port and you have to define how to use TLS", but that has not happened yet.

>  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?

We do not have any such infrastrucure yet (although we will be discussing getting that started in the websec WG next week). Thus, this draft in WG LC cannot assume that such infrastructure will be in place in time to prevent security issues from its requirements. That's why I put in the "reserve a bunch of ports that are easy to watch and allow that reservation to change later" section of my proposal.

> > - 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.

The code path for foo-on-a-second-port is "Start TLS; if it returns true, go forwards; otherwise stop". The code path for foo-with-upgrade has significantly more branches, as RFC 3207 shows.

> > - 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.

If a protocol developer is forced to use one port but doesn't want to do TLS, they pretty much have to reinvent it. It is much easier to say "no security on port x, just do TLS on port y".

> > - The number of new application protocols created over the past decade is significantly lower than was expected.
>
>By whose measure?

Hallway wisdom. Non-scientific scanning for "IANA" and "port" in the past 3000 RFCs. Reports at Apps Area meetings. In the heady days of 2000, many people thought at apps would bloom like wildflowers; turns out nearly all of those are running on port 80.

--Paul Hoffman, Director
--VPN Consortium