Subject: Re: Datagram TLS

From: Eric Rescorla <[email-masked]>
Date: 01 Feb 2004 13:46:40 -0800

Bodo Moeller <[email-masked]> writes:

> On Sat, Jan 31, 2004 at 09:38:04AM -0800, Eric Rescorla wrote:
> > Bodo Moeller <[email-masked]> writes:
> 
> [...]
> >>    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.
> 
> If you don't forbid it, I don't see a need to add fragmentation on the
> handshake protocol level -- recipients would have to be able to perform
> reassambly of Handshake data structures that are spread over multiple
> records anyway.  Reassembly is simpler with the fragment_offset
> provided by your higher-level fragmentation mechanism, but
> implementations don't really profit from this if fragmentation could
> actually happen at either level.
Ah. Good point--and that reassembly isn't deterministic.

We'll arrange to forbid it.

> By the way, section 4.1.1 (transport layer mapping) is not entirely
> clear.  Unless your intention is that each datagram should contain
> only a single DTLS record (which should be clarified in the Internet
> Draft if this is the case), I suggest changing
> 
>    Each DTLS record MUST fit within a single datagram. In order to avoid
>    IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
>    MTU and send records smaller than the MTU. [...]
> 
> into
> 
>    Each DTLS record MUST fit within a single datagram, and DLTS record
>    boundaries MUST observe datagram boundaries.  If lengths permit, multiple
>    DTLS records can be concatenated (in order) and sent within a
>    single datagram.  In order to avoid IP fragmentation [MOGUL], DTLS
>    implementations SHOULD determine the MTU and send datagrams smaller
>    than the MTU. [...]
>    
> or something along those lines.  (Record concatenation is useful
> when data from multiple message types is sent at the same time,
> such as ClientKeyExchange, ChangeCipherSpec, and Finished.)
Agreed. Good point.

> Right, I don't really fancy adding a new alert either, I just wanted
> to describe an option that *might* have some value.  If no one wants
> to have it, than I'm entirely comfortable without this kind of
> "non-alert".  (Other new alerts that I can think of but that I don't
> really want are alerts for indicating high record loss, i.e.
> holes in the list of sequence numbers received in valid records.)
In the spirit of adding as few things as possible, I think I'd
rather hold off on these for now until we we have some application
that clearly needs it.

Thanks,
-Ekr

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 4 Feb 2004 15:49:30 +0200

Hi Eric.

Here's two comments:

1. In section 3.2.1 (Packet Loss), as well as 4.2.4 you state that both
client and server should keep a retransmission timer and retransmit when it
expires.  This raises the question of who retransmits first, the client or
the server.  This leads to an unpredictable flow, which leads to race
conditions for implementations.  For the case of the HelloVerifyRequest we
have an additional disadvantage in that it requires the gateway to keep a
state.  I suggest that the client alone retransmits, and the server only
replies.  After receiving the second ClientHello it should keep enough state
to retransmit its previous reply, but it should never retransmit on its own.
IMO this makes the protocol flow more predictable and easy to analyze.
It does require that all negotiations have an even number of flights, like
in IKEv2, and unlike IKEv1.

2. In section 4.2.1 (Denial of Service Countermeasures) it is stated that
the technique used by Photuris is used to generate and to verify the
stateless cookie in the ClientHello message.  I believe that Internet drafts
should only mandate things that are necessary for interoperability.  In this
case, the cookie is generated and verified by the same server.  There should
be no mandate for the protocol.  I suggest that the Photuris technique be
mentioned only as a suggestion and that the PHOTURIS document be Informative
rather than Normative.  That way, if someone creates a stateless cookie
technique that's better than Photuris, you won't have to change the draft.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Eric Rescorla
Sent: Friday, January 30, 2004 7:04 PM
To: [email-masked]; [email-masked]
Subject: Datagram TLS

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