Re: [tcpm] SYN/ACK Payloads, draft 01

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Fri, 15 August 2008 07:14 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9593A67D2; Fri, 15 Aug 2008 00:14:34 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA5E3A6819 for <tcpm@core3.amsl.com>; Fri, 15 Aug 2008 00:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.038
X-Spam-Level: **
X-Spam-Status: No, score=2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQbOv9yHV+Vl for <tcpm@core3.amsl.com>; Fri, 15 Aug 2008 00:14:33 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 70F9B3A6403 for <tcpm@ietf.org>; Fri, 15 Aug 2008 00:14:32 -0700 (PDT)
Received: from [192.168.1.15] (p508FD8D4.dip.t-dialin.net [80.143.216.212]) by mail-n.franken.de (Postfix) with ESMTP id 847231C0C0BCE; Fri, 15 Aug 2008 09:14:32 +0200 (CEST)
Message-Id: <9AA6852B-C938-41A3-BFE0-0D150E9EB4AB@lurchi.franken.de>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
To: Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20080815020346.46406539CB0@kilo.rtfm.com>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Fri, 15 Aug 2008 09:14:31 +0200
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <48A465CC.8000402@isi.edu> <396556a20808141023s3abddc96u43b9e6e7898033ed@mail.gmail.com> <48A46BD3.4030408@isi.edu> <396556a20808141303k341599wfeef32d0841e9f76@mail.gmail.com> <48A491B9.3000209@isi.edu> <396556a20808141325u1e67c93co595eadeb3341539@mail.gmail.com> <48A4975D.3070303@isi.edu> <396556a20808141401of8ad149w5850e8dc552a9948@mail.gmail.com> <78C9135A3D2ECE4B8162EBDCE82CAD770417B23A@nekter> <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com> <20080815020346.46406539CB0@kilo.rtfm.com>
X-Mailer: Apple Mail (2.926)
Cc: Adam Langley <agl@imperialviolet.org>, tcpm@ietf.org, Caitlin Bestler <Caitlin.Bestler@neterion.com>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Aug 15, 2008, at 4:03 AM, Eric Rescorla wrote:

> At Thu, 14 Aug 2008 16:35:47 -0700,
> Adam Langley wrote:
>>
>> On Thu, Aug 14, 2008 at 3:44 PM, Caitlin Bestler
>> <Caitlin.Bestler@neterion.com> wrote:
>>> So there *is* rationale for doing this at the transport layer.  
>>> Whether
>>> there is *sufficient* rationale is subject to debate. My key  
>>> reservation
>>> remains that this breaks a fundamental concept of TCP. Instead of  
>>> the
>>> TCP payload being "a stream of bytes" it is now "an optional banner
>>> message sent only when the peer's TCP options indicate it can be
>>> parsed followed by a stream of bytes".
>>
>> Just to correct one point - the banners are still seen as part of the
>> stream of bytes by both ends. The option communicates a single bit,
>> out of band, to both ends. I think that's the problem.
>>
>> So it looks like the concenous for this is pretty thin.
>>
>> (Un)fortunately, I'm persistant as hell, so I shall consider what
>> other avenues I have. I still firmly believe that a world with
>> opportunistic encryption would be a better world than we have now.
>
> I believe this too. But there are lots of ways to get opportunistic
> encryption that don't involve screwing with TCP. For starters,
> there could simply be a header that said "You can use TLS to
> talk to me as well" and supporting clients could redirect.
In SCTP, RFC 5061, there is a features called 'Adaptation Layer  
Indication',
which could be used to signal this kind of information during the
handshake...
>
> The rationale for this mechanism is opportunistic encryption PLUS
> lower latency than currently offered by TLS. It's the second
> piece you haven't made the case for.
>
> -Ekr
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm