On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <cont...@simonbernard.eu>

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


> Simon
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
TLS mailing list

Reply via email to