On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox <waywardg...@google.com> wrote:
> On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind <jimrosk...@gmail.com> wrote: > >> The combination of DHE and TLS 1.3 session resumption via session >> tickets, can destroy the forward secrecy property that DHE was intended to >> provide. With the proposed removal of DHE-based 0-RTT from TLS 1.3, >> session resumption is the mechanism by which 0-RTT connections are >> established. When adopted into QUIC, this will then be a reduction in >> security as compared with the current QUIC Crypto protocol, which rapidly >> steps all connections up to having forward secrecy immediately after a >> 0-RTT connection. >> > > I think I can accurately answer this: just use ephemeral keys during your > resumption handshake. Then only the first flight 0-RTT packets lack PFS, > just like with DHE 0-RTT. > Quite so. TLS 1.3 supports two PSK-resumption modes: 1. Pure PSK, which has somewhat better security properties than in TLS 1.2 2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e., no-PFS for the first flight and PFS for subsequent flights I think it would be good to encourage people to use mode #2, but there are obvious reasons why performance-sensitive implementations might opt for mode #1. -Ekr > Just reiterating a point I think is important: the client needs to know > whether the server has replay protection in this case. It may decide to > use 1-RTT to have full PFS for all application data and real proofs of > possession for client certs, or it might decide to send 0-RTT data in any > case. However, we should advise clients not to send client certs and POST > requests over PSK 0-RTT resumes during the first flight, IMO. I'd like to > see tickets enhanced to enable the server to tell the client whether replay > protection is in place on the server. > > Bill > > _______________________________________________ > 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
