Re: [TLS] Justification

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Wed, May 12, 2010 at 01:33:08PM -0400, Adam Langley wrote:
> > On Wed, May 12, 2010 at 1:26 PM, Michael D'Errico <[e-mail]> wrote:
> > > What is this three packet limit you speak of?
> > 
> > TCP's initial congestion window is three frames (for now). So a TLS
> > server which needs more than three frames to send ServerHello through
> > to ServerHelloDone will have to wait additional round trips for
> > acknowledgments from the client.
> 
> I think this argues for using URLs for cacheable objects.

Personally, I strongly dislike this idea, just as much as I dislike
the client-cert-url extension and AIA in X.509v3 certs.
It amounts to out-of-band signaling, which creates a magnitude
larger problems than it solves.

Previously, since the original design conveyed the information only
inband, protected and authenticated with an original TLS session
(I dislike the idea of out-of-band-cache-population), the identification
of the cached data did not need a secure strong agile hash.

If the data is conveyed out-of-band, or even completely unprotected,
then we would have to put the secure strong agile hash over the
*real* data back into the protocol, or it'll be a security problem.


The TCP slow start (result of TCP congestion control) issue is actually
an interesting reminder.  I've seen it affecting the TLS handshake
in a different setup, but don't know the exact details.
There seem to be limits on the number of initial TCP segments as
well that can interact badly with the 200ms delayed ACK in
Windows TCP (at least XP).  I've seen it with a server SSL stack
that did _not_ coalesce the handshake Server->Client handshake messages
ServerHello+Certificate(+ServerKeyExchane+CertificateRequest)+ServerHelloDone
into a single TCP segment.


Is it really about "3 packets" or rather the result of a rather small
"TCP maximum segment size" (MSS) resulting in a fragmentation of the
application write into 2+ TCP segments?


-Martin