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

[Kyle Rose <[e-mail]>]

On Tue, Nov 28, 2017 at 5:38 PM, Daniel B Giffin <[e-mail]> 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