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:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: Freitag, 6. April 2018 19:27 To: Simon Bernard <cont...@simonbernard.eu> Cc: tls@ietf.org Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <mailto: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 mailto:TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
