(Non-conformance) Replying to Invalid Records

[bathooman]

Description

• Type: Non-conformance Bug
• Priority: Minor

---

Non-conformance Bug

Version: development branch

Expected behavior
The DTLS RFC specifies the following requirement regarding the handling invalid records :

Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). 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.

Actual behavior
When TinyDTLS expects a ClientKeyExchange message but instead receives a record with the content type set to ALERT. It responds with a warning-level \dmsg{ALERT} (Close Notify)

I have attached the handshake trace for the mentioned non-conformance.

capture.zip

[boaks]

When TinyDTLS expects a ClientKeyExchange message but instead receives a record with the content type set to ALERT.

FMPOV, there is a difference of "not expected" and "invalid" record, at least according Alert records. Otherwise it would be required to define where in the handshake an alert is possible and where invalid. In my view, that alert is not invalid and so the common alert mechanism applies.

[bathooman]

Thank you for your reply. In this case, however, it's important to note that a ClientKeyExchange message is being interpreted as an Alert, rather than simply receiving an unexpected Alert. Given this behavior, I would consider the message invalid.

[boaks]

Sorry, I can't see your point. Please consider to clarify your view on the IETF TLS mailing list.

[bathooman]

I simply refer to a record that contains a ClientKeyExchange message but the ContentType is set to be Alert instead of Handshake.

[boaks]

Thanks, now I see the misery.

  if (data_length < 2)
    return dtls_alert_fatal_create(DTLS_ALERT_DECODE_ERROR);

must be

  if (data_length != 2)
    return dtls_alert_fatal_create(DTLS_ALERT_DECODE_ERROR);

[bathooman]

This seems to solve the issue. I think we can close this.