Re: [tcpinc] Revised version of TCP-ENO

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Thu, 13 August 2015 23:42 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77C51ACEEF for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 16:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level:
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmmNOP-HhpIY for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 16:42:27 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0561ACEEE for <tcpinc@ietf.org>; Thu, 13 Aug 2015 16:42:27 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost.scs.stanford.edu [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id t7DNgQoV005782; Thu, 13 Aug 2015 16:42:26 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id t7DNgQ8e014272; Thu, 13 Aug 2015 16:42:26 -0700 (PDT)
X-Authentication-Warning: market.scs.stanford.edu: dm set sender to dm-list-tcpcrypt@scs.stanford.edu using -f
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Martin Thomson <martin.thomson@gmail.com>
In-Reply-To: <CABkgnnUF-byT2MH8mrmZJaMY2PTsspWJ8W3wJmddXdgMqGHCkQ@mail.gmail.com>
References: <87pp2vqplu.fsf@ta.scs.stanford.edu> <CAJU8_nXAHhf6dqqs0gUEGz49bG7YUO1qaGwaLm04+vstPTyfWg@mail.gmail.com> <87h9o4rqwz.fsf@ta.scs.stanford.edu> <874mk2kj56.fsf@alice.fifthhorseman.net> <CAJU8_nVcDmCw-0KYviJ5GWZL+-YcCg3wLMJqpkuh=iN8RppA+A@mail.gmail.com> <87y4hej2vf.fsf@alice.fifthhorseman.net> <87egj67sac.fsf@ta.scs.stanford.edu> <87bnea7rr6.fsf@ta.scs.stanford.edu> <CABkgnnUF-byT2MH8mrmZJaMY2PTsspWJ8W3wJmddXdgMqGHCkQ@mail.gmail.com>
Date: Thu, 13 Aug 2015 16:42:26 -0700
Message-ID: <87614i7o2l.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/k9rJUm3mxW9GueWnRkJFjc3PkAk>
Cc: tcpinc <tcpinc@ietf.org>
Subject: Re: [tcpinc] Revised version of TCP-ENO
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2015 23:42:28 -0000

Martin Thomson <martin.thomson@gmail.com> writes:

> On 13 August 2015 at 15:22, David Mazieres
> <dm-list-tcpcrypt@scs.stanford.edu> 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 is what will matter
> here.  As long as two session IDs are indistinguishable from each
> other, I think that we're OK.

Well, currently the first byte is the particular encryption spec you are
using, and the length of the whole thing is also dependent on the spec.
That's of course open to debate, but currently we can't require any two
session IDs to be indistinguishable.  More fundamentally, though,
comparing session IDs with each other will lead to a much more
complicated security definition for a property that's much harder to use
in other proofs.

Given that specs will almost certainly be generating the session ID from
a PRF like HKDF anyway, why do we need to allow lower-entropy session
IDs?

David