Re: [TLS] Problem with DTLS 1.2 handshake

Yes, I am talking about the TLS record MAC.

In my case this was happening because of a misconfiguration on the PSK.  When we finally figured out that this was a MAC error on the record, then we immediately looked at the values of the PSK knowing that this was the most likely failure.  The fact that in the main handshake this leads to a large amount of retries by the client I am not sure that this is just a slower failure detection.  I agree that this is less of an issue for a simple rotate the keys problem.  I am slightly worried about having the same problem on a re-negotiation though.

Jim

From: Eric Rescorla <ekr@rtfm.com> 
Sent: Monday, March 26, 2018 6:24 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Problem with DTLS 1.2 handshake

First, just for clarification, you mean the TLS record MAC on the Finished

rather than the TLS Finished MAC, right?

Assuming that is correct, then I believe this is reasonable behavior. It

makes the protocol somewhat more resistant to damaged bits on the wire.

Note that QUIC takes this position even further: every packet is integrity

protected (the initial packets use a key based on the CID). The primary

consequence of this is slower failure detection, but the kind of case you're

talking about primarily happens when there is an implementation error,

so not much in the field anyway.

-Ekr

On Mon, Mar 26, 2018 at 6:09 AM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

I appear to have run across an implementation that does not appear to
violate the specification, but which in my opinion is just plain wrong.

I am doing a handshake with PSK.  On the second flight from the client it
sends

[ChangeCipherSpec]
Finished

The server sees that the ChangeCipherSpec occurs and moves to use the keys.
It then attempts to validate the MAC on the Finished message and silently
ignores the Finish message because the MAC is incorrect and the text says
that it is legal to ignore packets which have a bad MAC.  This means that my
client re-sends the same flight to the server on and on because it never
gets a response and assumes that the packet must be getting lost in transit.

The document does not say that ignoring of bad MACs does not apply until the
Finished message is received and processed.  I am not sure, but I believe
the document needs to say that one cannot ignore a failed MAC on the first
block of data in any epoch and must error on those messages.

I have not looked to see if this is an issue for DTLS 1.3, but it could
easily be.

Jim

_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org> 
https://www.ietf.org/mailman/listinfo/tls