[TLS] Comments on draft-rescorla-tls-renegotiate.txt

[David-Sarah Hopwood <david-sarah at jacaranda.org>]

Comments on
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

Overall I think this draft is a good solution to the identified security
problem.

The draft defines an extension that affects renegotiation, which might
be perceived to conflict with RFC 3546 section 2.3:

   Finally note that all the extensions defined in this document are
   relevant only when a session is initiated.  However, a client that
   requests resumption of a session does not in general know whether the
   server will accept this request, and therefore it SHOULD send an
   extended client hello if it would normally do so for a new session.
   If the resumption request is denied, then a new set of extensions
   will be negotiated as normal.  If, on the other hand, the older
   session is resumed, then the server MUST ignore extensions appearing
   in the client hello, and send a server hello containing no
   extensions; in this case the extension functionality negotiated
   during the original session initiation is applied to the resumed
   session.

The intent of this restriction (that "the server MUST ignore extensions
appearing in the client hello, and send a server hello containing no
extensions" when a session is resumed) was that it would potentially
simplify security analysis of TLS, by justifying an assumption that the
extension-based options used in a session stay the same across resumptions
(see <http://thread.gmane.org/gmane.ietf.tls/429>).
It wasn't intended (at least not by me, as one of the authors of RFC 3546)
to preclude the definition of extensions that are specifically designed
to affect renegotiation. But since it could be interpreted that way, I
think that the draft should explicitly clarify this point.

Another issue is that a server that supports the extension can refuse
the renegotiation. The current draft is not clear about what the client
and server behaviour should be in that case.

Suggestion:

If a ClientHello that is requesting to resume a previous session
contains a Renegotiation_Info extension, and the server supports the
extension but wishes to refuse the renegotiation, it SHOULD reply
with a zero-length Renegotiation_Info.

If a client that is requesting to resume a session receives a
zero-length Renegotiation_Info without a no_renegotiation alert, it
MUST abort the handshake. If it receives both a zero-length
Renegotiation_Info and a no_renegotiation alert, then the fact that
the Renegotiation_Info contents do not match the previous session's
verify_data values should not be considered a reason for the client
to abort.

Note that one legitimate reason for refusing a renegotiation is that
the old session has expired, in which case the server is likely to have
forgotten the client and server verify_data values for that session.
Nevertheless it SHOULD reply with a Renegotiation_Info to indicate
that it supports the extension.

For the same reason, when the server refuses a renegotiation it may
not have the ability to check that the contents of the client's
Renegotiation_Info were correct. Therefore, there should be no
requirement for the server to check the contents in that case.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

Attachment: signature.asc
Description: OpenPGP digital signature