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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Nov 2010 11:14:35 +0800

TLS experts,

There currently a WG last call ongoing in on the IANA Procedures for the
Management of the Service Name and Transport Protocol Port Number
Registry update document.
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/

A WG last call comment on this document was raised by Paul Hoffman:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg10305.html

My summary of that comment is that STARTTLS for SMTP (RFC 3207) has
shown to have some security issues, be complexer to implement than using
two ports and thus less popular. Thus the registration rules should be
less restrictive in assigning an additional port for TLS version of
services/applications/protocols.

The downside of less restrictive port allocation rules is that the port
space will be consumed at a higher rate. Thus there is need to determine
what is the most suitable trade-off here.

Clearly if the security issues are serious when one multiplex TLS and
non-secured version of the protocol on the same port we must allow such
port allocations. However if the issues are minor and the primarily
issue is implementation complexity then saving the limited port space is
probably more important.

Your input into these questions would be very appreciated.

Thanks

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 07 Nov 2010 20:44:23 -0800

Here's a radical idea for IANA -- STOP REGISTERING UNENCRYPTED PROTOCOLS!

The days of unencrypted anything are nearing an end, so there should be
only one port assigned that uses TLS.  The day is coming when businesses
will be forced to stop sending email that is unencrypted.  Their privacy
policies will demand it.  SMTP will either get a don't_forward_this_
without_encryption option, or it will perish.

Mike

---

From: Geoffrey Keating <[email-masked]>
Date: 08 Nov 2010 11:40:29 -0800

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/
..
> services/applications/protocols.
...
> Your input into these questions would be very appreciated.

There are also security issues when two ports are used: how can an
application choose which port to communicate over?  Paul mentions the
list of security issues in RFC 3207, but each of these corresponds to
a similar issue in a two-port solution.  Eventually the RFC (and
similar specifications of other protocols) comes down to

"The decision about whether acceptable authentication or privacy was
   achieved is made locally, is implementation-dependent, and is
   beyond the scope of this document."

and in practise this leads to at least one, and sometimes more, of these:

1. Implementations which do not interoperate, because one requires
   security and the other does not implement it,

2. Automatically falling back to insecure communications when secure
   communications cannot be achieved, even if this is due to an
   attacker's denial-of-service, or

3. Asking the user questions that the user does not understand or for
   which the user cannot know the answer ("Is example.com supposed to
   have secure email?").

So, I think there are very limited additional concerns for a
single-port approach over a two-port approach, but there are
significant problems with both, and if implementation complexity and
interoperability is a concern it could and probably should be
addressed by specifying that TLS is always used.

---

From: "t.petch" <[email-masked]>
Date: Tue, 9 Nov 2010 12:02:15 +0100

----- Original Message -----
From: "Michael D'Errico" <[email-masked]>
To: "Magnus Westerlund" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>; <[email-masked]>; "tsvwg"
<[email-masked]>
Sent: Monday, November 08, 2010 5:44 AM

<tp>

Michael

Here's a better idea; stop registering encrypted protocols; they are expensive
and damaging
and practically noone needs them, just a few bankers, spies and governments:-)

Of course, authentication is a very different matter, and should be mandatory in
all procotols;
and if encryption allows a bootstrap of authentication, then there is a case for
encryption, otherwise not.

Just a different perspective on the requirements for security:-)

Tom Petch
</tp>

Mike

> Your input into these questions would be very appreciated.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 09 Nov 2010 09:02:29 -0800

> and practically noone needs them, just a few bankers, spies and governments:-)

Since you put a smiley at the end, it seems you're kidding, but just to be
clear....

   - the most important requirement for protocols is integrity; I don't
     know how to achieve that without TLS.

   - personally I also want privacy; not because I'm doing anything wrong,
     but because it's-none-of-your-business what I buy online and what I
     discuss with people through email, etc.  I don't know how to achieve
     this without encryption, thus TLS is an important tool.

   - what do you mean by expensive?  Google has published research results
     showing that enabling TLS on their services required no more/different
     hardware than they were using prior to switching on TLS.

   - also you have it backwards -- government should not be the one doing
     things in secret!

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Nov 2010 11:26:44 -0600

>     know how to achieve that without TLS.

There's the GSS-API...  There's IPsec...  The whole world isn't TLS...
though I think most apps from here on out will trend to using TLS.

(There's also SASL, though the SASL community has decided that new
mechanisms shouldn't have security layers, instead relying on channel
binding to TLS, so SASL doesn't really count :)

>     this without encryption, thus TLS is an important tool.

And also because most web stuff uses cookies to track sessions (the web
app has no visibility into TLS sessions, so it needs its own method for
tracking what connections make up a session), and doesn't use TLS to
authenticate users.  Those cookies need confidentiality protection, even
if you thought that what you do on the web doesn't.

>     hardware than they were using prior to switching on TLS.

Mostly this is a perception issue.  But also it helps to have decent TLS
and HTTP/1.1 implementations, so you can get session resumption, and
pipeline HTTP to amortize the cost of TLS session setup.  Also, not
everyone is Google; I'm not at all surprised that TLS didn't cost them
much, but I'd also not be surprised if TLS-all-the-time cost
significantly more than $0 for most online services not run by Google.

Nico
--

---

From: "t.petch" <[email-masked]>
Date: Tue, 9 Nov 2010 17:28:22 +0100

----- Original Message -----
From: "Michael D'Errico" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 09, 2010 6:02 PM

Michael

Yes there was a smiley but there is also a serious point.

I recently was involved in syslog over TLS and the RFC there explicitly calls it
out.  Diagnostic messages are good for diagnosing problems and so should be sent
in the clear unless there is a reason to do otherwise (eg relating to security
breaches, password misuse etc) and this is a general truth in operations (SNMP
etc).  Yes, I must have integrity, but privacy can be a real pain, stopping the
determination of problems.

And while my Pentium PC, and a Google teraflop server, can cope with most things
(S/MIME as used by our ADs with Apples being the exception for me), network
devices may be low-powered, more like an 8086 than a Pentium, so the cost of
processing encryption can be significant.

And, as a more general truth, the customers I work with are, for the most part,
obsessed with encryption and think that, with that in place, all their security
problems are solved.  In that regard, the widespread use of phishing is
excellent news, because it is finally opening their eyes, in a way I have not
been able to, that unless you have authentication, you are a sucker for
everything.

Just another point of view,

Tom Petch

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 09 Nov 2010 10:20:36 -0800

> There's the GSS-API...  There's IPsec...  The whole world isn't TLS...

I was talking about how I can communicate with, say, amazon.com from home.
GSS-API and IPsec are not options.  TLS is available pretty much everywhere.

Tom is right about constrained devices, but they are getting more and more
powerful every day.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Nov 2010 22:29:46 +0200

> determination of problems.

Nobody is forcing privacy down your throat. Just as IPsec has AH and ESP-NULL, TLS has TLS_RSA_WITH_NULL_SHA256 and TLS_ECDHE_ECDSA_WITH_NULL_SHA among others.

Browsers don't offer this ciphersuite, and for good reason, as Nicolas pointed out. But they may be good for other protocols.

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 09 Nov 2010 12:54:51 -0800

>>>     know how to achieve that without TLS.

S/MIME, anyone?

> Tom is right about constrained devices, but they are getting more and more

Yeah.  If you have a digital electric meter on the side of your house,
odds are good that it does AES-256, SHA-256, ECDSA and ECDHE now.

-- 
/Nelson Bolyard

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Nov 2010 04:57:56 +0800

> Tom is right about constrained devices, but they are getting more and more

I think what we're seeing in the land of constrained devices is the
flipside of Moore's Law: not more powerful devices, but cheaper devices.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bill Frantz <[email-masked]>
Date: Tue, 9 Nov 2010 13:13:42 -0800

On 11/9/10 at 9:26 AM, [email-masked] (Nicolas 

>significantly more than $0 for most online services not run by Google.

Michael - Do you have a pointer to the Google research results?

The figure I heard second-hand from some large non-financial web 
sites that use TLS for logon, but then switch back to HTTP for 
the rest of the session (and thus have been subject to the 
FireSheep plugin) is that keeping TLS on for the whole session 
would increase the size of their server farm by 10%. I find it 
incredible that e.g. RC4 + HMAC would add 10% in this day of 
multi-core, but there you have it.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | OAuth -  It's the best that  | Periwinkle
(408)356-8506      | the wrong way of doing things| 16345 
Englewood Ave
www.pwpconsult.com | can provide. - Mike Stay     | Los Gatos, 
CA 95032

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Nov 2010 15:25:41 -0600

> Michael - Do you have a pointer to the Google research results?

I second that.

> sites that use TLS for logon, but then switch back to HTTP for the
> rest of the session (and thus have been subject to the FireSheep
> plugin) is that keeping TLS on for the whole session would increase
> the size of their server farm by 10%. I find it incredible that e.g.
> RC4 + HMAC would add 10% in this day of multi-core, but there you
> have it.

I suspect the issue is that session resumption is generally not feasible
due to a) lack of implementation of session resumption without
server-side state, b) the need to cluster services making it difficult
to share server-side session resumption state.  Which would mean that
every TLS connection involves public key operations.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 09 Nov 2010 13:43:47 -0800

>> Michael - Do you have a pointer to the Google research results?

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

     "If there's one point that we want to communicate to
      the world, it's that SSL/TLS is not computationally
      expensive any more."

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Nov 2010 22:51:10 +0100 (MET)

Yoav Nir wrote:
> > I recently was involved in syslog over TLS and the RFC there
> > explicitly calls it out.  Diagnostic messages are good for
> > diagnosing problems and so should be sent in the clear unless
> > there is a reason to do otherwise (eg relating to security
> > breaches, password misuse etc) and this is a general truth
> > in operations (SNMP etc).  Yes, I must have integrity, but
> > privacy can be a real pain, stopping the determination of problems.
> 
> Nobody is forcing privacy down your throat. Just as IPsec has
> AH and ESP-NULL, TLS has TLS_RSA_WITH_NULL_SHA256 and
> TLS_ECDHE_ECDSA_WITH_NULL_SHA among others.

There is much more DoS-potential in the server endpoint identification.

If you _can_ prevent syslog entries from being written by messing with
OCSP requests of the client that wants to submit syslog entries,
then you have a vulnerability -- as would be any kind of insistence of
involvement of third parties for a TLS-enabled syslog client.

The popularity of TLS is not that it is good, efficient or secure.
The primary motivator is that implementations are available and
it allows everyone to continue using weak passwords to authenticate
end users (and noone really cares about authenticating servers,
never did).

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 9 Nov 2010 23:55:36 +0200

>     the world, it's that SSL/TLS is not computationally

I don't know if it has been mentioned here already, but Intel has recently released a research about TLS and specifically TLS 1.2 speed as well. They claim to have reached 1 Gbps throughput with a single general purpose core on their Core i7 processor using AES-128 GCM as the cipher and quite high speeds with AES-128 CBC + SHA1 as well. The research paper is somewhat of an Intel advertisement, but demonstrates well the acceleration that modern processors provide for encryption purposes. Computation doesn't seem to be a huge issue here.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 9 Nov 2010 23:58:50 +0200

> I don't know if it has been mentioned here already, but Intel has recently released a research about TLS and specifically TLS 1.2 speed as well. They claim to have reached 1 Gbps throughput with a…

http://ccr.sigcomm.org/online/files/p135_0.pdf

Forgot the actual link to the paper for people interested.

Juho

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Nov 2010 23:03:45 +0100 (MET)

> >>>     know how to achieve that without TLS.

Correct -- CMS/PKCS#7 protection will provide the integrity protection
not only during the network transit, but beyond into backups and archives.

TLS protection applies only during the short moment of network traversal
and once the data is received, no traces from that protection remain,
not even that the data was ever transferred in a protected fashion.

> odds are good that it does AES-256, SHA-256, ECDSA and ECDHE now.

Without support for SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA
and maybe TLS_RSA_WITH_AES_128_CBC_SHA, it might encounter interop problems
with a non-negligible amount of TLS peers...  :-/

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Nov 2010 16:03:06 -0600

On Tue, Nov 09, 2010 at 11:55:36PM +0200, Juho Vähä-Herttua wrote:
> I don't know if it has been mentioned here already, but Intel has
> recently released a research about TLS and specifically TLS 1.2 speed
> as well. They claim to have reached 1 Gbps throughput with a single
> general purpose core on their Core i7 processor using AES-128 GCM as
> the cipher and quite high speeds with AES-128 CBC + SHA1 as well. The
> research paper is somewhat of an Intel advertisement, but demonstrates
> well the acceleration that modern processors provide for encryption
> purposes. Computation doesn't seem to be a huge issue here.

The rate of HTTPS request service with pipelining or session resumption
can be estimated from the above number, but that's not really what's
interesting.  What's interesting is the rate of HTTPS requests served
without pipelining and without session resumption.

(How well supported by browsers is session resumption w/o server-side
state anyways?  Once that gets well enough supported, then we can
declare TLS perf mostly a non-issue.)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 9 Nov 2010 23:39:14 +0100 (MET)

>       the world, it's that SSL/TLS is not computationally

The problem is not that it is computationally expensive, it is the
"TLS tax" imposed by server certs from commercial CAs, their short
lifetime (1year), their non-transferability to other hostnames
(markedroids love to come up with new names every few weeks),
the incompatibility with virtual HTTP hosting (which is significantly
on the rise because of IPv4 addresses shortage) and the additional
help desk impact because of the extremely awful error diagnosis
that common browsers show when encountering network problems
or TLS problems.

SNI doesn't really help, because it is simply not available in ~50%
of the installed base (most of this is Windows XP) and that
number will only gradually decrease in the future.  Most of
the _change_ is from new SNI-capable PCs/notebooks/netbooks 
getting added to the count, much less from the installed 
base getting retired.

The complete absense of reasonable error handling and error
visualization of TLS-enabled software (including web browsers)
to the end users is also a considerable roadblock, substituting
the resolution of TLS-related connectivity issues into random
guessing.  

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 10 Nov 2010 09:29:53 +0100

On 11/09/2010 09:57 PM, Peter Saint-Andre wrote:

>> I was talking about how I can communicate with, say, amazon.com 
>> from home. GSS-API and IPsec are not options.  TLS is available 
>> pretty much everywhere. Tom is right about constrained devices, but
>> they are getting more and more powerful every day.

Don't quite agree. If you check appliances like set-top boxes and DSL
routers you'll see they are as powerful as the state of the art
PC 10-12 years ago. In the old times specific purpose micro-controllers
were used for constrained devices. Nowdays we see general purpose CPUs
(ARM,MIPS - in a form of SoC) being used for almost every constrained
device.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Nov 2010 23:46:17 +0100 (MET)

> hardware than they were using prior to switching on TLS.

They were probably comparing apples and oranges plus their specific
application is absolutely no indicator how much of an impact this
would have on _other_ applications.

When I heard this the first time, I quickly tried searching via
the orange https://www.google.com and immediately noticed the
difference to the Web-2.0 http://www.google.com apple that
ping-pongs every keypress.

> every TLS connection involves public key operations.

For those services that use either a NAT or DNS-A-round-robin load
balancing, TLS session caching might be an issue.  Especially
when clients are still using HTTP 1.0 (i.e. no keep-alive), like
when they're behind a proxy and use HTTP/1.0 by default for proxy
traversal -- which appears to be the default for a certain (huge)
installed base...

Trying to load off server state on the client as a TLS session cookie
might not be a solution for many scenarios, because it is simply not
available in many implementations and the server-side state might
be "huge" whereas the communication frequency and message size
might be tiny -- which easily results in a _magnitude_ higher load
when switching from HTTP to HTTPS.

Another issue might be poor application design -- which is not
necessarily obvious to "apps folks", when the server app is
performing HUGE amounts of small network writes, but didn't
use setsockopt(TCP_NODELAY) -- so that the Nagle algorithm
has been covertly easing the resulting pain for the network.

If such an app or web server plugin is suddenly called over TLS/HTTPS,
the performance impact as well as the increase in network bandwidth
might be even more than the order of one magnitude, because most SSL
APIs will produce SSL records for every single write call.
I've seen that happening -- and was disappointed how painful
and slow the education of application programmers progressed
in paying more attention to such design issues and fixing them.

In the case I encountered, it was a Microsoft IIS plugin producing
a dynamic HTML page full of javascript with context-sensitive contents
of drop-down boxes.  Originally the IIS reply was 97 distinct
SSL records to deliver only 3500 bytes.  After educating the
apps developers and fixing the app, the exact record boundaries
and number of records varied, 25-27 distinct records for 3500 bytes,
a fragmentation that seemed to be caused by IIS itself.

I've recently encountered similarily questionable behaviour
from a smartphone app, where a _picture_ upload to a TLS server
uses SSL records with 1320 bytes max.  That is the kind of
stuff that impacts your server's performance by more than 10%.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 11 Nov 2010 15:05:24 -0800

> when switching from HTTP to HTTPS.

I guess it depends on what you consider "huge."  My server issues
session tickets that are between about 230 and 260 bytes.  If a
client certificate is negotiated, then this figure rises due to
the fact that the certificate needs to be included in the ticket,
but nobody uses them anyway (not trying to start a war :-)

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Nov 2010 00:42:55 +0100 (MET)

> when switching from HTTP to HTTPS.

Btw. there are load balancers that can take the SSL session ID
into account when balancing load and ensure that requests with
the same SSL session ID end up at the same backend server,
which significantly improves the TLS session resume ratio.

When there are certain usage peaks on TLS servers, adequate session
cache size&lifetime management can make a huge difference.

If you have a server running with TLS that is hit by a lot of requests,
you probably want a high percentage of TLS session resumes on those
connections so that you do not max out on the CPU usage because
of the TLS handshakes.

When we had a customer with peak load problems several years ago
with the CPU load of his 8-way server at 90% and fairly disappointing
response times.  I looked at SSL session characteristics
and noticed a poor full-HS/resume ratio (6000:21 in 60 seconds),
indicating that our default session cache size and lifetime were
not adequate for that usage profile and that cache pruning
apparently didn't work (bug).  So I asked the customer to set a
larger tls session cache size and significantly reduce the
session cache lifetime, which resulted in a much better
full-HS/resume ratio (183:9168 in 120 seconds) and the CPU
load of his server dropped back to 15% and the response times
were _much_ better.  On a busy server, a server-side TLS session
cache lifetime in the area of 15-30 minutes is just fine to keep
the CPU load at acceptable levels.

I haven't come around to write a code for an automatic dynamic
cache size&lifetime adjustment depending on the server's
load and usage patterns.  The way how OpenSSL manages cache
lifetime might not be useful for such management, because
rather than session creation time, OpenSSL calculates on session
creation when a session should be expired on current parameters
and only stores that time in the cache.  For dynamic adjustments
when the cache is close to full, I prefer to have cache lifetime
adjustments affect all cache contents immediately based on the
true session age, not just new sessions (for which there is
not much room left).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Nov 2010 04:35:09 +0100 (MET)

> but nobody uses them anyway (not trying to start a war :-)

With such a small session state, *I* would never worry about
offloading.  Unless one is using a very ill-suited load-balancing
technology, the servers should handle such lightweight
TLS session sizes with ease.  (The memory footprint for cached
session in our servers is _MUCH_ larger, and we would rather
shorten the cache lifetime than offloading (and the first choice
for offloading would be some compressed local storage that
works completely independent and for all tls clients anyway). 

I would be very interestend in TLS connection characteritics
and session characteristics (full-HS/resume ration for
numerous combinations of cache sizes and cache lifetimes) 
for Servers where TLS session tickets could make any sense
at all.

When refering to offloading between requests to the client,
I was thinking more about off-loading the _entire_ backend state
along with the TLS session state, which may amount many kilobytes
up to several megabytes.

When you're doing plain HTTP, a reverse-proxy load balancer
can look at the entire request headers to select the correct
backend for the request (so that no backend state needs to
be carried around).  But that option is no longer available
when the entire traffic is TLS-encrypted end-to-end, because
the load-balancer can no longer see the request headers that
it has been using all the time.

Load-balancing based on SSL session ID is not "reliable",
because there is only a likelyhood that it will be reused often,
but no assurance whatsoever that all communication that is
referencing this backend state will use only one single
SSL session ID and remain valid for as long as the backend
state is valid.

So that leaves you with the only option to terminate
the SSL communication with the frontends on the reverse
proxy to be able to look at all of the request headers
again and perform load balancing as before.  Depending
on what software you use and whether you want SSL re-encryption
between reverse proxy and backends, e.g. to perform
"authentication forwarding" of client certs, then
you might encounter performance issues.

Apache as SSL-terminating reverse proxy with SSL-reencryption to the
backend and _default_ configuration used to be a huge performance
problem--no HTTP/1.1 keep-alive combined with no client-side
SSL session caching towards the backend.  And while you can
enable the former (keep-alive) by configuration, client-side
SSL session caching has not been available in the past
(and maybe still isn't) in mod_proxy.

And when the SSL-renecrypted link (using SSL client certs) is
using certs from deep CA-hierarchies with aggressive revocation
options and a similarily aggressive PKI software in the TLS stack,
this can also significantly impair performance.
Some years ago I had a customer seriously suffering with such
certs in use between his BigIP/F5 loadbalancer and our backends.
Looking at the timing between SSL API calls within our
backend for a couple of requests and looking at the certificate
chains of both peers, I suggested him to remove that PKIX-nonsense
from his point-to-point links and the problems disappeared.

-Martin