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

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 07 Nov 2009 06:18:22 +0000

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 07 Nov 2009 06:35:19 +0000

> be perceived to conflict with RFC 3546 section 2.3:

Ah, I should have been referencing RFC 4366 section 3 -- but the
wording is almost the same:

   Note also that all the extensions defined in this section are
   relevant only when a session is initiated.  When a client includes
   one or more of the defined extension types in an extended client
   hello while requesting session resumption:

   -  If the resumption request is denied, the use of the extensions is
      negotiated as normal.

   -  If, on the other hand, the older session is resumed, then the
      server MUST ignore the extensions and send a server hello
      containing none of the extension types.  In this case, the
      functionality of these extensions negotiated during the original
      session initiation is applied to the resumed session.

and the same comments apply.

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 07 Nov 2009 08:07:58 -0800

> with a zero-length Renegotiation_Info.

The server already has to reply with an empty Renegotiation_Info
extension.  That is what happens on an initial handshake even when
resuming a previous session, and also for a session_ticket resume.

The draft has only a single sentence discussing session resumption:

    The above rules apply even when TLS resumption is used.

Maybe it needs to elaborate more.

> verify_data values should not be considered a reason for the client

No, session resumption is no different w.r.t. the Renegotiation_Info
extension than a full handshake.  The info is always empty on the
first handshake for a connection, even when resuming a previous session.

As a result, you do not need to store the verify_data from the finished
messages in your session cache.

> that it supports the extension.

The server never needs to remember the verify_data from a previous
session unless it is the currently active session.  When storing a
session in your session cache, the verify_data can be discarded since
it is not needed in the future.  If that session gets resumed later,
the Renegotiation_Info will be empty.

Mike

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 08 Nov 2009 00:03:18 +0000

> resuming a previous session, and also for a session_ticket resume.
[...]
> messages in your session cache.

Yes, you're right. I was confused.

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Nov 2009 06:37:26 +0100 (MET)

The quoted sections are obvious defects in that documents.

rfc5246 7.4.1.4 (top of page 45) seems to contain a corrected version:

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.  Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.  However, some extensions may
   specify different behavior during session resumption.

what TLS documentations should have expressed (what it meant) is
that TLS extensions ought to not modify the cryptographic properties
of the resumed session.  The TLS RI extension will not modify the
cryptographic properties of the resumed session.

-Martin

David-Sarah Hopwood wrote:
> David-Sarah Hopwood  âš¥  http://davidsarah.livejournal.com
> 
> 
> --------------enig78606FA1DFD4566081965DA6
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iF4EAREIAAYFAkr1FTAACgkQWUc8YzyzqAeXzQD/cAwn2+qxFM7S/DwRcg+bFLf0
> 5tm2hOBIsJwrCA233twBAIBGJi0NscO0nM5PZK+Pobm+oFnotOOkxRSx+4syl0v/
> =IaTm
> -----END PGP SIGNATURE-----
> 
> --------------enig78606FA1DFD4566081965DA6--
> 
> --===============1151963907==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
> --===============1151963907==--
>