Re: [TLS] Summarizing identity change discussion so far

<Pasi.Eronen@nokia.com> Wed, 09 December 2009 13:36 UTC

Return-Path: <Pasi.Eronen@nokia.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 2EF9B3A67C2 for <tls@core3.amsl.com>; Wed, 9 Dec 2009 05:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.547
X-Spam-Level:
X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 43ok8JJsvE1d for <tls@core3.amsl.com>; Wed, 9 Dec 2009 05:36:02 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E89633A67E1 for <tls@ietf.org>; Wed, 9 Dec 2009 05:36:01 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB9DZi6s004969; Wed, 9 Dec 2009 15:35:48 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:35:40 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 15:35:35 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 9 Dec 2009 14:35:33 +0100
From: Pasi.Eronen@nokia.com
To: mrex@sap.com
Date: Wed, 09 Dec 2009 14:35:31 +0100
Thread-Topic: [TLS] Summarizing identity change discussion so far
Thread-Index: Acp4IR/RC00VyvXPR36LVBBx023MUQAsWbMA
Message-ID: <808FD6E27AD4884E94820BC333B2DB774F31D24088@NOK-EUMSG-01.mgdnok.nokia.com>
References: <808FD6E27AD4884E94820BC333B2DB774F31D235DE@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Dec 8, 9 02:12:07 pm <200912081611.nB8GBQ8a019273@fs4113.wdf.sap.corp>
In-Reply-To: <200912081611.nB8GBQ8a019273@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Dec 2009 13:35:35.0362 (UTC) FILETIME=[7CAD6A20:01CA78D4]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Summarizing identity change discussion so far
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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, 09 Dec 2009 13:36:03 -0000

Martin Rex wrote:

> When there is some signaling between TLS implementation and application
> (like a callback), and application data that arrives during the
> renegotiation handshake is either dropped or leads to failed hanshake,
> then a change of identity--even for something as "insignificant" as
> a certificate renewal is manageable for the application.
> 
> There are issues in the existing SSL & TLS protocol specs that
> cause a problem for such semantics: (a) the TLS spec explicitly allows
> transfer of application messages interleaved with renegotiation
> handshake messages, and (b) the TLS spec indicates that handshake
> messages have precedence over application data, without saying
> what this means.  Since this precedence is _not_ about processing
> at the record layer (in TLS, all messages must be processed in order),
> so it can only be about delivery to application.  But here, it
> creates a confusion in the wrong direction.  Application data delivered
> interleaved with the renegotiation handshake is protected under the
> original cipher suite and under the original authentication.
> Delaying that data until after authentication seems unreasonable,
> because it would require an additional facility to tell the application
> at what point in the application data stream the identity change
> happened, long after the signaling of the new identity.

Even if application data and handshake messages were not interleaved
over-the-wire, the application could still be confused.

Let's assume some application data arrives just before the handshake
(no interleaving over-the-wire); the TLS library reads it, decrypts
it, and stores it in a buffer.  But then the handshake starts before
the application had a chance to read the data from the buffer (perhaps
it's busy doing some else).  After the handshake is done, the APIs
may not really tell the application when exactly the data arrived...

(This situation doesn't necessarily occur in all TLS libraries, and
may depend on what the APIs look like, how threads are used, etc...)

Best regards,
Pasi
(not wearing any hats)