Re: [TLS] DTLS Handshake race condition

mrex@sap.com (Martin Rex) Mon, 12 August 2013 18:08 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244C821F9E0A for <tls@ietfa.amsl.com>; Mon, 12 Aug 2013 11:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yToxsf1sbbY7 for <tls@ietfa.amsl.com>; Mon, 12 Aug 2013 11:08:20 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC521F9D8D for <tls@ietf.org>; Mon, 12 Aug 2013 11:08:17 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r7CI8B5W029453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Aug 2013 20:08:11 +0200 (MEST)
In-Reply-To: <A34A16A6-6D79-4A8B-A4A9-CF05B5C4C5F7@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Mon, 12 Aug 2013 20:08:11 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130812180811.779011A8FF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS Handshake race condition
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Mon, 12 Aug 2013 18:08:29 -0000

Michael Tuexen wrote:
> 
> I think the RFC does not cover the race condition I'm referring to...
> What if the HelloRequest(message_seq=0) is lost and the client sends
> a ClientHello(message_seq=0) on its own (since the local user initates
> a re-handshake). The server accepts the ClientHello and responds with
> a ServerHello(message_seq=1). The client however expects a
> ServerHello(message_seq=0), since it never saw the HelloRequest.
> The HelloRequest is also not retransmitted, since the server considers
> it acked by the ClientHello.
> 
> It is only the collision case I'm considering and I think which is
> not covered by the RFC.

Your observation seems correct.

The original TLS handshake is only half duplex.  Properly dealing
with renegotiation is therefore non-trivial.  The original TLS spec
addresses the overlapping of the renegotiation handshake by

  - omitting HelloRequests from the Handshake message hash computation.

  - require the TLS client to ignore any HelloRequests that
    are be received during the handshake (which includes the one
    received after the client has already requested a new handshake
    by sending a ClientHello from your scenario.


Another "grey" area, that may not work particularly well with
some TLS implementations, is what happens if one side requests
a renegotiation while the other is still sending application data.


While the TLS spec itself this should be OK when renegotiation handshake
messages are interleaved with application data, it may not actually
work with all implementations.  Taken to the extreme, with TLS APIs
that perform peer certificate validation in an event-based fashion,
it may open a potential vulnerability (for servers doing delayed
client authentication) when the client starts the renegotiation
handshake, but stops sending handshake messages after the
client's certificate handshake message and then continues sending
application data under the original/enclosing TLS session.


-Martin