On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > 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 > > I was just wondering if this is what will happen in practice. But I should have separated this consideration (and the next) from the more fundamental point of public vs secret state. > > > 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? > It doesn't. And you don't need a public key for this. If the server rotates the ticket encrypting key often (say each 5 minutes as in the example) then you get the same effect. The point was about which case, g^s or symmetric ticket encryption key will be managed better in practice. I don't have an answer. Hugo > -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
