Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 20 July 2007 04:51 UTC
Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkSv-0006UA-Kn; Fri, 20 Jul 2007 00:51:45 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBkSu-0006U3-Co for tls@ietf.org; Fri, 20 Jul 2007 00:51:44 -0400
Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBkSt-0007Z8-Tn for tls@ietf.org; Fri, 20 Jul 2007 00:51:44 -0400
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6K4pgGo009713 for <tls@ietf.org>; Fri, 20 Jul 2007 04:51:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6K4pgRF001307 for <tls@ietf.org>; Thu, 19 Jul 2007 22:51:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6K4pgJW026311; Thu, 19 Jul 2007 23:51:42 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6K4pfPn026310; Thu, 19 Jul 2007 23:51:41 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 19 Jul 2007 23:51:41 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <Martin.Rex@sap.com>
Subject: Re: [TLS] Negotiation in draft-santesson-tls-gssapi
Message-ID: <20070720045140.GC26276@Sun.COM>
References: <200707192354.l6JNsPkJ029220@fs4113.wdf.sap.corp> <200707200020.l6K0KTdL000752@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200707200020.l6K0KTdL000752@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
On Fri, Jul 20, 2007 at 02:20:29AM +0200, Martin Rex wrote: > A while back we had a discussion about changing the TLS PRF. > Then it was suggested that it should be OK if both parties have > to keep all SSL handshake messages around in order to compute > the finished messages. > > I don't think this would be a good idea if there is no size limit > on the size of the entire SSL/TLS handshake. Do we really want > to have the entire GSS-API token exchange WITHIN the TLS handshake? Well, we could have the Finished message construction modified so as to substitute a hash of each GSS context token in place of that token. > The decision of a TLS server to abort a handshake because of an > excessively large Hello extension itself might be easier than > to tell from which size on a huge optimistic context token for an > (potentially unsupported) gssapi mechanism in the SPNEGO token > should be considered an offense or attack deserving a FATAL SSL alert... I don't think we want to have the initial context token go in the client Hello message, even if it turns out that we could. I'm willing to eat that round-trip (even though I might be -- I haven't decided :) -- concerned about additional round-trips in the GSS-fails case). Nico -- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- [TLS] Negotiation in draft-santesson-tls-gssapi Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- RE: [TLS] Negotiation in draft-santesson-tls-gssa… Larry Zhu
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Martin Rex
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Nicolas Williams
- Re: [TLS] Negotiation in draft-santesson-tls-gssa… Bodo Moeller