Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
Nicolas Williams <Nicolas.Williams@sun.com> Tue, 06 October 2009 23:50 UTC
Return-Path: <Nicolas.Williams@sun.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 494873A6818 for <tls@core3.amsl.com>; Tue, 6 Oct 2009 16:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.887
X-Spam-Level:
X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GWBeUdqjvQwu for <tls@core3.amsl.com>; Tue, 6 Oct 2009 16:50:22 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id B13663A6851 for <tls@ietf.org>; Tue, 6 Oct 2009 16:50:21 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n96NpxSu008760 for <tls@ietf.org>; Tue, 6 Oct 2009 23:51:59 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n96NpxVq007839 for <tls@ietf.org>; Tue, 6 Oct 2009 17:51:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n96Neixu005334; Tue, 6 Oct 2009 18:40:44 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n96NehvB005333; Tue, 6 Oct 2009 18:40:43 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 06 Oct 2009 18:40:43 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20091006234043.GP887@Sun.COM>
References: <p0624087dc6efe84bcc54@[10.20.30.163]> <87bpkkd4tv.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87bpkkd4tv.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tls@ietf.org
Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Tue, 06 Oct 2009 23:50:23 -0000
On Tue, Oct 06, 2009 at 03:34:04PM +0200, Simon Josefsson wrote: > If these use-cases are intended to be realistic use-cases of the > extension (which doesn't seem clear to me), I believe the document needs > more work: it should suggest a structure of the PRF data so that servers > will understand what type of data the client sent. Compare for example > how RFC 5077 suggests a format. The document could even go further and > mandate a particular format, which would make the use-cases more likely > to interoperate, such as: This is effectively a channel binding input to TLS. Uses of a channel binding input are not limited to channel binding (which is not likely to be useful to TLS, even though channel binding to IPsec would clearly be feasible). For example, in SCRAM/GS2 we use GSS-API channel binding in the construction of a SASL mechanism to protect cleartext sent outside the GSS-API mechanism's tokens. A secure audit protocol in OpenSolaris uses GSS-API channel bindings to protect early application protocol version negotiation. And so on. I think this is likely to be particularly useful to StartTLS-type applications, as a way of integrity-protecting early application protocol version negotiation. I suspect this extension will also be particularly useful to DTLS applications, for similar reasons. Nico --
- [TLS] New draft: draft-solinas-tls-additional-prf… Paul Hoffman
- Re: [TLS] New draft: draft-solinas-tls-additional… Simon Josefsson
- Re: [TLS] New draft: draft-solinas-tls-additional… Michael Gray
- Re: [TLS] New draft: draft-solinas-tls-additional… Nicolas Williams
- Re: [TLS] New draft: draft-solinas-tls-additional… Paul Hoffman
- Re: [TLS] New draft: draft-solinas-tls-additional… Michael Gray
- Re: [TLS] New draft: draft-solinas-tls-additional… Paul Hoffman
- Re: [TLS] New draft: draft-solinas-tls-additional… Michael Gray
- Re: [TLS] New draft: draft-solinas-tls-additional… Pasi.Eronen
- Re: [TLS] New draft: draft-solinas-tls-additional… Michael D'Errico
- Re: [TLS] New draft: draft-solinas-tls-additional… Russ Housley
- Re: [TLS] New draft: draft-solinas-tls-additional… Paul Hoffman
- Re: [TLS] New draft: draft-solinas-tls-additional… Nicolas Williams
- Re: [TLS] New draft: draft-solinas-tls-additional… Pasi.Eronen