Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

[Marsh Ray <[e-mail]>]

On 11/08/2010 03:07 AM, Paul Hoffman wrote:
>
> "some security issues": See the long Security Considerations section
> on RFC 3207.

Hmmm, yes, the little matter of the downgrade attack.

"Other than that, Mrs. Lincoln, how did you like the play?" :-P

> "be complexer to implement than using two ports": See the state
> machine described in section 4 and its subsections in RFC 3207.
> That's much more complex than "OK, let's go".
>
> "thus less popular": Developers would like fewer code paths and more
> failure states.

It's a decision that ends up in the hands of the admin anyway. Admins 
are already maintaining the ACLs on their firewall.

What are the advantages of running different versions of a protocol 
(having radically different security properties) on the same vs. 
different TCP ports?

As I see it, running on different ports has some advantages:

* Developers don't have to implement and test protocol support for some 
negotiation scheme.

* Developers don't have to code support for configuration

* Admins don't have to learn more configuration, site security doesn't 
depend as much on the perfection of sendmail.cf.

* Admins can look at their firewall rules, use wireshark and 
telnet-level test tools to gain confidence that they have blocked off 
unencrypted traffic.

* Passive network monitoring tools can't observe a STARTTLS handshakes 
and conclude that there is not still a vulnerability to downgrade. 
Testing tools which can prove the absence of a STARTTLS downgrade 
vulnerability are likely to be complex and not fully conclusive (perhaps 
it could even depend on complex mail delivery rules).


Running on the same port has some advantages:

* It saves a port number allocation.

* It may be compatible with some existing firewall rules.


I think a secure-only port number is the superior solution for many 
reasons. The ability to reliably block insecure connections based on 
looking only at the TCP/IP header is a powerful thing.


> At 6:46 PM +1300 11/8/10, Peter Gutmann wrote:
>> About a year after the initial STARTTLS spec was published, I and a
>> few other security geeks did some informal surveys of mail being
>> processed at a couple of large sites and found that STARTTLS, after
>> a year, was securing more mail than all other email encryption
>> protocols combined, and that was a decade ago.

That's great. Did you test resistance to downgrade attacks?

Should we only be concerned with passive eavesdropping? If so, then 
consider how much higher adoption could have been if the specs had 
endorsed anon-anon DH connections such that there was no need for admins 
to set up certificates for their mail servers before deploying encryption.

>> So, what research or figures is the above claim, that STARTTLS is
>> less popular than using port 465, based on?
>
> STARTTLS in POP and IMAP is much less popular than POP and IMAP on a
> second port for TLS.

FWIW, Mozilla Thunderbird seems to try STARTTLS first. But their scheme 
is hardly a gold standard:  http://extendedsubset.com/?p=22

Security is obtained only when both endpoints refuse to exchange 
meaningful data (or engage in any forwardable authentication scheme) 
until a mutually authenticated and encrypted channel has been 
established. So IMHO, that should be the default configuration setting 
and the starting point for the discussion.

 From there we can negotiate downwards, but we should recognize that 
it's the game of "My data (and perhaps even my authentication 
credentials) hold little enough value that an attacker will probably not 
go to the trouble of an active attack. I hope."

- Marsh