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

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