Re: [TLS] Justification

Martin Rex <mrex@sap.com> Wed, 12 May 2010 19:41 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEC63A67B2 for <tls@core3.amsl.com>; Wed, 12 May 2010 12:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.759
X-Spam-Level:
X-Spam-Status: No, score=-7.759 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 Ji4d6HPGMVkr for <tls@core3.amsl.com>; Wed, 12 May 2010 12:41:49 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3857B3A68E7 for <tls@ietf.org>; Wed, 12 May 2010 12:41:39 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4CJfGnG019183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 May 2010 21:41:16 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005121941.o4CJfF0O021613@fs4113.wdf.sap.corp>
To: Nicolas.Williams@oracle.com (Nicolas Williams)
Date: Wed, 12 May 2010 21:41:15 +0200 (MEST)
In-Reply-To: <20100512180814.GI9429@oracle.com> from "Nicolas Williams" at May 12, 10 01:08:14 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Justification
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2010 19:41:50 -0000

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 <mike-list@pobox.com> 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