Re: Datagram TLS

[Eric Rescorla <ekr@rtfm.com>]

Bodo Moeller <bmoeller@eecs.berkeley.edu> writes:

> On Fri, Jan 30, 2004 at 09:04:27AM -0800, Eric Rescorla wrote:
> 
> > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt
> > 
> > Comments welcome...
> 
> 1. Section 4.1.1 says "Each DTLS record MUST fit within a single datagram."
> 
>    Section 4.2.3. on handshake message fragmentation and reassembly
>    states that "As noted in Section 4.1.1., each DTLS message MUST fit
>    within a single transport layer datagram."
> 
>    However, in TLS terminology, "records" and "messages" are notions on
>    different levels.  A record is a unit of data that is handled by the
>    TLS record protocol, which handles encryption and so one.  A "message"
>    is structured data sent through the TLS record layer in records with a
>    ContentTape of change_cipher_spec, alert, or handshake, where message
>    boundaries are *not* preserved in the record layer (RFC 2246,
>    section 6.2.1).
Right. This should say "record".

>    Section 4.2.3 of the DTLS Internet Draft essentially describes how
>    long handshake messages can be fragmented into multiple shorter
>    handshake messages.  However, I haven't seen language in the draft
>    actually saying that messages must not be otherwise fragmented into
>    multiple records, which is perfectly legal in TLS (a 97-byte
>    ClientHello message could be sent in 97 records carrying one handshake
>    protocol byte each, for example).  Obviously you don't want this to
>    be done in DTLS, but the draft does not appear to forbid it.
Well, I think this is bad practice, but I'm not sure we want to
forbid this.

> 2. In TLS, alerts such bad_record_mac are fatal, which will even
>    (unnecessarily) invalidate the current session such that it is no
>    longer available for session resumption.  Treating invalid records
>    like this appears unnecessary for DTLS, and undesireable if we want
>    to make denial of service attacks harder.
> 
>    One possibility would be to keep the bad_record_mac alert (the
>    purported sender of the record in question might be interested in
>    knowing that something went wrong), but make them non-fatal.  It
>    may make sense to limit the rate of such alerts -- if 90% of the
>    records received for a DTLS session are bogus, the remaining
>    legitimate 10% might do a good job for communication between
>    DTLS client and server, and limiting the rate of such non-fatal
>    bad_record_mac would avoid unnecessarily wasting bandwidth
>    in addition to that directly stolen by the adversary who sends
>    the bogus datagrams.  Possibly it might even make sense to
>    introduce a new alert that say that a *valid* has been received:
>    otherwise, in unidirectional communication, the sender cannot tell
>    if it make any sense to continue after it has received some
>    bad_record_mac alerts (which could sometimes indicate that
>    something really went wrong with the cryptography done by the
>    client and the server, e.g. because of implementation bugs
>    affecting the current ciphersuite).
Good point. I like the non-fatal suggestion. Not so sure about
the new alert...

-Ekr