On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang <w...@google.com> wrote:
> On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <s...@sn3rd.com> wrote: > > > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT > mode > > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT > > are almost identical, but 0-RTT PSK has better performance properties and > > is simpler to specify and implement. Note that this does not permanently > > preclude supporting DHE-based 0-RTT in a future extension, but it would > > not be in the initial TLS 1.3 RFC. > > This will remove a feature from the QUIC protocol, so I'd be > interested in hearing the QUIC team's opinion. > I agree that this would be valuable. Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm > not sure if "simplier to specify" should be an important factor. > However, "simpler to implement" is an important consideration. I am > curious to know how we concluded that 0-RTT PSK is simpler to > implement. Did anyone implement both 0-RTT modes and can compare the > difficulties? > We have a prototype 0-RTT PSK implementation and have looked at but not yet implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of doing any 0-RTT is the bulk of the additional effort, but that if you have PSK already, which you probably want for ordinary resumption, then the incremental cost of 0-RTT with PSK is less than with DHE. As for 0-RTT PSK having better performance, that comes at the cost of > a previous full handshake with the server. Yes, this is correct. However, that's the current design of 0-RTT DHE in TLS 1.3 as well. > Also, TLS 1.3 clients that > want to do 0-RTT PSK across an application shutdown will need to deal > with the harder problem of storing PSKs persistently. > Yes, that's the major delta. -Ekr > > Wan-Teh Chang > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
