I have reviewed the latest version of this document. This appears to address most of the points in my discuss. A few more comments below.
When a frame is received, tcpcrypt reconstructs the associated data and frame ID values (the former contains only data sent in the clear, and the latter is implicit in the TCP stream), computes the nonce "N" as above, and provides these and the ciphertext value to the AEAD decryption operation. The output of this operation is either a plaintext value "P" or the special symbol FAIL. In the latter case, the implementation SHOULD abort the connection and raise an error condition distinct from the end-of-file condition. But if none of the TCP segment(s) containing the frame have been acknowledged and retransmission could potentially result in a valid frame, an implementation MAY instead drop these segments (and "renege" if they have been SACKed, according to [RFC2018] Section 8). Looking through this again, why is this the right guidance? It seems like: 1. You shouldn't ACK data that you can't verify, because it's confusing to the other side. This seems like one of the arguments for tcpcrypt rather than protocols that run over top of TCP. 2. You would get better resistance to connection failure if you instead decrypted packets and then ACKed. Is the situation that sometimes you have to ACK? I haven't thought this through. Perhaps you should recommend against ACKing if you don't have to. I also notice you don't require checking that the result of the X25519 function is nonzero. We hve been requiring this in other IETF protocols. the number of past connections that are vulnerable. Of course, placing private keys in persistent storage introduces severe risks that they will not be destroyed reliably and in a timely fashion, and SHOULD be avoided at all costs. This seems a bit over the top. Either it's this serious and you need a MUST, or it's not this serious, and you should tone it down. To meet that ideal, it might appear natural to also mandate ECDHE using P-256, as this scheme is well-studied, widely implemented, and sufficiently different from the Curve25519-based scheme that it is unlikely they will both suffer from a single (non-quantum) cryptanalytic advance. I'm not sure how persuasive this argument is. Wouldn't an efficient discrete log algorithm in generic groups affect both of these functions. As far as I know, it's not known that no such algorithm exists. -Ekr On Tue, Nov 28, 2017 at 2:55 PM Kyle Rose <kr...@krose.org> wrote: > On Tue, Nov 28, 2017 at 5:38 PM, Daniel B Giffin <d...@scs.stanford.edu> > wrote: > > Yes. It makes sense that whenever you send a TEP identifier > > (by itself or for resumption, even if you use some > > yet-unspecified resumption-request format), you are willing > > to do fresh key exchange with that TEP. Thus I have added > > this to section 3.5. Session Resumption: > > > > If a passive opener receives an ENO suboption with a TEP identifier > > and "v = 1", but the suboption data does not have length 9 bytes, it > > MUST behave as if the same TEP had been sent with "v = 0". That is, > > the suboption MUST be interpreted as an offer to negotiate fresh key > > exchange with that TEP. > > Right, I was just pointing out that we want to keep this change even > if we decide not to make further changes to resumption at this time. > > >> Do we want an extra frame in/after the INIT > >> messages for sending version-specific data on the first flight that > >> old receiver versions will simply ignore (beyond including it in the > >> handshake transcript), to avoid an extra RTT for version negotiation? > > > > Because the new "version" byte would be the first byte sent > > in each direction, it can be used to negotiate any future > > protocol behavior to follow that byte. > > You need both because you need to know that the INIT message you send > will be accepted by the receiver before you know which version(s) it > supports (i.e., on the first flight). That said, I had forgotten that > the protocol already has this property, as you pointed out: > > > Even without the version byte, the Init1/Init2 messages > > already reserve trailing space for future uses, which > > implementations of the current protocol are instructed to > > ignore (although it is always part of the transcript). > > If we decide to make use of that space in a future version, we'll need > to come up with a structure with intrinsic backward compatibility for > version fallback... but that's a conversation for another time. :-) > > Kyle >
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
