Re: [TLS] DTLS Handshake race condition

mrex@sap.com (Martin Rex) Tue, 13 August 2013 21:42 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 7278521F92C2 for <tls@ietfa.amsl.com>; Tue, 13 Aug 2013 14:42:08 -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 avfknSHhMm5A for <tls@ietfa.amsl.com>; Tue, 13 Aug 2013 14:42:03 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0F821F9344 for <tls@ietf.org>; Tue, 13 Aug 2013 14:42:02 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r7DLg0s5016944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 23:42:00 +0200 (MEST)
In-Reply-To: <18BBEE86-075C-4A2F-B67A-49D5F281DCFE@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Tue, 13 Aug 2013 23:42:00 +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: <20130813214200.B3CAA1A908@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: Tue, 13 Aug 2013 21:42:08 -0000

Michael Tuexen wrote:
> Martin Rex <mrex@sap.com> wrote:
>> 
>> 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.
>
> So this applies also to DTLS.
>
>> 
>>  - 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.
>
> In my scenario the client never receives it, since it is
> * dropped by the network
> * but sort of ACKed by the client by sending the ClientHello and
>   therefore it is never retransmitted.
> So currently, the DTLS connection is stalled until it is taken
> down due to the retransmission timer firing too often...

If HelloRequest changes the DTLS MsgSeqNo, then simply "ignoring it"
seems no longer an option (that it was in TLS).

Ignoring it was really supposed to mean "will not affect state".
MsgSeqNo. looks like state that is relevant to the DTLS handshake
state machine.

In case the server _did_ send a HelloRequest, would glueing/prefixing another
HelloRequest to the front of the HelloVerifyRequest help?

-Martin