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

Martin Rex <mrex@sap.com> Thu, 12 November 2009 05:37 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3DB3A6B82 for <tls@core3.amsl.com>; Wed, 11 Nov 2009 21:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.159
X-Spam-Level:
X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC8tWZB-AyGS for <tls@core3.amsl.com>; Wed, 11 Nov 2009 21:37:02 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C9193A6A0B for <tls@ietf.org>; Wed, 11 Nov 2009 21:37:02 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAC5bTXI025008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 06:37:29 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911120537.nAC5bQV0021407@fs4113.wdf.sap.corp>
To: david-sarah@jacaranda.org
Date: Thu, 12 Nov 2009 06:37:26 +0100
In-Reply-To: <4AF51527.5060404@jacaranda.org> from "David-Sarah Hopwood" at Nov 7, 9 06:35:19 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2009 05:37:03 -0000

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