Subject: Re: [saag] Should security requirements be MUST?

From: Joe Touch <[email-masked]>
Date: Sun, 1 Jul 2012 23:00:05 -0700

On Jun 30, 2012, at 5:18 AM, Alan DeKok <[email-masked]> wrote:

> Joe Touch wrote:
>> It would be useful to know if that actually sent packets on the wire
>> (not in-memory measurements),
> 
>  If your best counter-argument is to assume I'm a complete idiot, that
> explains why your tests only get 50Mbps.

1500 byte blocks, measured per core, and that was IP level.

>  For more reality-based counter-arguments, see the "high performance
> SSH" patches.  They're also getting better than 900Mbps with crypto on
> commodity hardware.

8 cores, different alg (CTR, not CBC, which is weaker), and 8 kb blocks at the "app" level, not 1500.

That won't protect TCP.  To do that, you need to encrypt at the block of a TCP or IP packet, which is a lot costlier.  And burning 8 cores is a lot more costly than one $10 crypto chip, and prevents use of outboard TCP and IP hardware assist.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 1 Jul 2012 23:04:19 -0700

On Jun 29, 2012, at 5:43 PM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> On Jun 29, 2012, at 17:11, Joe Touch <[email-masked]> wrote:
> 
>> 
>> 
>> On 6/29/2012 5:00 PM, Alan DeKok wrote:
>>> Joe Touch wrote:
>>>> My last graphed measurements of this were in an NPSEC 2006 paper, and
>>>> show that an entire Xeon CPU (within noise of current ones) gets around
>>>> 50Mbps at 100% load.
>>> 
>>>  Well... I've measured commodity systems doing 940+ Mbps with AES-256.
>>> This is in the last 4 months, using 2 year-old systems, and 1.5K packets.
>> 
>> It would be useful to know if that actually sent packets on the wire (not in-memory measurements), and if so, how much of your CPU was gone in the process.
>> 
>>>  If you need crypto acceleration to fill a 1G pipe, then your system
>>> has less CPU power than my iPhone.
>> 
>> Your iPhone certainly can't run anywhere this fast.
> 
> You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the hardware encryption chip (if there even is one)

And background processes too, since iOS 4.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 05:57:00 -0700

> And background processes too, since iOS 4.

iOS background processes are very sharply limited in terms of
how much resources they can consume.

http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html

About the only one of these cases that would allow you to do
high-speed encryption is voice/video, but video in the background
doesn't make sense and video in the foreground means nobody
else should be doing fast encryption.

Really, I'm finding it pretty hard to believe we're still having this
userland versus kernel debate in 2012. The market has spoken
and userland cryptography won. That was clear back in 1999.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jul 2012 11:05:17 -0500

> and userland cryptography won. That was clear back in 1999.

Agreed; user-land cryptographic protocols won long ago, and I'd say
they won with SSL 2.0, so, really, long, long ago.  There are
exceptions though, such as distributed filesystems, which usually are
implemented in kernel mode such that session crypto also happens in
kernel mode.  Also, there do exist kernel-mode HTTPS implementations
(e.g., Solaris has one), though I think that exists primarily to take
better advantage of crypto co-processors -- a thing of the past
really, as crypto instructions like AES-NI proliferate in new CPUs.
IPsec would have to have had APIs and all that in 1995 for this to
have turned out differently; it didn't.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 02 Jul 2012 11:49:49 -0500

On 07/02/2012 01:00 AM, Joe Touch wrote:
>
> That won't protect TCP.  To do that, you need to encrypt at the block
> of a TCP or IP packet, which is a lot costlier.  And burning 8 cores
> is a lot more costly than one $10 crypto chip, and prevents use of
> outboard TCP and IP hardware assist.

I'm not convinced that userland code is incapable of benefiting from 
crypto hardware.

* Userland code benefits greatly from GPU acceleration hardware. 
Graphics applications (e.g. 3D games) have similar latency requirements 
to networking and far higher bus bandwidth requirements.

* OpenSSL is a userland library that includes hooks for supported crypto 
hardware.

* MS CryptoAPI has installable crypto providers.

* OpenBSD has long exposed kernel crypto drivers to userland code.

* On Intel and AMD chips that support them, AES-NI instructions are 
available from userland code.

* It's true that most apps build upon TCP support provided by the 
kernel, but most kernels provide some degree of raw socket capability to 
allow for userland TCP stacks in cases where it makes a difference.

- Marsh

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 09:50:01 -0700

On 7/2/2012 9:05 AM, Nico Williams wrote:
> they won with SSL 2.0, so, really, long, long ago.

App-layer.

Where they won, they won because they allowed half the connection to not 
authenticate. BTNS was all about trying to get that benefit for 
protocols like IPsec, that were wound too tightly around a "one size 
fits all" approach, IMO.

And they won for consumer transactions. Secure tunnels can't operate 
efficiently in user-space without defeating outboard transport, network, 
and link protocol support.

Off-loading for IPsec is still supported both by hardware and OSes, esp. 
for cloud computing:
http://www.intel.com/support/network/adapter/pro100/sb/CS-030515.htm?wapkw=ipsec

And it's still supported in line-card hardware for routers too, of course.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 09:51:17 -0700

> else should be doing fast encryption.

VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or 
PPTP tunnel.

Part of the restriction in iOS is precisely because of the lack of 
hardware support for efficient offloading - vs., e.g., audio playback 
which is supported in that way.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 09:53:00 -0700

> allow for userland TCP stacks in cases where it makes a difference.

The problem is that userland crypto interferes with offloaded TCP and 
IP. Once an egress packet leaves main memory, you don't want to pull it 
back in to do crypto.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:01:30 -0700

On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch <[email-masked]> wrote:
>>>> You realize that an iPhone only allows one foreground process so it
>>>> hardly matters if it doesn't share the hardware encryption chip (if there
>>>> even is one)
>>>
>>>
> VoIP, or basically *any* networking (Pandora, e.g.) over an IPsec or PPTP
> tunnel.
>
> Part of the restriction in iOS is precisely because of the lack of hardware
> support for efficient offloading - vs., e.g., audio playback which is
> supported in that way.

Huh? Do you have any evidence that difficulty of sharing crypto hardware
is a reason for iOS background processing? Like quotes from Apple
or somesuch.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:03:01 -0700

On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch <[email-masked]> wrote:
> authenticate.

No, they won because the people deploying the software wanted to be
able to have it just install on the user's machine without screwing with the
kernel.

> BTNS was all about trying to get that benefit for protocols
> like IPsec, that were wound too tightly around a "one size fits all"
> approach, IMO.
>
> efficiently in user-space without defeating outboard transport, network, and
> link protocol support.

What, you've never heard of an SSL VPN?

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 10:06:49 -0700

> On Mon, Jul 2, 2012 at 9:51 AM, Joe Touch <[email-masked]> wrote:
...
> is a reason for iOS background processing? Like quotes from Apple

For things it is designed to do in background, it has outboard 
processing (phone, music playback).

Apple didn't issue a statement about everything it didn't include in its 
design. The limitations it posts are based on its *current* architecture.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:08:28 -0700

On Mon, Jul 2, 2012 at 10:06 AM, Joe Touch <[email-masked]> wrote:
>>> hardware
> For things it is designed to do in background, it has outboard processing
> (phone, music playback).

There's no hardware acceleration for notifications, for instance, but you can
do them in the background.

> design. The limitations it posts are based on its *current* architecture.

In other words, this is just something you're asserting without evidence.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 10:09:18 -0700

> able to have it just install on the user's machine without screwing with the

SSL is popular because users don't need to buy X.509 certs or register 
with an authority to use it.

Compare, e.g., how popular SSL is vs. another userland security system 
that relies on PKI entries for all users - I don't see the general 
public using PGP.

> What, you've never heard of an SSL VPN?

I've also heard of token ring, but besides the geek community, it's not 
used all that much. The dominant VPNs are IPsec and PPTP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 10:15:03 -0700

> do them in the background.

They're presumably not a persistent load.

> In other words, this is just something you're asserting without evidence.

I gave you evidence - their current architecture dedicates hardware to 
persistent shared or background processes. I'm not saying this is a 
difficulty of sharing crypto hardware, but rather the lack if it in the 
first place.

We're both inferring based on current design and current developer 
recommendations, neither of which state explicitly why they don't have 
crypto offloading in hardware.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:17:55 -0700

On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch <[email-masked]> wrote:
> SSL is popular because users don't need to buy X.509 certs or register with
> an authority to use it.

IPsec could have been run in the same configuration (i.e., with anonymous
clients) if people had wanted to. For instance, one could have used
self-signed certs on the client side.

Seriously, you think Netscape would have shipped a security system that
required you to install a kernel module?

> I've also heard of token ring, but besides the geek community, it's not used
> all that much. The dominant VPNs are IPsec and PPTP.

Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and
why Cisco AnyConnect now supports DTLS.

Look, I'm not making an argument about whether SSL VPN is better or worse
than IPsec VPNs. But the notion that you can't run SSL/TLS fast is just
silly in a world where all of Gmail runs on SSL/TLS. Here's Adam Langley
on the topic: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

"In January this year (2010), Gmail switched to using HTTPS for
everything by default. Previously it had been introduced as an option,
but now all of our users use HTTPS to secure their email between their
browsers and Google, all the time. In order to do this we had to
deploy no additional machines and no special hardware. On our
production frontend machines, SSL/TLS accounts for less than 1% of the
CPU load, less than 10KB of memory per connection and less than 2% of
network overhead. Many people believe that SSL takes a lot of CPU time
and we hope the above numbers (public for the first time) will help to
dispel that."

-Ekr

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 02 Jul 2012 19:20:41 +0200

On 07/02/2012 06:50 PM, Joe Touch wrote:
> efficiently in user-space without defeating outboard transport, 
> network, and link protocol support.
minix3

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 2 Jul 2012 13:23:20 -0400

On Jul 2, 2012, at 1:09 PM, Joe Touch wrote:
> SSL is popular because users don't need to buy X.509 certs or register with an authority to use it.
> 
> Compare, e.g., how popular SSL is vs. another userland security system that relies on PKI entries for all users - I don't see the general public using PGP.
> 
> I've also heard of token ring, but besides the geek community, it's not used all that much. The dominant VPNs are IPsec and PPTP.

I'm aware of multiple enterprise VPNs based on DTLS.  For example:

"
The Cisco AnyConnect VPN Client provides remote users with secure VPN connections to the Cisco ASA 5500 Series Adaptive Security Appliance using the Secure Socket Layer (SSL) protocol and the Datagram TLS (DTLS) protocol. AnyConnect provides remote end users with the benefits of a Cisco SSL VPN client, and supports applications and functions unavailable to a clientless, browser-based SSL VPN connection.

"
<http://www.cisco.com/en/US/products/ps8411/products_qanda_item09186a00809aec31.shtml>

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 10:34:42 -0700

...
> required you to install a kernel module?

They could have shipped with a security system that used an existing 
security kernel module, just like they shipped with a communication 
system that used an existing transport kernel module.

They could also have shipped with modules that used kernel modules 
optionally where present.

> why Cisco AnyConnect now supports DTLS.

 From their pages, these appear to be focused on support for email and 
web access to SSL-based services. E.g., from Cisco's page:

---
SSL VPN Overview

Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from 
almost any Internet-enabled location using only a web browser that 
natively supports SSL encryption. This feature allows your company to 
extend access to its secure enterprise network to any authorized user by 
providing remote-access connectivity to corporate resources from any 
Internet-enabled location.
---

I.e., that's web browser access to services.

> on the topic: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

You can run SSL/TLS fast because
	a) you encrypt over fairly large blocks most of the time (8K+)
	b) many users toss their entire multicore CPU at the problem,
	and don't care

When you either care about your battery or preserving that $500 CPU for 
real work, you want a $10 crypto chip to help.

When you handle messages that are high-speed but small (1500 bytes or 
smaller), you want that chip.

And when you want TCP/IP offloading hardware assist, you *need* a crypto 
chip if you want to protect at the transport or network layer.

If you don't want any of that - which web browser users don't - then 
yes, SSL is fine.

> and we hope the above numbers (public for the first time) will help to

It'd be interesting to understand where their CPU _is_ spending time, 
and what the average CPU's network capacity is. Email is notoriously 
disk-limited as well.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:44:22 -0700

On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <[email-masked]> wrote:
> security kernel module, just like they shipped with a communication system
> that used an existing transport kernel module.

Please do tell: what existing security kernel module was available in
1995 across the entire range of operating systems that people
ran browsers on?

> optionally where present.

What would be the point of that once you already had to absorb the
cost of shipping the crypto?

Look, I was actually involved in building cryptographic software intended
for use by consumers at the time that SSL/TLS was being designed,
and I can assure you that people thought that the need to install a kernel
module (not to mention the cost of developing one for an array of operating
systems) was a huge issue.

You can believe that or not, but really, if you and I have this different views
of the history of this technology, then I don't think there's much more to
say.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 10:50:40 -0700

One more thing.

On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <[email-masked]> wrote:

> When you either care about your battery or preserving that $500 CPU for real
> work, you want a $10 crypto chip to help.
>

This isn't true. Performance of encryption and decryption is nearly linear
in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead
but it is amortized very quickly by message size. See, for instance,
Rescorla, "SSL and TLS", page 199.

Additionally, see Langley again:
"But don't make the records too large either! See the 15KB record that
https://www.bankofamerica.com sent? None of that data can be parsed by
the browser until the whole record has been received. As the
congestion window opens up, those large records tend to span several
windows and so there's an extra round trip of delay before the browser
gets any of that data. Since the browser is pre-parsing the HTML for
subresources, it'll delay discovery and cause more knock-on effects.

So how large should records be? There's always going to be some
uncertainty in that number because the size of the TCP header depends
on the OS and the number of SACK blocks that need to be sent. In the
ideal case, each packet is full and contains exactly one record. Start
with a value of 1415 bytes for a non-padded ciphersuite (like RC4), or
1403 bytes for an AES based ciphersuite and look at the packets which
result from that."

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Mon, 02 Jul 2012 12:52:42 -0500

> system that used an existing transport kernel module.

I'm sorry dude but that's just ridiculous.

If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist 
on many clients.

Netscape shipped SSL 6 months before IPsec was even described for the 
first time in RFC 1825. Of course there were no kernel crypto modules.

Today on a popular platform like MS Windows there are OS-provided crypto 
modules. Some apps use them, some don't. But you can bet if it were a 
significant perf benefit to doing it in kernel mode this optimization 
would have gotten to network programmers. In fact, Windows IIS and Linux 
both have in-kernel http servers but this has everything to do with 
reducing user-kernel mode context switches and nothing to do with crypto 
performance. The only crypto performance issues I ever hear of people 
having on modern hardware is the asymmetric key operations.

And with that, I'm pretty sure this thread has overextended its ability 
to inform.

- Marsh

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 11:00:54 -0700

On 7/2/2012 10:44 AM, Eric Rescorla wrote:
....
> 1995 across the entire range of operating systems that people

IPsec didn't exist, nor did PPTP at the time.

But that was 1995. There have been more than a few releases since then. 
I don't know anyone who's still running 1995 browser software.

> cost of shipping the crypto?

Backup support for services isn't uncommon. Even at the time kernel 
updates were fairly frequent - as frequent as app updates, in some cases 
(e.g., comparing release histories of MacOS, for which minor version 
numbers exist vs patch history, and Netscape).

> systems) was a huge issue.

I recall that too - when you told them it was a kernel module they 
freaked, but those same people updated their OS, or bought new hardware 
fairly regularly anyway. What people complain about and what they do 
anyway aren't always related.

I also recall realizing that SSL got it right regarding keys - which is 
why I brought up BTNS. IPsec is now in everything, including cellphone 
OSes, but it's rarely used except in enterprises, largely because of the 
key distribution issue.

Joe

---

From: <[email-masked]>
Date: Mon, 2 Jul 2012 14:06:21 -0400

> I.e., that's web browser access to services.

That's wrong, sorry.  An SSL VPN provides full IP network extension -
it's most definitely not browser-only.  The technology is effectively IP
encapsulation in TLS, not clever use of TLS to access "SSL-based services."

EMC uses AnyConnect for secure remote access, and it effectively
replaced usage of remote access IPsec VPNs for the entire company.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 11:13:00 -0700

On 7/2/2012 10:50 AM, Eric Rescorla wrote:
> but it is amortized very quickly by message size.

That must be why the high-speed SSL you cite uses 8K blocks, rather than 
something that might correspond better to the TCP packets sent.

 > See, for instance,
> gets any of that data.

Except for the first 3 or so round trips where this matters, ACK 
clocking will prevent this sort of "full RTT delay". The RTTs of delay 
that are seen in these cases are typically from misconfigured Nagle.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Jul 2012 11:16:21 -0700

> If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist

Clearly everything Netscape first shipped with hasn't changed in 17 years.

Oh, and why it's still available.

Things change, and there have been many opportunities to use kernel 
modules over the years. "First out" isn't always the winner (or are you 
all using SGML and Fetch?)

Joe

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 2 Jul 2012 14:24:14 -0400

On Mon, Jul 02, 2012 at 11:16:21AM -0700, Joe Touch wrote:
> modules over the years. "First out" isn't always the winner (or are
> you all using SGML and Fetch?)

Sure, but what it means is that SSL had the first mover advantage.  If
IPSEC was going to displace SSL it would have needed to be
significantly better in terms features, functionality, ease-of-use,
ease-of-deployability, etc.  Unfortunately, the lack of standard API,
the unevenness which OS providers adopted IPSEC, etc., meant that in
the eyes of application developers IPSEC was significantly worse than
SSL, not better.

Yes, today IPSEC support is in most OS's.  And in theory someone could
create a simple, easy to use userspace library which applications
could use, and this API could expose enough information on a per-TCP
connection basis so that a server could make authorization decisions.
(The discussion of whether x.509 certificate names is a wash, given
SSL is also using certificates, so it doesn't matter for the purposes
of this discussion.)  But even supposing all of this work got done,
what's the killer feature that would cause people to want to migrate
to using IPSCEC instead of SSL?

If there isn't one, then even if all of the standards work is done,
adoption will be slow and uneven.  Sort of like the adoption rate of
IPv6 until we actually started running out of IPv4 addresses....

     	      	       	       	       	   - Ted

---

From: Mouse <[email-masked]>
Date: Mon, 2 Jul 2012 14:37:25 -0400 (EDT)

> I'm not convinced that userland code is incapable of benefiting from

In general, "userland code cannot benefit from crypto hardware" is
false.  However, an equally general "userland code can benefit from
crypto hardware" is also false.  There are a whole lot of factors
involved, many of which depend on sufficiently detailed aspects of the
task at hand that we can't really say much more than vague handwaves in
a thread like this.

I was once involved in setting up an OpenVPN tunnel.  The machine had a
crypto accelerator, but using it proved to actually _impair_
performance.  I investigated this and eventually came to the conclusion
that, for that application on that hardware with that OS (all three of
which are important qualifications), the cost of the kernel/user
crossings involved more than outweighed the gain from the crypto
hardware.  Given the application, it couldn't throw more than some
1500 bytes at the crypto chip at once, and it took more like 8K-10K to
actually get a speedup after overhead was taken into account.

Of course, if the crypto accelerator had been accessible without
needing to do a syscall trap...if the application had been able to
throw more than 1½K at the chip at once...if syscall traps had been
cheaper...then the tradeoffs would have been different.  This is why I 
remarked that all the qualifiers I mentioned above were relevant.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2012 11:44:45 -0700

On Jul 2, 2012, at 11:13, Joe Touch <[email-masked]> wrote:

> That must be why the high-speed SSL you cite uses 8K blocks, rather than something that might correspond better to the TCP packets sent.
> 

You must be thinking of someone else.

I've provided you measurements that support what I am saying. Unless you have measurements that show differently I don't think there is much to talk about

Ekr

> Except for the first 3 or so round trips where this matters, ACK clocking will prevent this sort of "full RTT delay". The RTTs of delay that are seen in these cases are typically from misconfigured Nagle.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Jul 2012 15:03:44 -0400

OK, folks, that's enough.

This discussion has gone far, far afield of the original question, and
IMHO no longer addresses any question useful in either the design of
current and future Internet standards or in the writing of the documents
that describe them.

And frankly, I'm getting tired of watching Joe and ekr argue.  I've seen
over 20 messages in this thread in my inbox in the last couple of hours,
and it's getting old.

Please stop.  Please?

-- Jeff

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2012 09:01:33 +0300

A minor remark: The reason why email and Web access is explicitly mentioned because that's what people use when they access their company services (and any other service on the Internet as well). 
 
Of course the SSL / TLS based VPNs could carry other protocols on top of it. 

I am not sure why you say it isn't a clever use of TLS to access "SSL-based services.

On Jul 2, 2012, at 9:06 PM, <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: <[email-masked]>
Date: Tue, 3 Jul 2012 10:03:40 -0400

Hi Hannes,

> A minor remark: The reason why email and Web access is explicitly mentioned
> because that's what people use when they access their company services (and
> any other service on the Internet as well).
> 

And they do ...

> I am not sure why you say it isn't a clever use of TLS to access "SSL-based
> services."

This is because the TLS is in the VPN, not the accessed services.  Obviously,
HTTPS and the like use a second encapsulated instance of TLS, but the primary
TLS is in the SSL VPN, and it doesn't extend to the service.  Specifically,
the TLS server cert presented by the SSL VPN (at least AnyConnect) is an SSL
VPN cert, not a cert from the accessed service - to get the latter requires an
instance of TLS that goes all the way to the service, not just to the SSL VPN
gateway (ok, that was obvious ...).  Hence one can run traffic over an SSL VPN
that is unencrypted on the far side (enterprise network) of the SSL VPN gateway.

Thanks,
--David

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2012 2:02 AM
> To: Black, David
> Cc: Hannes Tschofenig; [email-masked]; [email-masked]
> Subject: Re: [saag] SSL VPN
> 
> A minor remark: The reason why email and Web access is explicitly mentioned
> because that's what people use when they access their company services (and
> any other service on the Internet as well).
> 
> used

---

From: Gregory Lebovitz <[email-masked]>
Date: Sat, 14 Jul 2012 23:09:46 -0700

In line,

> that is unencrypted on the far side (enterprise network) of the SSL VPN

Note: Not all SSL / TLS VPNs are created equally. The Juniper solution, by
default, only uses the TLS connection to authenticate the user and set up a
 control channel. It then pushes down through that TLS connection a SA for
an ESP connection between the host and the gateway, and the rest of the
traffic is sent through the tunnel goes through the ESP. If ESP fails to
get through, as is the case often enough due to in-the-middle firewalls
that don't handle / allow ESP, then the tunnel reverts back to TLS.

The advantages of SSL / TLS over pure IPsec are:
 - no need for explicit software download by IT department in order to make
secure first remote connection; end-user just hits a URL, and the rest
happens from there. This ease of deployment is THE MAIN reason that most
large enterprises ditched pure IKE / IPsec clients and went to SSL VPNs.
 - gets through firewalls and NATs more readily
 - has other modes, non-tunnel-all, so that if the remote user is on a
device where they cannot load software, they can still view email and
browse / download / upload network files
 - the policy is stored and enforced at the gateway, so any changes are
always instantaneous (or immediate upon next connection), and need not be
pushed out to all the remote endpoints.

As I said before, most enterprises have gone the route of SSL VPNs for
remote access. The customers love the stuff.

Hope it helps,
Gregory

> > services.

-- 
----
IETF related email from
Gregory M. Lebovitz