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

[Kyle Rose <[e-mail]>]

On Mon, Nov 27, 2017 at 11:11 PM, Daniel B Giffin <[e-mail]> wrote:
> Whether or not we decide to go back to the WG to discuss the
> mechanics of session resumption, we could make lightweight
> changes to the current protocol in this last call that would
> facilitate any "upgrades" that appear necessary after
> deployment has begun.
>
> To wit, we propose:
>
>   - Replace the first byte of INIT1_MAGIC and INIT2_MAGIC
>     with a "version" byte.  Implementations of the current
>     protocol must send a zero version-byte, and must ignore
>     what they receive.
>
>   - When receiving ENO suboptions for tcpcrypt TEPs with
>     v=1, which are "resumption suboptions": if the
>     resumption identifier-half is not the expected length
>     (9 bytes), treat this suboption as a bare TEP byte with
>     v=0; that is, an invitation to fresh key-exchange with
>     that TEP.  This *almost* goes without saying; the
>     current draft doesn't say what to do in this case of
>     "malformatted" resumption identifiers.

Upon reflection, isn't this an oversight? It seems the draft should
address this regardless of how we decide to deal with misuse
tolerance.

> The version byte is intended to allow implementations of
> future protocol versions to identify each other (by sending
> the highest version they support), which then allows them to
> perform "advanced" resumption signaling later.

So is the idea that the format of INIT*_MAGIC would be fixed, and that
the version can only affect subsequent messages? I suppose the
alternative is that we burn a new set of TEPs whenever anything about
the protocol changes, so putting that extensibility directly into
tcpcrypt (where a much less constrained number of signaling bits are
available) makes sense for future proofing, maybe even irrespective of
this particular issue. I'm thinking of some analogy to ClientHello
extensions in TLS, where you can send stuff that the server might not
parse, and that's okay. 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?

Kyle