[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] DTLS resilience [was: comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20p
From:       Nikos Mavrogiannopoulos <nmav () gnutls ! org>
Date:       2013-10-23 20:50:08
Message-ID: 52683680.8020909 () gnutls ! org
[Download RAW message or body]

On 10/23/2013 06:40 PM, Nikos Mavrogiannopoulos wrote:

>>     as a general comment I think DTLS' resilience on forged packets
>>     isn't that good. It makes it a perfect target to lay an attack. I think
>>     it would be much better to have a limit by default on the allowed
>>     packets with wrong MAC.
>> S 4.2.7 provides some guidance in this area, but it's pretty vague:
>>
>>    Note that Alert messages are not retransmitted at all, even when they
>>    occur in the context of a handshake.  However, a DTLS implementation
>>    which would ordinarily issue an alert SHOULD generate a new alert
>>    message if the offending record is received again (e.g., as a
>>    retransmitted handshake message).  Implementations SHOULD detect when
>>    a peer is persistently sending bad messages and terminate the local
>>    connection state after such misbehavior is detected.
>> It certainly seems like it would be a good thing to document some
>> better guidance about how many bad MACs you should tolerate.
>> Do you have any thoughts about what makes sense?
> 
> I was thinking of disabling wrong MAC tolerance completely if the
> underlying layer has checksums. UDP for example has checksums and
> packets that are altered due to transmission errors will be discarded
> anyway. In lower protocols such as ethernet we also have checksums.
> 
> If someone needs to transmit in raw without any checksums, he could
> exceptionally allow wrong MAC tolerance.

It seems I answered hastily. I think there is an issue with what I
proposed. I see 2 things that need to be ensured here.
1. The session must be resilient to accidental transmission errors.
2. The session must be resilient to termination by someone who hasn't
access on the communication line

Do I miss something else?

[I don't think there is point being resilient to someone with access to
the communication line, as he could always cause a DoS by simply
dropping all packets.]

My proposal above handles 1, but not 2. In the UDP case anybody can
forge a DTLS packet and send it on the server port claiming to be the
client (he doesn't need to know the client port, he just sends many
packets with all possible ports). DTLS will discard packets out of
epoch, or with old sequence numbers, but sequence numbers are easy to
guess in DTLS. They are sequential and start from 0. Thus one could
"easily" avoid the window check in DTLS and pass a packet with an
invalid MAC.

So if wrong MAC tolerance is removed in a future revision of DTLS, it
has to be combined with something that ensures (2). That could be random
sequence numbers (similar to TCP), or something else.

regards,
Nikos


[prev in list] [next in list] [prev in thread] [next in thread]