Re:Secure Socket API: POSIX socket API as a vehicle for a si...
by tialaramex on Friday August 17, 2018 @03:22PM
(#17785104)
The feature you linked only handles the symmetric crypto.
TLS and other protocols in this space do very little public key crypto, during a "handshake" phase when they also check everybody is agreed about how the protocol will work and set other parameters, they pick symmetric keys (often two each, it could just one each, and it might be more) and then most of the actual content is handled with just symmetric encryption.
The handshake phase is complicated, whereas the symmetric crypto is very simple. There's also a bunch more policy decisions in the handshake phase, and the Linux kernel tries not to do policy. For example, when your browser connects to a site and there's a problem it often has an "override" feature you can use to connect anyway, if the policy deciding whether to allow connections was in the kernel... too bad?
However this "SSA" does almost everything on the kernel side, at least from the point of view of the application.
It also, and I can't tell how serious they were about this, says it offers the just published TLS 1.3 including 0RTT.
In a way TLS 1.3 is simpler than previous versions, so that makes sense, but it does also add some brand new twists, and more cautious implementations (e.g. in Chrome) don't do 0RTT while they wait to decide how to approach it since it has exciting security properties.
This paper takes those exciting properties a bit more casually than I'm comfortable with. What's _supposed_ to happen here is that protocols on top of TLS (e.g. HTTPS) figure out whether 0RTT is something they'll handle and if so how best to do so. What's definitely NOT safe is to just go "Eh, who cares?" and do 0RTT but treat it the same as the non-0RTT case silently.
TLS and other protocols in this space do very little public key crypto, during a "handshake" phase when they also check everybody is agreed about how the protocol will work and set other parameters, they pick symmetric keys (often two each, it could just one each, and it might be more) and then most of the actual content is handled with just symmetric encryption.
The handshake phase is complicated, whereas the symmetric crypto is very simple. There's also a bunch more policy decisions in the handshake phase, and the Linux kernel tries not to do policy. For example, when your browser connects to a site and there's a problem it often has an "override" feature you can use to connect anyway, if the policy deciding whether to allow connections was in the kernel... too bad?
However this "SSA" does almost everything on the kernel side, at least from the point of view of the application.
It also, and I can't tell how serious they were about this, says it offers the just published TLS 1.3 including 0RTT.
In a way TLS 1.3 is simpler than previous versions, so that makes sense, but it does also add some brand new twists, and more cautious implementations (e.g. in Chrome) don't do 0RTT while they wait to decide how to approach it since it has exciting security properties.
This paper takes those exciting properties a bit more casually than I'm comfortable with. What's _supposed_ to happen here is that protocols on top of TLS (e.g. HTTPS) figure out whether 0RTT is something they'll handle and if so how best to do so. What's definitely NOT safe is to just go "Eh, who cares?" and do 0RTT but treat it the same as the non-0RTT case silently.