IETF Logo Mail Archive

[TLS] DTLS lost connection on server side

Hauke Mehrtens <hauke@hauke-m.de> Wed, 21 August 2013 10:54 UTC

Return-Path: <hauke@hauke-m.de>
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 E446211E81FA for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 03:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BFiUHdJ+FwGC for <tls@ietfa.amsl.com>; Wed, 21 Aug 2013 03:54:25 -0700 (PDT)
Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB511E8128 for <tls@ietf.org>; Wed, 21 Aug 2013 03:54:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id A8EEF85EA for <tls@ietf.org>; Wed, 21 Aug 2013 12:54:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at hauke-m.de
Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbuYIvvvZA9U for <tls@ietf.org>; Wed, 21 Aug 2013 12:54:12 +0200 (CEST)
Received: from [IPv6:2001:638:708:30da:b160:a69a:6717:38c5] (unknown [IPv6:2001:638:708:30da:b160:a69a:6717:38c5]) by hauke-m.de (Postfix) with ESMTPSA id 5827C857F for <tls@ietf.org>; Wed, 21 Aug 2013 12:54:12 +0200 (CEST)
Message-ID: <52149C52.9090506@hauke-m.de>
Date: Wed, 21 Aug 2013 12:54:10 +0200
From: Hauke Mehrtens <hauke@hauke-m.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [TLS] DTLS lost connection on server side
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/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: Wed, 21 Aug 2013 10:54:26 -0000

This problem is similar to the problem described in RFC6347 section
4.2.8. Establishing New Associations with Existing Parameters.

We have a DTLS Server S and a DTLS Client C which did a successful
handshake and have an encrypted connection.


1. S looses its state (e.g., after a reboot) and C does not get informed
about that.
2. C send an encrypted application data package to S, because C does not
know that S lost its state and it has some new data.
3. S send a unencrypted fatal unexpected_message alert, because it does
not have any connection with C and is unable to decrypt the message or
encrypt the alert.

What should C now do with this alert?

A: Ignore it, because it thinks it has an encrypted channel with the
other peer.
	Then it will never be able to send a package to the other peer.

B: Handle it and try to do a new DTLS handshake with the peer.
	Now any attacker would be able to reset the connection with just
sending an unencrypted alert.

C: Ignore it and wait till some timeout and do a new handshake.
	It takes some time till the new connection will be established.

Hauke

v2.23.0 | Report a Bug | By Email