Subject: [TLS] Comments on alerts decrytion_failed and bad_record_mac

From: Johannes Hoff <[email-masked]>
Date: Wed, 26 Jan 2005 12:50:39 +0100

In rfc2246-bis-09:
> bad_record_mac
> 	This alert is returned if a record is received with an incorrect
> 	MAC. This alert also MUST be returned if an alert is sent because
> 	a TLSCiphertext decrypted in an invalid way: either it wasn't an
> 	even multiple of the block length, or its padding values, when
> 	checked, weren't correct. This message is always fatal.
>
> decryption_failed
> 	This alert MAY be returned if a TLSCiphertext decrypted in an
> 	invalid way: either it wasn't an even multiple of the block
> 	length, or its padding values, when checked, weren't correct.
> 	This message is always fatal.
> 	NB: Differentiating between bad_record_mac and decryption_failed
> 	alerts may permit certain attacks against CBC mode as used in TLS
> 	[CBCATT]. It is preferable to uniformly use the bad_record_mac
> 	alert to hide the specific type of the error.						
If I understand this correctly, the following situation occur when I discover 
a padding error:
* I MUST send a bad_record_mac alert.
* I MAY also send a decryption_failed alert. (even though it's not 
recommended)

If this is true, it's a great security risks, as it gives very easy access to 
the error channel (as is the point in Vaudenay et.al.'s attack (CRYPTO2003)). 
If a server choose to send both messages, there is a trivial mapping from
* 1 error message -> bad MAC
* 2 error messages -> bad padding or not an even multiple of the block length.

My suggestion would be dropping the decryption_failed code from the standard.

Any comments? Or maybe someone can point out where I misunderstand :)

And a little question on the side: When will TLS1.1 go from a working draft to 
a proper standard?

- Johannes Hoff

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: EKR <[email-masked]>
Date: Wed, 26 Jan 2005 07:07:38 -0800

> * I MAY also send a decryption_failed alert. (even though it's not 
I think this is confusing writing on my part.

You should send EITHER alert, not both.

> My suggestion would be dropping the decryption_failed code from the standard.
I'd prefer to simply deprecate it a bit harder and tighten up this
language.

> And a little question on the side: When will TLS1.1 go from a
> working draft to a proper standard?
We've finished WGLC and should be forwarding it to IESG RSN.

-Ekr

---

From: David Hopwood <[email-masked]>
Date: Wed, 26 Jan 2005 22:16:58 +0000

> the error channel (as is the point in Vaudenay et.al.'s attack (CRYPTO2003)).

A description of the decryption_failed alert should be retained because
previous implementations can generate it, and new implementations must
still be prepared to receive it. I suggest the following wording:

   bad_record_mac
         This alert MUST be returned if a record is received with an
         incorrect MAC, or if a TLSCiphertext decrypted in an invalid way:
         either it wasn't an even multiple of the block length, or its
         padding values, when checked, weren't correct. This message is
         always fatal.

   decryption_failed
         Previous versions of TLS (and SSL) allowed this alert to be
         generated when a TLSCiphertext decrypted in an invalid way: either
         it wasn't an even multiple of the block length, or its padding
         values when checked, weren't correct. However, differentiating
         between bad_record_mac and decryption_failed alerts may permit
         certain attacks against CBC mode as used in TLS [CBCATT].
         Therefore, decryption_failed MUST NOT be sent in TLS 1.1 sessions.
         An implementation MUST nevertheless treat a received
         decryption_failed alert as a fatal error.

-- 
David Hopwood <[email-masked]>

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 27 Jan 2005 00:21:55 +0100

>          decryption_failed alert as a fatal error.

Just one correction: The decryption_failed alert is not specified for
SSL 3.0, so instead of "previous versions of TLS (and SSL)", we should
say "TLS version 1.0".