On Wed, Oct 21, 2015 at 10:32:59AM -0700, Eric Rescorla wrote: > > It seems natural to try to merge these mechanisms, but this raises > the question of whether the handshake hashes should continue through > the rejection exchange (https://github.com/tlswg/tls13-spec/issues/104). > The tension here is that you want to be able to have a stateless > rejection (to avoid DoS in the DTLS scenario) but having things > makes it much harder to analyze the handshake's resistance to > downgrade attacks.
> Because the handshake hash is continued through the entire handshake, > it's much easier to analyze the downgrade properties. It is not just resistance to downgrade on protocol level. It is also resistance to downgrade at implementation level. Which is nastier to analyze. (I found three different ways[1] to potentially cause downgrades against careless implementaions, continuing hashes stops all of those). > If this sounds good to people, I'll work up a PR for this, but > really all it is is saying that you don't reset the hash and > then a non-normative appendix describing stateless implementation > techniques. > > Thoughts? Does anyone see anything wrong with this? Sounds good to me. Combines the resistance to downgrade continuing hashes offers with the possibility of being stateless (for DTLS). Aside: Has anyone looked at making DTLS 1.3? I would think the main issue to look at would be how to arrange retransmissions (especially with things like 0-RTT data, encrypted handshake and final handshake flight). [1] 1) Tamper with ClientHello so server generates HRR causing the client to downgrade. 2) Tamper with HRR to cause the client to downgrade. 3) Insert ClientHello causing server to latch weak parameters, eat the HRR and replay ClientHello. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
