RE: [TLS] compression
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [TLS] compression
It really doesn't provide much practical information - although is mostly correct and excellent, in it own right. It does say in standardese much that was not stated in the implementors/analysts writeup of SSL3, concerning compression and fragmentation/reassembly procedures performed at the SSL Handshake/SSL Record layer boundary. Be aware, that https compression practices are distinct from SSL compression design, understanding that compression is based on the many of the same math principles as type 2 cipher designs, and have many of the same pitfalls when added to packet networking environments.
Perhaps, take your new SSL library, and now apply it to class d addressed applications. Take that code and apply it to the types of streams exchanged between class d addressed applications, and see where it takes you: in the stream-specific compression world, the supprot required of the SSL record layer, the key management, and the socket/API controls.
Never forget that the SSL (and TLS1.0) writeup only ever represented one view of the SSL patent: how to make a lightweight interoperable library, targeting "browsers" and SSL Connection proxies.
> Date: Mon, 27 Nov 2006 16:50:24 +0100
> From: bmoeller at acm.org
> To: mike-list at pobox.com
> Subject: Re: [TLS] compression
> CC: tls at ietf.org
>
> On Mon, Nov 27, 2006 at 07:42:01AM -0800, Mike wrote:
>
> > Are there any specs for standard compression
> > schemes for TLS?
>
> Yes, please take a look at RFC 3749.
>
> Bodo
>
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
Check the weather nationwide with MSN Search Try it now!
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.