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
<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
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
