Re: Merged Transport Layer Protocol Development

Dan Simon writes:
> 
> >From: 	Tatu Ylonen[SMTP:ylo@ssh.fi]
> >
> >I just wish to say that I also agree that special processing for
> >pre-encrypted data is a Bad Idea.  A 90-MHz Pentium can encrypt fast
> >enought to completely fill an ethernet (the ethernet becomes the
> >limiting factor), and the processing speed is doubling every year.
> >
> >The overhead from encryption is negligible all but the most
> >high-volume servers connected to the Internet by something faster than
> >10Mbits/sec.  (Unless you also do a lot of CPU-intensive processing
> >that competes for CPU.)
> 
> My impression is that asymmetric decryptions of master keys require more
> than enough "CPU-intensive processing" to put CPU time at a premium in
> the typical high-volume secure server.


We seem to have come to an impasse- Tatu's impression vs. Dans.
I'd guess that both are correct for the situations they have in mind.


My suggestion would be that the current spec (SSL3) has
a method already, as someone else has proposed, to
enable sending pre-encrypted data by changing the cipherspec
to RSA_WITH_NULL_SHA or RSA_WITH_NULL_MD5 or
even NULL_WITH_NULL_NULL and sending the pre-encrypted
data unencrypted by the TLS layer.

Yes, if the preencrypted data has been encrypted by something
stronger than TLS offers, and the key is sent via a TLS session, then
the TLS session becomes the weakest part of the link.  I'm not
sure that's really a big problem.  First off, more than one
proposal for TLS-type protocols have included triple-DES
as a symmetric cipher choice.  If I'm not mistaken, triple-DES
is the strongest commonly-available symmetric cipher.  So the
preencrypted data key would, if one used the best possible TLS
ciphertypes, be as secure as the preencrypted data itself.
Secondly, the suggested MAC method to allow some pre-calculation
of the MAC is not as secure as the Krawczyk method used in SSL3
(and I would presume STLP).

So, I'm not sure that sending the pre-encrypted data's key
via TLS is any weaker than the preencrypted data itself, and I do
see a problem with using a weaker MAC method.  On the other hand, SSL
already has a method to deal with preencrypted
data, although it's not as streamlined as some would like.
My opinion would be that the cost of adding more to the protocol
(time spent arguing about it here, plus time taken to comb over
it looking for possible security holes) isn't worth the gains in
this case.  It's worth thinking about later as an addition to
the TLS protocol, but I'd rather see this WG get out something basic
that works soon instead of something complicated later.



-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF

Received on Wednesday, 24 April 1996 23:23:22 UTC