Suggested behavior change for DTLS implementation

[jimsch]

In trying to do some interop testing on a different project, I was part of a group which did not seem to be able to type PSKs correctly. This caused what I consider to be very poor behavior when my implementation interacted with the Californium version of DTLS. The change requested is that the first encrypted packet not be silently dropped on the floor, but instead a fatal alert be sent back to the client implementation.

What happens is, the client sends a change cipher suite and finish message to the server. The server process the CSS message and then the finish message fails to decrypt so it is silently ignored. The client times out and says that the UDP messages must have gotten lost and resends the CSS and finish message. The CSS message is ignored as already processed, the finish message fails to decrypt and is silently ignored. Rinse and repeat until the client gets tired and decides that the server is dead.

If the finish message is fataled rather than ignored, there is a small possibility that message corruption would cause a fatal to happen, but this is more than offset by the fact that it is now really easy to say - oh the PSK may be wrong let me re-check things. As soon as Ludwig debugged things enough to say that the message was dropped because of a decrypt error I immediately correctly diagnosed the problem.

I have been informed by the powers that be that you behavior is perfectly correct and acceptable. I just think that it is not friendly behavior as the client will not resend the timed out message to the server until the end of time.

[boaks]

Maybe, you comment on issue #606 :-)

[boaks]

I think #606 is the right issue, to discus his topic.
If you agree, please close this one.

[jimsch]

Conversation is happening on #606 - close as dup