Re: [TLS] Record layer corner cases

Martin Rex <martin.rex@sap.com> Fri, 24 November 2006 01:07 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPXZ-0005no-4K; Thu, 23 Nov 2006 20:07:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPXY-0005na-43 for tls@ietf.org; Thu, 23 Nov 2006 20:07:40 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPXT-0004Ox-Ni for tls@ietf.org; Thu, 23 Nov 2006 20:07:40 -0500
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id CAA18026; Fri, 24 Nov 2006 02:01:09 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200611240101.CAA23300@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Record layer corner cases
To: mike-list@pobox.com
Date: Fri, 24 Nov 2006 02:01:09 +0100
In-Reply-To: <45664015.6000802@pobox.com> from "Mike" at Nov 23, 6 04:43:01 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Mike wrote:
> 
> I clearly misunderstood what you meant, and actually agree that it
> would be good to have one handshake message per record.  Practically,
> though, you will need to support earlier versions for some time.
> Just try to connect to the industry-leading certificate authority
> with TLS 1.0: https://www.verisign.com/ for example.

Talking of VeriSign...

A few years ago, www.verisign.com had been sending out an expired
rootCA certificate in the certification path of the Server, and
curiously, none of the Web Browsers complained when it had a
replacement cert (same Subject&Issuer, same key, longer validity)
in the list of trust anchors.  If the newer local key was
deleted in the browsers list of trust anchors, then the expired
rootCA cert sent by www.verisign.com became visible.

Maybe there should be some guidance, common sense doesn't seem
to be sufficient (it took VeriSign several months to fix it when
I complained to them about their server misconfiguration/misbehaviour).

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls