> That said, one could imagine a fringe use case where an application
> wants to prove that two anonymous TCP connections belong to the same two
> processes, in which case the session ID of the first connection might be
> used as a MAC key to authenticate the session ID of the second. So you
> don
>> What is the meaning of "first valid spec identifier"? This allowance
>> for multiple spec identifiers sent by host B makes sense if the chosen
>> spec is "the first spec identifier also among those spec identifiers
>> that host A sent",
>
> That is the intent. In other words, if A and B have mu
Ted Hardie writes:
>> That said, one could imagine a fringe use case where an application
>> wants to prove that two anonymous TCP connections belong to the same two
>> processes, in which case the session ID of the first connection might be
>> used as a MAC key to authenticate the session ID of
Martin Thomson writes:
> On 13 August 2015 at 15:22, David Mazieres
> wrote:
>>
>> * Unless and until applications disclose information about the session
>> ID, all but the first byte MUST be computationally indistinguishable
>> from random bytes to a network eavesdropper.
>
>
> Don't call o
Martin Thomson wrote:
> On 13 August 2015 at 15:22, David Mazieres
> wrote:
> >
> > * Unless and until applications disclose information about the session
> > ID, all but the first byte MUST be computationally indistinguishable
> > from random bytes to a network eavesdropper.
>
>
> Don't cal
On 13 August 2015 at 15:22, David Mazieres
wrote:
>
> * Unless and until applications disclose information about the session
> ID, all but the first byte MUST be computationally indistinguishable
> from random bytes to a network eavesdropper.
Don't call out the first byte. The whole thing i
David Mazieres writes:
> * Specs should assume the session ID will be made public and ensure
> that it contains no confidential data (such as data permitting the
> derivation of session keys).
>
> * However, unless the application at either end of a connection
> takes st
On Thu, Aug 13, 2015 at 3:11 PM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> Daniel Kahn Gillmor writes:
>
> > On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
>
> That said, one could imagine a fringe use case where an application
> wants to prove that two anonymous TCP connec
Daniel Kahn Gillmor writes:
> On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
>> This can't be the case if, for instance, the session IDs are signed in
>> batches as proposed in the tcpcrypt paper.
>
> You seem to be assuming that peer authentication will happen by an
> cryptographic public-ke
On 8/13/15, 5:27 PM, "Tcpinc on behalf of Daniel Kahn Gillmor"
wrote:
>On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
>> This can't be the case if, for instance, the session IDs are signed in
>> batches as proposed in the tcpcrypt paper.
>
>You seem to be assuming that peer authentication wil
On Thu 2015-08-13 17:05:38 -0400, Kyle Rose wrote:
> This can't be the case if, for instance, the session IDs are signed in
> batches as proposed in the tcpcrypt paper.
You seem to be assuming that peer authentication will happen by an
cryptographic public-key signature over the session id. In th
> We almost certainly want endpoints/applications to treat the session ID
> as sensitive information -- leaked knowledge of the session ID would
> allow someone to impersonate the other party if any authentication was
> bootstrapped off of the session ID.
>
> The point of the text David highlights
On Wed 2015-08-12 20:08:28 -0400, David Mazieres wrote:
> Kyle Rose writes:
>> 4.1: Do you want to add the additional requirement that session IDs be
>> public, i.e., not be secret to endpoints/applications?
>
> This was the intent of the following bullet in section 4.1:
>
>o The session ID M
13 matches
Mail list logo
