Christian Huitema wrote this message on Sun, Aug 02, 2015 at 19:07 +0000:
> On Sunday, August 2, 2015 11:12 AM, David Mazieres wrote:
> > Richard Barnes <[email protected]> writes:
> >
> > > I have a pretty strong preference for (a), the Rescorla draft. New code
> > > is undesirable in security systems -- better to rely on a known,
> > > battle-tested code base. So it seems like a no-brainer to use TLS as the
> > > starting point and making the minimum set of changes needed.
> >
> > There are two problems with this argument, though. First, as already
> > pointed out, you can't just drop openssl into the kernel, so new code
> > will have to be written anyway.
> > ...
> > Well, a priori, one can argue that even though TCP-use-TLS may require
> > more engineering effort in absolute terms than tcpcrypt, the delta
> > between application-level TLS (required anyway) and transport-level TLS
> > is smaller than the effort required for all of tcpcrypt (which can't be
> > shared). However, a posteriori, given that we still don't have a
> > profile and the (still proprietary) implementation took so long to
> > realize, I think there's a good chance that either a) people
> > underestimated the effort required for TCP-use-TLS, or b) nobody cares
> > enough about TCP-use-TLS to do the obvious work.
>
> I too have a strong preference for EKR's draft (a). My main reason is that I
> see TCP INC as a transition technology, deploying opportunistic encryption
> first but evolving quickly to strong encryption with authentication. TLS
> compatibility facilitates that transition. My other reason is that I would
> much rather maintain a single security stack instead of two.
How does tcpcrypto not facilitate the trasition to authentication? It
already has a working OpenSSL modifications that authenticates tcpcrypt
sessions... or are you saying that tcpcrypt does not provide strong
encryption?
> The main argument for TCP Crypt is the cost of implementation. That argument
> rings a bit hollow for a Windows kernel developer, since we have in fact
> access to S-Channel in the Windows kernel. Windows web servers rely on the
> HTTP.SYS kernel driver, which implements TLS using the kernel API for
> S-Channel. HTTP.SYS has been doing that for a long time, so there is indeed
> some experience with that solution.
Microsoft has not talked publicly about the issues they had w/
implementing and securing HTTP.SYS, and they have a full time set of
engineers they can put on the task, other OSS OS's do not have that
luxury.. Though Microsoft does have an implementatio, very little is
known about it, so too much is unknown about it, IMO, to claim that
full TLS in the kernel is doable and safe...
> The other argument for the light weight filter is that the protocol can be
> smaller, and thus easier to verify, debug, or even prove. The protocol may
> indeed be smaller, but the size effect mostly comes from leaving out
> authentication. Without authentication, there is no need for verifying
> certificates. If one leaves certificate negotiation out, TLS is pretty small.
> The next big chunk of complexity comes from algorithm agility, but I fully
> expect that any standardized version of TCP crypt will have to incorporate
> some support for algorithm agility. At that point, we would have two stacks
> to implement, which means twice the attack surface and twice the number of
> potential security bugs.
The TLS-use-TCP protocol also leaves out authentication, so I don't
see any differences here...
I do agree that doing two stacks is counter productive and should not
be done..
> The logical argument that swayed me towards reusing TLS is the evolution
> towards authentication. We want to deploy TCP INC to enable opportunistic
> encryption of old applications that have not yet been upgraded to "Start
> TLS." But we do not want these applications to be stuck at the
> "opportunistic" level. The solution in TCP crypt is to use a channel binding
> API so authentication can be later implemented inside the application. That
> works, but it requires applications to manage secrets, and points to the
> evolution of an enlarged TCP crypt stack that would incorporate
> authentication based on channel binding, and effectively compete with the TLS
> solutions. At that point, the risk of twice the attack surface and twice the
> bugs becomes really concerning, not to mention the confusion of two IETF
> standards to achieve the same thing.
I don't see how TLS avoids the application managing secrets, or are you
talking about a full version of TLS in the kernel, but still the
application still needs to manage the secrets, otherwise how else can
it load them into the kernel?
> The "TLS filter" approach provides a simpler evolution path. System
> administrators first use a system option to insert a TLS shim under
> unprotected applications. In parallel, applications start evolving and adopt
> a way to "Start TLS." We get a transition state in which the TLS layer
> incorporated in an application talks to the shim under an unmodified
> responder. The system administrator initially provision the shim with a
> self-signed certificate, but may upgrade to a regular certificate and provide
> actual authentication. All that looks like a clean evolution.
It's sounds like you view TLS-use-TCP as doing full certificate parsing
and validation in the kernel, is this correct?
TLS-use-TCP still doesn't have a profile.. ekr gave a profile "like"
something today, he isn't committing to it, or even suggesting that
be the profile...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
