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

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