Subject: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 8 Oct 2009 11:01:47 -0700

This is an announcement for working group last call on DTLS 1.2 (RFC
4347-bis).  The document is available here:

http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03

Please send any comments to the list by October 26, 2009.  It is useful
to send an indication to the list if you have read the document and
think it is ready for publication even if you don't have specific
comments.  

Thanks,

Joe

---

From: Robin Seggelmann <[email-masked]>
Date: Mon, 19 Oct 2009 14:25:25 +0200

> think it is ready for publication even if you don't have specific

In my opinion it's ready and I have no further comments.

Regards,
Robin

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 22 Oct 2009 18:10:17 +0200

Hi Josef,

I read the ID and I'm fine with it.

Best regards
Michael

On Oct 8, 2009, at 8:01 PM, Joseph Salowey (jsalowey) wrote:

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

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 22 Oct 2009 21:29:18 -0700

The link appears to go to the correct version of the draft, but the
header of each page says it is draft -00 dated June 2008.

Overall the draft seems to be good, but one thing I think is missing
is for the server to be able to somehow tell the client to switch to
a different port for DTLS over UDP (I don't know about other types
of transports).  The simplest scheme I can envision is that the
HelloVerifyRequest and ServerHello messages would be sent from the
port the client initially contacted.  The ServerHello would contain
a DTLS_PortChange extension listing the new port number.  The
remainder of the handshake and subsequent data transfer would occur
on this new port.

Comments on the draft:

In section 3. Overview of DTLS, it says:

     1. TLS's traffic encryption layer does not allow independent
     decryption of individual records.  If record N is not received,
     then record N+1 cannot be decrypted.

I don't believe this is always true -- if a block cipher is used,
then since there is an explicit IV given, you can decrypt the record.
The MAC, however, will not calculate correctly due to the wrong
sequence number, so the missing record will be detected.  Stream
(and AEAD?) ciphers would fail to decrypt as stated.

Near the top of page 9, the abbreviation CSS is used.  I think that
should have been CCS, but I would suggest spelling out ChangeCipher
Spec rather than abbreviating.

At the very end of section 4.2.1 (top of page 17) it mentions a
HelloVerify message (not HelloVerifyRequest).  Should that be a
ClientHello message (with cookie)?

Typos:

   - last line of page 3: "they typically requires" strike the s.
   - section 4.1.1 second line, "that clients" remove "that"
   - top of page 14 - "forget" should be "forgery"

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 28 Oct 2009 10:06:16 -0700

Hi Mike,

Thanks for looking at the document.  I think that an extension to tell
the client to switch ports or protocols is beyond the scope of the
current work item.  It would be best covered as a separate new work item
if the working group thinks it is useful.  Perhaps it is related to the
proposal on next protocol negotiation that was sent to the list (it
might not be, I haven't had a chance to read it yet).  I'll open an
issue for your other comments.

Thanks,

Joe

> The link appears to go to the correct version of the draft, 
> but the header of each page says it is draft -00 dated June 2008.
> 
> Overall the draft seems to be good, but one thing I think is 
> missing is for the server to be able to somehow tell the 
> client to switch to a different port for DTLS over UDP (I 
> don't know about other types of transports).  The simplest 
> scheme I can envision is that the HelloVerifyRequest and 
> ServerHello messages would be sent from the port the client 
> initially contacted.  The ServerHello would contain a 
> DTLS_PortChange extension listing the new port number.  The 
> remainder of the handshake and subsequent data transfer would 
> occur on this new port.
> 
> Comments on the draft:
> 
> I don't believe this is always true -- if a block cipher is 
> used, then since there is an explicit IV given, you can 
> decrypt the record.
> The MAC, however, will not calculate correctly due to the 
> wrong sequence number, so the missing record will be 
> detected.  Stream (and AEAD?) ciphers would fail to decrypt as stated.
> 
> Near the top of page 9, the abbreviation CSS is used.  I 
> think that should have been CCS, but I would suggest spelling 
> out ChangeCipher Spec rather than abbreviating.
> 
> At the very end of section 4.2.1 (top of page 17) it mentions 
> a HelloVerify message (not HelloVerifyRequest).  Should that 
> be a ClientHello message (with cookie)?
> 
> Typos:
> 
> > Please send any comments to the list by October 26, 2009.  It is 
> > useful to send an indication to the list if you have read 
> the document 
> > and think it is ready for publication even if you don't 
> have specific 
> > comments.
> > 
> > Thanks,
> > 
> > Joe