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

Eric Rescorla <ekr@networkresonance.com> Fri, 15 August 2008 02:03 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 1ECED3A6A79; Thu, 14 Aug 2008 19:03:44 -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 508003A69FE for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 19:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.263
X-Spam-Level:
X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 RMTffY3wv9gy for <tcpm@core3.amsl.com>; Thu, 14 Aug 2008 19:03:41 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 93A2C3A69C4 for <tcpm@ietf.org>; Thu, 14 Aug 2008 19:03:41 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id 46406539CB0; Thu, 14 Aug 2008 19:03:46 -0700 (PDT)
Date: Thu, 14 Aug 2008 19:03:45 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Adam Langley" <agl@imperialviolet.org>
In-Reply-To: <396556a20808141635s43981c99g301065585f22127c@mail.gmail.com>
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>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080815020346.46406539CB0@kilo.rtfm.com>
Cc: 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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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.
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