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

[Simon Bernard <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>> 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
>
>     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
>     (https://tools.ietf.org/html/rfc4279#section-2
>     <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
>     <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 ?
>
>
> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>