On Sat, Nov 11, 2017 at 11:12 AM, Eric Rescorla <e...@rtfm.com> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > https://mozphab-ietf.devsvcdev.mozaws.net/D3970 > > 2^64 bytes in the underlying TCP datastream (which would cause the > "offset" field to wrap) before re-keying. > > In TLS and other WGs, we have adopted the practice of > salting the nonce with a secret per-connection value to avoid > large-scale surveillance attacks. Why did you opt to use a weaker > construction. See: > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#security-record-layer > and https://eprint.iacr.org/2016/564.
I think I need some clarification on the point here. From the relevant passage in the TLS 1.3 draft: q( In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing the sequence number with a secret per-connection initialization vector derived along with the traffic keys. See [BT16] for analysis of this construction. ) What is the situation, commonly the case for HTTP, in which different users would be using the same key for encryption? > FIN flag set, it MUST immediately send a frame (with empty > application data if necessary) with "rekey = 1". > > I don't think that the algorithm in this section > necessarily works properly, because you have to handle rekeys in > sequence: > > Frame 1 [0:999] > Frame 2 [1000:1999, rekey=1] > Frame 3 [2000:2999, rekey=1] > > Now what happens if the frames are re-ordered so you get Frame 3 and > then Frame 2. You will try to decrypt Frame 3 with generation 2 and > Frame 2 with generation 3, neither of which will work (though you > might be able to interpret the text loosely to have you try to decrypt > Frame 2 with generation 2). Note that if you were to resequence before > processing, this wouldn't happen. > > At minimum I think some clarification is needed here. I'm confused. The byte stream will be delivered in-order via TCP sequence semantics, so receiving frames (TLV within the TCP bytestream) out-of-order should not be possible. If a MitM reordered the frames, the receiver would either drop the frame or close the connection following a failure to authenticate upon decryption: q( In the latter case, the implementation MUST either drop the TCP segment(s) containing the frame or abort the connection; but if it aborts, the implementation MUST raise an error condition distinct from the end-of-file condition. ) > Given that you are allowing P-256 and point reuse, you > should be requiring point validation. See: > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.4.2.8.2 > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#elliptic-curve-diffie-hellman > > You should probably also be requiring Curve25519 output validation. Agreed. > You still seem to need to specify an MTI symmetric algorithm. Daniel noted this in his October 25 email, but you are right: I can't seem to find it in the latest draft, either. Did that change get lost? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > The design of session resumption here essentially precludes doing > tcpcrypt resumption across servers (as one does with TLS) because you > need extremely tight control of ss[i] or you have catastrophic > results. Was this a deliberate choice by the WG? The idea of doing something more ticket-like was discussed, but David pointed out (in the thread here: https://www.ietf.org/mail-archive/web/tcpinc/current/msg00919.html) that tickets might not meet the charter mandate for forward secrecy. I don't recall discussing the implications of mismanaging ss[i], but I'll defer to Daniel on that point. Same goes for the following: > session resumption such that a given pre-session key "ss[0]" is only > used for either passive or active opens at the same host, not both. > This seems like it probably needs some more emphasis, as failure to follow > this > instruction results in GCM compromise. ... > It would probably be useful to explain why you opted for this design rather > than having nonces, which would remove the need for such strict ss[i] > management. I assume the reason is that you want to save the round trip? > > connection; but if it aborts, the implementation MUST raise an error > condition distinct from the end-of-file condition. > > Note that this interacts badly with the rekey issue I raise below. > format", and MUST accept values encoded in "compressed", > "uncompressed" or "hybrid" formats. > > Why are you allowing multiple formats here? Generally, if you're going to > encourage compressed, you want to just require it. I'm not sure what the justification here was, so I'd be happy with mandating compressed values if it simplifies the receiver's logic. Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
