> RFC6347, 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

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> 

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 :

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

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



TLS mailing list

TLS mailing list

Reply via email to