IETF Logo Mail Archive

Re: [tcpinc] Revised version of TCP-ENO

"Everhart, Craig" <Craig.Everhart@netapp.com> Thu, 13 August 2015 21:37 UTC

Return-Path: <Craig.Everhart@netapp.com>
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 037FA1B3B44 for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 14:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lFhA2yt4VU6x for <tcpinc@ietfa.amsl.com>; Thu, 13 Aug 2015 14:37:24 -0700 (PDT)
Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71F61B3B39 for <tcpinc@ietf.org>; Thu, 13 Aug 2015 14:37:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.15,672,1432623600"; d="scan'208";a="63028146"
Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx141-out.netapp.com with ESMTP; 13 Aug 2015 14:37:06 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 13 Aug 2015 14:37:04 -0700
Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::6d5f:5aa0:85e2:441%21]) with mapi id 15.00.1076.000; Thu, 13 Aug 2015 14:37:04 -0700
From: "Everhart, Craig" <Craig.Everhart@netapp.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Kyle Rose <krose@krose.org>
Thread-Topic: [tcpinc] Revised version of TCP-ENO
Thread-Index: AQHQ02p7EZ5XDEweHUCLe7igLyj+rp4H0daAgAG1CQCAAVsEgIAABDwAgAAGCwD//7+pgA==
Date: Thu, 13 Aug 2015 21:37:04 +0000
Message-ID: <D1F285AF.96DC4%Craig.Everhart@netapp.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>
In-Reply-To: <87y4hej2vf.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.4.150722
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.122.56.79]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EE64D7759959F743A523A778A4FEACDB@hq.netapp.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpinc/AJq8RLH-52xnDWIN89z52Se9_3U>
Cc: "tcpinc@ietf.org" <tcpinc@ietf.org>, David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
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 21:37:25 -0000

On 8/13/15, 5:27 PM, "Tcpinc on behalf of Daniel Kahn Gillmor"
<tcpinc-bounces@ietf.org on behalf of dkg@fifthhorseman.net> 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 will happen by an
>cryptographic public-key signature over the session id.  In this case, i
>agree that the session id could be published without a problem.
>
>But this isn't necessarily the only mechanism that could be used to
>authenticate the peer.

I was looking forward to sending something like an HMAC of the signature
value, myself.

		Craig

v2.23.0 | Report a Bug | By Email