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 <tls-boun...@ietf.org> On Behalf Of Simon Bernard Sent: Thursday, April 26, 2018 2:32 AM To: Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ? 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 <cont...@simonbernard.eu <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 TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
