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

From: Simon Bernard <[email-masked]>
Date: Fri, 6 Apr 2018 19:16:23 +0200

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Apr 2018 10:26:34 -0700

On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <[email-masked]>
wrote:

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

-Ekr

--
> Simon
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Mon, 9 Apr 2018 08:09:33 +0000

Hi,

> RFC6347, 4.1.2.7. Handling Invalid Records
> …
> In general, invalid records SHOULD be silently discarded, thus preserving the association;

During a handshake only the new association will be affected and therefore no (current) association could be preserved with silently discarding records. So I can't see, what benefit would be achieved applying the general rule to the handshakes also.

> RFC6347, 4.2. The DTLS Handshake Protocol
> DTLS uses all of the same handshake messages and flows as TLS, with
> three principal changes:
> ...
> With these exceptions, the DTLS message formats, flows, and logic are
> the same as those of TLS 1.2.

> RFC5246, 7.2.2. Error Alerts
> Error handling in the TLS Handshake protocol is very simple. When an
> error is detected, the detecting party sends a message to the other
> party.

So, if no alerts should be used during the handshake, I would prefer to have that mentioned as "forth principal change" in 4.2.

FMPOV, the main advice for the handshake-alerts should be, that they MUST be used with care, not to provide details, which may be used for an attack, and that handshake-alerts MAY not be used at all.

Mit freundlichen Grüßen / Best regards 

Achim Kraus

(INST/ECS4) 
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com 

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Freitag, 6. April 2018 19:27
To: Simon Bernard <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?

On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <mailto:[email-masked]> wrote:
Hi,

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

But in DTLS :

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

-Ekr

--
Simon

mailto:[email-masked]

---

From: Simon Bernard <[email-masked]>
Date: Thu, 26 Apr 2018 11:31:32 +0200

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.

Simon

Le 06/04/2018 à 19:26, Eric Rescorla a écrit :
>
>
> On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     We are implementing DTLS with PSK over UDP and I would like to
>     know how "unknown identity" and "bad psk" should be handled
>
>     (https://tools.ietf.org/html/rfc4279#section-2
>     <https://tools.ietf.org/html/rfc4279#section-2>)
>
>     <https://tools.ietf.org/html/rfc6347#section-4.1.2.7>
>
>     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.
>
> -Ekr
>
>     --
>     Simon
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 26 Apr 2018 09:58:10 -0700

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.

Jim

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

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.

Simon

 

On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

But in DTLS :

Hi  Simon,

-Ekr

--
Simon