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

[Martin Rex <mrex at sap.com>]

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 wrote:
> > 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:
> 
> 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.
> 
> -- 
> 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
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> --===============1151963907==--
>