Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS

I looked at DTLS and it doesn't seem like it is vulnerable as TLS is.
The "uint16 epoch" and "uint48 sequence_number" in the record header are input to the MAC and are validated per RFC4347 Section 4.1.2.1. It seems to me that a MiTM would not have a  matching epoch+sequence number, the MiTM can't change them (ok, may change, but MAC would not validate), and it takes 2^48 for them to roll over. So, short of 2^48 bit rollover (and, don't forget the message sequence number <uint16> inside the record), I don't see how MiTM would work in DTLS.

However, in the last paragraph of the same section, it says "DTLS implementations SHOULD silently discard data with bad MACs". If an implementation were to ignore bad MACs, things would go bad and MiTM would be applicable. I suggest SHOULD be changed to MUST; or people must expect that implementations would barf on mad MACs. 

- Tolga

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Kyle Hamilton
Sent: Monday, November 30, 2009 10:32 AM
To: Eric Rescorla
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-renegotiation-01.txt and DTLS

I would support randomizing the epoch counter in DTLS, giving a 1:2^16 chance of getting it right in a single attempt.  (This follows my observation that the hash saved from the last Finished message is essentially the same as a named epoch.)

-Kyle H

On Mon, Nov 30, 2009 at 10:29 AM, Eric Rescorla <ekr@networkresonance.com> wrote:
> At Mon, 30 Nov 2009 12:06:02 -0600,
> Marsh Ray wrote:
>>
>> Michael Tüxen wrote:
>> >
>> > If I'm not wrong, then the attack which works against TLS does not 
>> > work against DTLS, since DTLS has an epoch counter.
>> >
>> > If a client tries to establish a DTLS connection and a MITM 
>> > intercepts it, establishes itself a DTLS connection, the epoch is 
>> > 1. There will be a final mismatch in the epoch and the packets will 
>> > be discarded. When using the RI extension one could enforce the sending of the alert message.
>> > But the original attack is not possible, I think.
>> >
>> > Is my analysis correct or am I overlooking something?
>>
>> Can MitM do the same number of renegotitations as he does with the 
>> server before splicing him?
>
> Nagendray and I had this conversation last week. While I haven't done 
> a complete analysis, my intuition is that DTLS is more resistant (for 
> the reason you indicate) but not 100% resistant.  Another concern 
> would be epoch rollover: what if you do 65536 (65535?--too lazy to
> calculate) handshakes with the server and force the epoch back to 0?
>
> So, probably better to use RI with DTLS as well.
>
> -Ekr
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls