On Fri, Jul 24, 2015 at 7:59 PM, John-Mark Gurney <[email protected]> wrote:
> Eric Rescorla wrote this message on Fri, Jul 24, 2015 at 10:22 +0200: > > > > I've been working on project to accelerate TLS by doing the framing > > > > and encryption work in the kernel, and not in userland. We made the > > > > choice of not moving the handshake and certificate validation into > > > > the kernel due to it's complexity and high risk for bugs. Yes, > > > > tcpcrypt will have slightly more code than just framing and > encryption, > > > > but it's vastly more simple than doing anything wrt parsing and > > > > validating X.509 certificates. > > > > > > > There's not going to be any need to do either of these. I'm working on > > the profile, but expect it to be anonymous (EC)DHE, and so not > > require certificates. > > Well, require and support are two different things. Under chapter 10, > you say: > If some sort of external authentication mechanism was provided or > certificates are used > > This implies that certificates may be used. What is going to happen > if one side decides to require a certificate and the otherside rejects > any certificate use? Then we end up again, back to an unencrypted > session, or worse (better?), failure to establish the session. > > I do realize that ladder diagram does not even mention the Certificate > side of things, so probably the clause, "or certificates", should just > be removed. > > It should be tightened up to explicitly disallow any use of > certificates, or at a minimum, that the side that presents a > certificate but does not receive a correct response, must continue as > if the certificate was ignored. Thanks for your comments. My thinking here is that I would like this mechanism to serve two purposes: 1. To allow for encryption in TCP at the system/kernel level. 2. To let applications discover when TLS is available and upgrade to it In the former case, certificates are not useful but in the latter they are. Perhaps what's needed is an indication in the initial extension handshake of the expectation vis-a-vis authentication -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
