[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
- [TLS] [DTLS]: how to handle unknown identity and … Simon Bernard
- Re: [TLS] [DTLS]: how to handle unknown identity … Eric Rescorla
- Re: [TLS] [DTLS]: how to handle unknown identity … Kraus Achim (INST/ECS4)
- Re: [TLS] [DTLS]: how to handle unknown identity … Simon Bernard
- Re: [TLS] [DTLS]: how to handle unknown identity … Jim Schaad