On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote:
> > > On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <s...@sn3rd.com> wrote: > >> All, >> >> To make sure we’ve got a clear way forward coming out of our BA sessions, >> we need to make sure there’s consensus on a couple of outstanding issues. >> So... >> >> 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, > > > I am not offering an opinion about what the WG should decide regarding > keeping > DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that > the > above claim "The security properties of PSK-based 0-RTT and DHE-based > 0-RTT are > almost identical" is not quite right (nothing I say here is new, I just > felt > that I had to "object" to this statement as written). > > There are some significant differences - in some cases even "fundamental > differences" - between keeping secret state (in the PSK case) and keeping > non-secret state (in the DHE case) or even not keeping state at all (in the > DHE case) and retrieving the server key g^s from some external source (with > integrity but not secrecy). In addition, using DHE 0-RTT would require the > client to send a key share g^x leading to a PFS 1-RTT exchange while with > PSK > it may be "tempting" to omit PFS. > The current plan of record is to allow the server to specify which cipher suites it is willing to accept, so it could refuse this Moreover, if the server's configuration > key g^s is refreshed often (say each 5 minutes) then the g^xs key used by > the > client to protect its 0-RTT data already has some good level of forward > secrecy (the attacker has a 5 minute window to find s and after that > forward > security is guaranteed). The latter point touches on an important aspect > which is the key management complexity of ticket encryption/decryption keys > (as needed in the PSK case) vs managing secret DH key s (in the DHE case). > I am not sure what would be done better (more secure) in practice. > Can you expand on the difference here? Say that the server implements tickets by storing a DH private key and then encrypting the ticket under the corresponding public key. How does this provide different PFS properties? -Ekr > But really it seems that the discussion boils down to identifying cases of > enough interest where avoiding the original 1-RTT trip for establishing a > session ticket is important. I am puzzled by the fact that the Google team > seems ok with something that essentially voids the main feature and design > basis of of QUIC. > > Hugo > > > >> 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. >> >> If you think that we should keep DHE-based 0-RTT please indicate so now >> and provide your rationale. >> >> J&S >> >> _______________________________________________ >> 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
