[TLS] [DTLS]: how to handle unknown identity and bad psk ?

Simon Bernard <contact@simonbernard.eu> Fri, 06 April 2018 17:16 UTC

Return-Path: <contact@simonbernard.eu>
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 7BBD112025C for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 10:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dx77KSi2WPN for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 10:16:33 -0700 (PDT)
Received: from 8.mo2.mail-out.ovh.net (8.mo2.mail-out.ovh.net [188.165.52.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44C41200C5 for <tls@ietf.org>; Fri, 6 Apr 2018 10:16:32 -0700 (PDT)
Received: from player692.ha.ovh.net (unknown [10.109.122.73]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id BE80C12A8B4 for <tls@ietf.org>; Fri, 6 Apr 2018 19:16:30 +0200 (CEST)
Received: from [192.168.0.16] (rng31-1-88-168-248-146.fbx.proxad.net [88.168.248.146]) (Authenticated sender: contact@simonbernard.eu) by player692.ha.ovh.net (Postfix) with ESMTPSA id 0448460009D for <tls@ietf.org>; Fri, 6 Apr 2018 19:16:29 +0200 (CEST)
From: Simon Bernard <contact@simonbernard.eu>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <e36279ab-2ac7-3ab6-a1b6-d1fac2b0aa79@simonbernard.eu>
Date: Fri, 06 Apr 2018 19:16:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 12352810830315141361
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrgeekgdduudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3sXyPNowGI1zn3qwTQr7ZWhIBMI>
Subject: [TLS] [DTLS]: how to handle unknown identity and bad psk ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 Apr 2018 17:16:35 -0000

Hi,

We are implementing DTLS with PSK over UDP and I would like to know how 
"unknown identity" and "bad psk" should be handled

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)

 >   If the server does not recognize the PSK identity, it MAY respond
 >   with an "unknown_psk_identity" alert message. Alternatively, if the
 >   server wishes to hide the fact that the PSK identity was not known,
 >   it MAY continue the protocol as if the PSK identity existed but the
 >   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7

 >   In general, invalid records
 >   SHOULD be silently discarded, thus preserving the association;
 >   however, an error MAY be logged for diagnostic purposes.
 >   Implementations which choose to generate an alert instead, MUST
 >   generate fatal level alerts to avoid attacks where the attacker
 >   repeatedly probes the implementation to see how it responds to
 >   various types of error.  Note that if DTLS is run over UDP, then any
 >   implementation which does this will be extremely susceptible to
 >   denial-of-service (DoS) attacks because UDP forgery is so easy.
 >   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even 
HANDSHAKE(22) record (and so FINISHED message) or is it mainly for 
APPLICATION_DATA(23) record ?

Is it acceptable to send fatal alert "decrypt_error" in DTLS or should 
we just ignore bad credentials silently ?

--
Simon