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

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

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:
> 
> 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
> 
> 
> Joseph Salowey (jsalowey) wrote:
> > 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
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>