Subject: Datagram TLS

From: Eric Rescorla <[email-masked]>
Date: Fri, 30 Jan 2004 09:04:27 -0800

This seems relevant to these working groups.

Although TLS is quite useful as a generic security layer protocol for
lots of applications, it is limited by its reliance on datagram
transport. It seems like it would be useful to deploy TLS-style security
for datagram apps. To this end, Nagendra Modadugu and I have designed a
variant on TLS which works properly over datagram transport but is
otherwise intended to be as similar to TLS as possible.

http://www.ietf.org/internet-drafts/draft-rescorla-dtls-00.txt

Comments welcome...

-Ekr

---

From: Scott Fluhrer <[email-masked]>
Date: Fri, 30 Jan 2004 18:00:08 -0800 (PST)

On Fri, 30 Jan 2004, Scott Fluhrer wrote:

>
>
> On Fri, 30 Jan 2004, Eric Rescorla wrote:
>
> One obvious question is how you handle the switchover if one of the sides
> decides to rekey.  In this case, a packet encrypted with the old key
> might be slow, and arrive at the destination after the rekey
> negotiation has completed.  TLS handles this because it can assume strict
> message ordering.  IPSec handles this with the SPI value.  How does DTLS
> prevent a packet being decrypted with the wrong key?

Never mind...  While writing this, I came across the epoch flag, that
handles precisely this.  I went to cancel the email and accidentally hit
Send... :-(

-- 
scott

---

From: Eric Rescorla <[email-masked]>
Date: 30 Jan 2004 18:02:10 -0800

> prevent a packet being decrypted with the wrong key?

Using the epoch number (Section 4.1).

Of course, in principle this is unnecessary. You could just 
try both keys but we deciced that was too ugly. :)

-Ekr

---

From: Scott Fluhrer <[email-masked]>
Date: Fri, 30 Jan 2004 17:58:06 -0800 (PST)

-- 
scott

---

From: Eric Rescorla <[email-masked]>
Date: 31 Jan 2004 09:38:04 -0800

Bodo Moeller <[email-masked]> writes:

> On Fri, Jan 30, 2004 at 09:04:27AM -0800, Eric Rescorla wrote:
> 
> 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