Subject: RE: [TLS] Last call comments about DTLS (mostly editorial)

From: [email-masked]
Date: Tue, 22 Mar 2005 19:08:18 +0200

Eric Rescorla writes:
>
> Pasi,
> 
> Thanks for your comments. These seem pretty sensible. 
> A few responses below.
<snip>
> > I would probably call [PHOTURIS], [RFC2401], [TCP], and 
> > [TLS] informative references rather than normative. 
> 
> RFC 2401 is needed as normative because it specifies in
> part the anti-replay algorithm. TCP specifies MSL, and
> since this is a delta from TLS, we need to specify TLS
> as normative.

[TLS11] is certainly normative, but probably not [TLS]?

And here comes the next batch of comments:

12)

DTLS seems to assume a connection-oriented datagram transport
(or at least a transport that has some idea of connections)
since the transport is responsible for mapping incoming packets
to correct TLS sessions (unlike, for instance, IPsec/IKE that
have explicit SPI fields).

Presumably for UDP, this would happen using the source and 
destination IP addresses and port numbers.

Suggested change: Describe this explicitly (perhaps somewhere
around 4.1.1 would be a good place).

13)

The last paragraph of Section 4.1.2.5 suggests that DTLS handles
incorrect MACs differently than normal TLS 1.1 (where they're
always a fatal error). 

Suggested change: Describe this explicitly (maybe in 
Section 4.1.2.1).

14)

Section 4.2.1 says that "The server SHOULD use those values to
generate its cookie and verify that they are correct upon cookie
receipt." (where "those values" refers to the fields from
ClientHello)

But obviously the most important piece of data to include in the
cookie calculation is the client's IP address. Even though this
is somewhat obvious, perhaps it should be still mentioned
explicitly.

Come to think of it, Section 2.6 of draft-ietf-ipsec-ikev2-17
has some good advice about how to calculate cookies and verify
them in a way that does not require server-side state. Maybe
some of that text could be copied here, with suitable changes.

15)

It seems that the handshake will unnecessarily fail if the
client ever sends an a cookie that the server rejects (for
whatever reason, e.g. restarted server process).

It looks like the server could just send a new
HelloVerifyRequest with a new cookie, but it won't work. 
The client sends a new ClientHello with that cookie; the server 
will accept the cookie this time, and the handshake will
continue... until it fails when the Finished message is
verified.

This is because the Finished message includes both the old and
new ClientHello (according to 4.2.6); and this means the server
has to remember the old ClientHello (which is precisely what we
tried to avoid with cookies).

Suggested change: when using cookies, don't include the first
ClientHello and HelloVerifyRequest when calculating the Finished
message (this is the way IKEv2 handles the same problem, BTW).

16)

According to Section 4.2.4, it seems both the client and the
server do retransmissions based on timer.

I'm not quite sure how good idea this is. Especially having the
server to retransmit HelloVerifyRequest repeatedly sounds like 
a very bad idea: the server must keep state (while the idea of
cookies was to avoid state at this stage), and can be used as 
an "amplifier".

This particular problem could be fixed by just making an
exception for HelloVerifyRequest, but perhaps it would be
simpler to avoid timers on the server side completely 
(whenever possible).

For the full handshake, all the timer-based retransmissions
could be easily done by the client (server retransmits only 
when receiving a retransmitted message from client).

For session resumption, the last handshake message is sent 
by the client, so to make it work, DTLS would have to add 
one more message to acknowledge that.

This way, the server would not need to do timer-based
retransmissions for anything else except HelloRequest messages
(which, BTW, are not covered by the current state machine in
Section 4.2.4).

17)

It seems that Alert messages are not retransmitted at all
(ChangeCipherSpec is not technically a handshake message 
either, but that's listed as exception in 4.2.5).

Does this cause some problems? (at least it should be
mentioned explicitly)

18)

Section 4.2.2 says that message_seq (in Handshake structure)
stays the same when a message is retransmitted.

What about DTLSPlaintext.sequence_number? (If the
retransmissions are done by the "handshake layer", then it 
seems logical that sequence_number would be incremented for
retransmissions, since they're new messages from the record
layer point of view.)

19)

It seems that replay protection should not be used before
ChangeCipherSpec has been sent (i.e. during handshake)?
Perhaps this should be mentioned explicitly.

I've got a couple of comments more that I haven't fully gone
through yet; I'll send them tomorrow..

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls