On Mon, Nov 27, 2017 at 8:30 AM, Black, David <david.bl...@dell.com> wrote:
> Inline ... > > > 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. > > [David>] I agree with Kyle here. In addition, a new key exchange is > cheaper for tcpcrypt by comparison to TLS (e.g., because tcpcrypt does not > authenticate), so if the properties of a new tcpcrypt key exchange are > wanted, that's what should be done, IMHO. > I'm not sure why you call this the properties of a new key exchange. Non-reuse of keys is a basic property of key establishment schemes. > 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. > > [David>] Hmm - this doesn’t do much for confidentiality with stream > ciphers like AES GCM (the single "MUST implement" cipher for tcpcrypt) , as > if reuse happens, then the attacker XORs the two matching ciphertext > streams yielding an XOR of the plaintext streams in which the first n bytes > of XOR'd nonces can safely be ignored. > > If the intent was that the nonces participate in key derivation, then the > keys would need to be re-derived after the first message following > resumption is received Huh? I think we're talking past each other here. My suggestion was to send a nonce before you send any ciphertext and then derive the traffic keys from ss[i] and the nonce. That's why this only works properly asymmetrically. - it's a better idea to move that key derivation into setting up the TCP > connection for resumption. One consequence of nonce participation in key > derivation is that pre-calculation of resumption keying material prior to > the TCP handshake is no longer possible. I would hope that a one-byte > nonce in each direction will suffice, as the goal is reuse prevention, not > injection of significant new entropy. If significant new entropy is > wanted, start over with a new key exchange, IMHO. > To have strong reuse prevention you need a long enough nonce that you have a low probability of collision. One concern here is that an implementation might have a defect where it improperly erases ss[i] after use, in which case an attacker might repeatedly exercise that defect and thus get key reuse. -Ekr Here's a sketch of one way in which this could be done. First, reduce the > resumption identifier size to 16 bytes from the current 18, and then send 8 > bytes of resumption ID + 1 byte of nonce in each direction for resumption > in place of the current 9 bytes of resumption ID. Those nonces then need > to be folded into the existing tcpcrypt CPRF key generation framework that > takes a 1-byte value in addition to the key. One possibility (feels like > a bit of a hack) is to take the upper half of the current 1-byte CONST > value space for this purpose by forcing the most significant bit of each > nonce to 1, and then running CPRF twice to include both nonces: > ss_a[i] = CPRF(ss[i], nonce_a | 0x80, K_LEN) > ss_ab[i] = CPRF(ss_a[i], nonce_b |0x80, K_LEN) > After this, the master keys, mk[i], are generated from ss_ab[i] instead of > ss[i]. > > The result is 7 bits of nonce in each direction, so 14 bits of reuse > resistance. That seems ok, since reuse is not supposed to happen in the > first place. OTOH, there's no useful anti-replay resistance here, as one > would need much larger nonces for that, so it's good that anti-replay is a > non-goal. However, Kyle's concern about changes to the core protocol > applies to this sort of design, even though it doesn't add a new round-trip. > > > Kyle >
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
