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

From: Tolga Acar <[email-masked]>
Date: Thu, 3 Dec 2009 11:46:20 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Kyle Hamilton
Sent: Monday, November 30, 2009 10:32 AM
To: Eric Rescorla
Cc: [email-masked]
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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Thu, 03 Dec 2009 14:01:32 -0600

Tolga Acar wrote:
>  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.

Couldn't he possibly 'prep' the client by triggering the exchange of the
appropriate number of dummy records before splicing him into the server
connection?

Is there something about the DTLS sequence_number that makes it more
resilient than the TLS record sequence number?

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Dec 2009 12:45:04 -0800

At Thu, 03 Dec 2009 14:01:32 -0600,
> resilient than the TLS record sequence number?

The sequence number still zeros at every handshake. AFAIK, the only
protection is the epoch, which, as discussed, is potentially manipulable.

-Ekr

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 03 Dec 2009 23:41:34 +0000

Tolga Acar wrote:
> 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.

RFC 4347 section 4.1:

# As with TLS, the sequence number is set to zero after each
# ChangeCipherSpec message is sent.

So there are two ways to apply the attack to DTLS: either using the
third attack scenario described in
<http://tools.ietf.org/id/draft-mrex-tls-secure-renegotiation-03.txt>:

# 3. Two independent TLS sessions Client<->MitM and MitM<->Server
#    are spliced into one single TLS session Client<->Server through
#    TLS renegotiation where the MitM proxies all communication

or by a rollover of the epoch, which is only 16 bits. The latter is
straightforward if the target implementation does not detect rollovers.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com