[tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-tcpinc-tcpcrypt-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/



----------------------------------------------------------------------
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.


   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.



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.


You still seem to need to specify an MTI symmetric algorithm.


----------------------------------------------------------------------
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?

   suboption containing the TEP identifier and "v = 0".  In order to
   propose session resumption (described further below) with a
   particular TEP, a host sends a variable-length suboption containing

It would be clearer if you explained resumption here.

          PRK = Extract(N_A, eno-transcript | Init1 | Init2 | ES)
What is the rationale for providing N_A as the salt to HKDF-Extract, given that
you also supply N_A in the Init1 message?

   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.