Last Call Review of draft-ietf-tls-padding-01
review-ietf-tls-padding-01-opsdir-lc-hares-2015-09-01-00

Adam:



This is an OPS-DIR Review and part of the IETF effort to improve all
documents.  These set of comments should be taken as any other comment during
IETF LC.



Comment: Nicely written document with clear examples.  Easy to understand the
“How, when, where, and why” of the document.



Status: Not ready, minor concern. Please review if it updates RFC5246



One minor concern: This seems to update RFC5246.  If so, it should state this. 
If it does extend RFC5246, then it needs to create a new section in the draft
to address the issues.

If the author believes it doesn’t update RFC5246, then I’d appreciate knowing
why to help with my future reviews of security area documents.



Operationally – it’s a nice fix.  It would be nice to state if this has been
tested in a number of TCP implementations in the draft. You can always put the
status of the TCP implementation on your wiki page.



Sue Hares



===========

RFC5246 p. 41



   extensions

      Clients MAY request extended functionality from servers by sending

      data in the extensions field.  The actual "Extension" format is

      defined in Section 7.4.1.4.



   In the event that a client requests additional functionality using

   extensions, and this functionality is not supplied by the server, the

   client MAY abort the handshake.  A server MUST accept ClientHello

   messages both with and without the extensions field, and (as for all

   other messages) it MUST check that the amount of data in the message

   precisely matches one of these formats; if not, then it MUST send a

   fatal "decode_error" alert.



Section 7.4.1.4 states as follows

   An extension type MUST NOT appear in the ServerHello unless the same

   extension type appeared in the corresponding ClientHello.  If a

   client receives an extension type in ServerHello that it did not

   request in the associated ClientHello, it MUST abort the handshake

   with an unsupported_extension fatal alert.



[Sue’s note – this is obeyed by this extension text above]



   Finally, note that extensions can be sent both when starting a new

   session and when requesting session resumption.  Indeed, a client

   that requests session resumption does not in general know whether the

   server will accept this request, and therefore it SHOULD send the

   same extensions as it would send if it were not attempting

   resumption.



[Sue’s if the packet length is different, you may send the same padding

Extension or you may not need to send the same extension. ]