Subject: [TLS] Forward: Comments on draft of DTLS 1.2

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Mar 2009 22:00:53 -0700

Subject: Comments on draft of DTLS 1.2
From: Russ Housley <[email-masked]>
To: [email-masked]
Date: Mon, 16 Mar 2009 16:33:02 -0400

Passing these along ....

I have the following comments  on
draft-ietf-tls-rfc43470bis-02.

1) Section 3.2.1 says that once the client has transmitted
the ClientHello message, it expects to see a HelloVerifyRequest from the
server.  Section 4.2.1 states that when the client sends its
ClientHello message to the server, the server MAY respond with a
HelloVerifyRequest message.  I assume then that the use of
HelloVerifyRequest message is optional.  If this is the case, should
section 3.2.1 say instead that once the client has transmitted the
ClientHello message, it expects to see either a HelloVerifyRequest or a
ServerHello message from the server.

2) Section 4.1, the paragraph after the descriptions of epoch,
sequence_number, length and fragment.  Looking at the end of the
third sentence, should this be instead "....even if the message from
epoch 0 was transmitted first".

3) In the last paragraph of section 4.2.1, we have the sentence "If
a server receives a ClientHello with an invalid cookie, it SHOULD treat
it the same as a ClientHello with no cookie.,,,,,this may result in
clients receiving multiple HelloVerifyRequest messages with different
cookies....".    What does this mean exactly?
Can the server decide just to ignore the bad cookie and continue with the
handshaking?  If so, then the client would calculate its finished
message over this clienthello with the cookie and the server would
calculate its finished message over this clienthello without the
cookie.

I'm also assuming that all messages with helloverifyrequest and
clienthello's are not included in the certificateverify and finished
messages until you get to the last clientHello sent (that is assumed to
be valid and allows you to proceed).  For example, client sends
ClientHello(1), server responds with HelloVerifyRequest(1); client sends
the ClientHello with invalid cookie - call it ClientHello(2); Server
sends 2nd HelloVerifyRequest(2); Client replies with the ClientHello with
the valid cookie this time - call it ClientHello(3). They then proceed
with the handshake.  In this case ClientHello(1),
HelloVerifyRequest(1), ClientHello(2), HelloVerifyRequest(2) are omitted
from Finished and CertificateVerify messages. (?)

4) Section 4.2.2    fragment_length is a uint 24.
How can this be if the overall record length is a uint16 ?  I
thought that fragment_length is the length of this particular fragment
while "length" , a uint24,  is the overall length of this
particular handshake message.

5) Section 4.2.2.  In the descriptive section (the diagram) about
retransmitting one sees (seq=0) etc.  It might be better to write
out message_seq in place of "seq" just to make sure that it's
clear that we're talking about the message_seq and not the
sequence_number.  The paragraphs right before and right after the
diagram do clarify that though.

6) In figure 2, it might be nice to include the (epoch,sequence_number)
for each line or to provide an example of this.  This would help
illustrate what Michael Tuexen and Robin Seggelmann
were talking about in the emails from the end of Feb.  In
particular, it would clarify that the epoch changes value after the
change_cipher_spec message (so, the change_cipher_spec message itself
still uses the current epoch number)

Grammatical:

1) Section 1, 2nd para., last sent:
requires should be require in
"..they typically require a large amount
of effort..."

2) Section 4.1, 3rd para. from the end; end of 2nd sentence missing a
noun?  "but if packet loss causes noticeable problems,
implementations MAY choose...."

3) Section 4.1, 2nd para. from the end, 2nd sent, add a
"message" to "For instance, the server may send its
Finished message and then start transmitting
data".  I had trouble parsing the next sentence and added a
";" and "," as in "Implementations MAY either
buffer or discard such packets; though, when DTLS is used
over realiable...."

4) Section 4.1, last para.  I would add message to Finished in two
places and change CSS to ChangeCipherSpec . In the last sentence I would
change "an" to "any" and add an "s" to the
last word "attack":    In
any other case, the implementation
MUST wait for the receipt of the Finished
message to prevent downgrade
attacks.

5) Section 4.1.1, 1st para., 2nd sent: remove "that" from
"In order to avoid fragmentation, that
clients..."

6) Section 4.1.1, 2nd para., last sent, make number
plural.

7) Section 4.1.2.1, add a "," to "..is that
in TLS, MAC errors ...."

8) Section 4.2.1, last para., change "may results"
to "may result" in "implementors:  this may
results in clients..."  Also in the last
sentence, one sees "HelloVerify".  Should this be instead
"ClientHello"?