On Fri, Nov 24, 2017 at 1:33 PM, Eric Rescorla <e...@rtfm.com> wrote: > Well, there are (at least) two other options: > > 1. You could simply accept the extra round trip and send nonces in both > directions, as you do for the non-resumption handshake. That would be > the most straighforward approach, and arguably the best one.
Whether this is acceptable to mandate or not really depends on the goals of session resumption. If the goal is simply to save compute resources for key exchange, then this seems like a reasonable change to make; but if the goal is to drive down time-to-first-byte-delivered to no more than a normal TCP connection, then this will negate that advantage, significant especially for lengthy paths. If tcpinc were primarily about confidentiality against active attackers, I think I'd come down on the side of safety against bad implementations; but, as the primary goal of tcpinc is to prevent pervasive passive surveillance, I think the balance tips the other way: to favor performance over misuse tolerance. I also agree with David Black that I feel like there's a lot of scope creep here: frankly, I'm not comfortable making substantive changes to the core protocol without doing another WGLC. > 2. As I mentioned in my original note, you could have implementations > send a nonce in their sending direction before the first byte of ciphertext. > This isn't as good because you don't get anti-replay, but I *believe* > that it would provide strong defense against keying material reuse, > which seems like the most immediate threat. This may be the best compromise: it provides a measure of misuse tolerance within the existing performance constraints. Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
