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

Jim Schaad <> Thu, 26 April 2018 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F26D4127863 for <>; Thu, 26 Apr 2018 09:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5F_f-N8ItAFB for <>; Thu, 26 Apr 2018 09:58:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 975D21267BB for <>; Thu, 26 Apr 2018 09:58:19 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 26 Apr 2018 09:55:46 -0700
From: Jim Schaad <>
To: 'Simon Bernard' <>, 'Eric Rescorla' <>
References: <> <> <>
In-Reply-To: <>
Date: Thu, 26 Apr 2018 09:58:10 -0700
Message-ID: <028e01d3dd7f$c38cdc50$4aa694f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028F_01D3DD45.172EC7A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGfAj8TWuI97DkQGLAMwRiwCwdXewEvWvd6Awdw5BqkW0QbsA==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2018 16:58:23 -0000

As a secondary issue related to this.  My client is currently implementing the handshake protocol a little too faithfully to the 1.2 DTLS specification.  Since the client side reliability loop does not have any discussion on deciding that the server has gone dark or is just never going to respond there is an infinite loop that is created.  The client will always do a back off resend of the last set of handshake messages.





From: TLS <> On Behalf Of Simon Bernard
Sent: Thursday, April 26, 2018 2:32 AM
To: Eric Rescorla <>
Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?


Eric, thx a lot for your answer. 

We are discussing a lot about that with our community and there is still no consensus ...

So I come back to you to have clearer information to help us to make the good decision.

Using DTLS with PSK over UDP, without re-negotiation allowed :
- Is there known security issue about sending the same alert for both "unknown identity" and "bad_psk"(invalid record for handshake message) ?

"Discarding records aims to preserve current association", if we are able to preserve current association using :
- no renegotiation allowed,
- send alert for invalid record only for handshake record and if we have an ongoing handshake,
- In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, destroy the existing association only if the client has demonstrated reachability by completing a cookie exchange.

Should it be OK ? 

Thx again for your time.


Le 06/04/2018 à 19:26, Eric Rescorla a écrit :



On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard < <> > wrote:


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 :

>   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 :

>   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 ?


Hi  Simon,


The advice in 4279 is basically "make an unknown identity look like a bad key". So the idea would be to just randomize the key and then get the TLS or DTLS-type behavior. I.e., with TLS you would send decrypt_error and in DTLS the handshake would just stall because you would drop packets.





TLS mailing list <>