Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

[Daniel B Giffin <[e-mail]>]

Thanks for the review, Adam ...

Adam Roach wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for a well-written document. I have some suggestions for improvement
> (two minor, and one significant).
> 
> This document has several references to tables that are quite distant from the
> table being referenced. It might be useful to readers if these were phrased
> something like "Table 4 in section 7," so they know where to go looking for the
> table.

Good idea.  I've gone and added the section to all table
references.

> Section 3.5 says:
> 
>    If an active opener receives a resumption suboption for a particular
>    TEP and the received identifier-half does not match the "resume[i]"
>    value whose other half it previously sent in a resumption suboption
>    for the same TEP, it MUST ignore that suboption.  In the typical case
>    that this was the only ENO suboption received, this means the host
>    MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more
>    ENO options and MUST NOT encrypt the connection.
> 
> I think the text here would benefit from pointing out that the client MUST NOT
> attempt to resume a session with this host for the next TCP connection attempt.

Is your concern that these two peers can get "stuck" in a
state where they repeatedly fail a mutual attempt at
resumption, thus forever falling back to no encryption?

In the case of a hash-collision of resumption identifiers,
it seems we don't get stuck because the active opener will
advance to the next session secret on the next connection:

	When proposing resumption, the active opener MUST use the lowest value
	of `i` that has not already been used (successfully or not) to
	negotiate resumption with the same host and for the same pre-session
	key `ss[0]`.

Maybe you're seeing a different problem?

> ____
> 
> Section 3.6 stipulates:
> 
[truncate]

(I've responded to this concern in a separate thread.)

daniel