On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <cont...@simonbernard.eu> 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) > > > 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 ? > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
