Re: [Cfrg] tcpinc: endpoint authentication and session ID privacy

[Kyle Rose <[e-mail]>]

Apologies for the 6-week RTT. Now that I'm stuck on a 14 hour flight, I
finally have some time to get through the email backlog.

On Sat, Oct 1, 2016 at 1:16 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sat, Oct 01, 2016 at 12:31:31PM -0400, Kyle Rose wrote:
> > No: a session ID is to be used on one connection only, with a key
> > derivation algorithm used by both hosts on secret IKM to derive future
> IDs
> > for session caching/reuse. See sections 3.3-3.4 of the tcpcrypt draft for
> > more information on how these identifiers are derived.
>
> I tried reading the relevant sections, and noticed that if SID[i], for
> i>0 gets disclosed, one can correlate the resumption attempt.
>

Not quite sure what you mean here. SID[i] is defined as

SID[i] = CPRF (ss[i], CONST_SESSID, K_LEN)

where ss[i] is secret for all i, ss[i] chains off ss[i-1], and where ss[i]
is used as the IKM for further key derivation within the connection
identified by SID[i]: in particular, I think I'm claiming that there's no
computation that gets you from SID[a] to SID[b] for a != b. Depending on
CPRF, they may or may not be indistinguishable from random to an observer
without knowledge of the inputs, but they should have no correlation with
each other. So if you reveal SID[a] in one resumption attempt and then
SID[b] in a different resumption attempt, that by itself shouldn't help an
observer correlate the attempts.


> But I presume that the SID value used for identifying the connection is
> SID[0].
>

A client is supposed to use a particular SID[i] for resumption once only,
and then advance to SID[i+1] for the next resumption attempt; and both the
client and the server should securely erase ss[i] from memory once it is
used to resume a session on a connection so SID[i] cannot be used for
subsequent resumption attempts.


> Also, the computation formula for PRK has concatenations. One needs to
> be careful with concatenations: The components must be uniquely
> parseable from concatenation.
>

Agreed. We think tcpcrypt is okay on this front. In particular:

(1) eno-transcript is uniquely parseable despite being of variable length
because it incorporates the length via the TCP option length byte, as noted
in section 4.8 of the TCP-ENO draft.

(2) Init1 and Init2 similarly incorporate the message length.

(3) The length of ES doesn't matter given its placement at the end of the
input, and while its structure is kex alg-specific, any collision here
could occur only if bytes earlier in the input corresponded to a different
kex alg: IOW, for a given kex algorithm, it will uniquely parse.

Kyle