From simon@josefsson.org Thu Oct 1 03:59:15 2009 Return-Path: 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 395D33A682E for ; Thu, 1 Oct 2009 03:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 P7hm6X4cIJV7 for ; Thu, 1 Oct 2009 03:59:14 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 06C903A6767 for ; Thu, 1 Oct 2009 03:59:13 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n91B0Yj3006323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Oct 2009 13:00:36 +0200 From: Simon Josefsson To: martin.rex@sap.com References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA3@LLE2K7-BE01.mitll.ad.local> <200909301454.n8UEsEFw007520@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091001:tls@ietf.org::H5N47WOBNNjU6fSv:1q+3 X-Hashcash: 1:22:091001:martin.rex@sap.com::JSfKej+34ckVS93f:Bqne X-Hashcash: 1:22:091001:uri@ll.mit.edu::nCzOCSGN6MPjxMG/:Rggo Date: Thu, 01 Oct 2009 13:00:34 +0200 In-Reply-To: <200909301454.n8UEsEFw007520@fs4113.wdf.sap.corp> (Martin Rex's message of "Wed, 30 Sep 2009 16:54:14 +0200 (MEST)") Message-ID: <87ab0bwf8t.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 10:59:15 -0000 Martin Rex writes: > Blumenthal, Uri wrote: >> >> In my understanding, TLS-established server_name should be >> enforced by the server. >> >> And Martin - I couldn't disagree more with you. The whole point of >> using TLS is to enforce who can access what. So the client makes sure >> he accesses the right server, the server makes sure he grants access >> to the right pages on the right virtual host. And if your server >> doesn't do that - please kindly tell me what commercial or >> freeware product it is included in, so I can avoid buying or >> using it in the future. > > There seems to be a significant misunderstanding. > > The Host header field of an HTTP request is a detail of an > application protocol. The hostname conveyed by the TLS extension > server name indication (SNI) happens at a competely different > protocol layer. > > The difference becomes obvious when you add reverse proxies > into the picture (those which terminate the TLS wrapping). > > Conceptually, the Host: header field of a HTTP request is > part of the URL. If a reverse proxy perform URL rewriting, > it may as well have to rewrite Host: header fields. That > depends entirely on the backend architecture of each > particular software installation. > > > Whether or not an application may want to make consistency > checks between a Host: Header field and a hostname received > via SNI at the specific point of the backend architecture > where TLS was terminated depends entirely on the backend > architecture, and is an application issue. I believe this wording in RFC 4366bis makes it a TLS issue: If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. I believe there are two options: 1) Either remove all requirements on application behaviour from 4366bis (including the text above) and explicitly defer such discussions to other documents. 2) Add the text I proposed to make servers actually validate proper client behaviour. I went for 2) assuming that the text above was intentional, but I share your arguments for going with approach 1). /Simon From uri@ll.mit.edu Thu Oct 1 04:54:12 2009 Return-Path: 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 C2E133A69CA for ; Thu, 1 Oct 2009 04:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 L7CRXaU-cO4O for ; Thu, 1 Oct 2009 04:54:12 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id CE3E73A68A5 for ; Thu, 1 Oct 2009 04:54:11 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n91BtTsT010831; Thu, 1 Oct 2009 07:55:29 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAcgaiIb; Thu Oct 1 07:44:29 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 1 Oct 2009 07:44:29 -0400 From: "Blumenthal, Uri" To: "'simon@josefsson.org'" , "'martin.rex@sap.com'" Date: Thu, 1 Oct 2009 07:44:20 -0400 Thread-Topic: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Thread-Index: AcpChmwiemOoDs36RvChbb13kLtWqQABhv2i Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'tls@ietf.org'" Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 11:54:12 -0000 SSBzdXBwb3J0IG9wdGlvbiAoMikgYW5kIGFtIGFnYWluc3Qgb3B0aW9uKDEpLCBmb3IgcmVhc29u cyBleHByZXNzZWQgaW4gZWFybGllciBlbWFpbHMuDQoNClRueCENCg0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBTaW1vbiBKb3NlZnNzb24gPHNpbW9uQGpvc2Vmc3Nvbi5v cmc+DQpUbzogbWFydGluLnJleEBzYXAuY29tIDxtYXJ0aW4ucmV4QHNhcC5jb20+DQpDYzogQmx1 bWVudGhhbCwgVXJpOyB0bHNAaWV0Zi5vcmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFRodSBPY3Qg MDEgMDc6MDA6MzQgMjAwOQpTdWJqZWN0OiBSZTogTGFzdCBDYWxsOiBkcmFmdC1pZXRmLXRscy1y ZmM0MzY2LWJpcyAoVHJhbnNwb3J0IExheWVyDQoNCk1hcnRpbiBSZXggPE1hcnRpbi5SZXhAc2Fw LmNvbT4gd3JpdGVzOg0KDQo+IEJsdW1lbnRoYWwsIFVyaSB3cm90ZToNCj4+IA0KPj4gSW4gbXkg dW5kZXJzdGFuZGluZywgVExTLWVzdGFibGlzaGVkIHNlcnZlcl9uYW1lIHNob3VsZCBiZQ0KPj4g ZW5mb3JjZWQgYnkgdGhlIHNlcnZlci4NCj4+IA0KPj4gQW5kIE1hcnRpbiAtIEkgY291bGRuJ3Qg ZGlzYWdyZWUgbW9yZSB3aXRoIHlvdS4gVGhlIHdob2xlIHBvaW50IG9mDQo+PiB1c2luZyBUTFMg aXMgdG8gZW5mb3JjZSB3aG8gY2FuIGFjY2VzcyB3aGF0LiBTbyB0aGUgY2xpZW50IG1ha2VzIHN1 cmUNCj4+IGhlIGFjY2Vzc2VzIHRoZSByaWdodCBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgbWFrZXMgc3Vy ZSBoZSBncmFudHMgYWNjZXNzDQo+PiB0byB0aGUgcmlnaHQgcGFnZXMgb24gdGhlIHJpZ2h0IHZp cnR1YWwgaG9zdC4gQW5kIGlmIHlvdXIgc2VydmVyDQo+PiBkb2Vzbid0IGRvIHRoYXQgLSBwbGVh c2Uga2luZGx5IHRlbGwgbWUgd2hhdCBjb21tZXJjaWFsIG9yDQo+PiBmcmVld2FyZSBwcm9kdWN0 IGl0IGlzIGluY2x1ZGVkIGluLCBzbyBJIGNhbiBhdm9pZCBidXlpbmcgb3INCj4+IHVzaW5nIGl0 IGluIHRoZSBmdXR1cmUuDQo+DQo+IFRoZXJlIHNlZW1zIHRvIGJlIGEgc2lnbmlmaWNhbnQgbWlz dW5kZXJzdGFuZGluZy4NCj4NCj4gVGhlIEhvc3QgaGVhZGVyIGZpZWxkIG9mIGFuIEhUVFAgcmVx dWVzdCBpcyBhIGRldGFpbCBvZiBhbg0KPiBhcHBsaWNhdGlvbiBwcm90b2NvbC4gIFRoZSBob3N0 bmFtZSBjb252ZXllZCBieSB0aGUgVExTIGV4dGVuc2lvbg0KPiBzZXJ2ZXIgbmFtZSBpbmRpY2F0 aW9uIChTTkkpIGhhcHBlbnMgYXQgYSBjb21wZXRlbHkgZGlmZmVyZW50DQo+IHByb3RvY29sIGxh eWVyLg0KPg0KPiBUaGUgZGlmZmVyZW5jZSBiZWNvbWVzIG9idmlvdXMgd2hlbiB5b3UgYWRkIHJl dmVyc2UgcHJveGllcw0KPiBpbnRvIHRoZSBwaWN0dXJlICh0aG9zZSB3aGljaCB0ZXJtaW5hdGUg dGhlIFRMUyB3cmFwcGluZykuDQo+DQo+IENvbmNlcHR1YWxseSwgdGhlIEhvc3Q6IGhlYWRlciBm aWVsZCBvZiBhIEhUVFAgcmVxdWVzdCBpcw0KPiBwYXJ0IG9mIHRoZSBVUkwuICBJZiBhIHJldmVy c2UgcHJveHkgcGVyZm9ybSBVUkwgcmV3cml0aW5nLA0KPiBpdCBtYXkgYXMgd2VsbCBoYXZlIHRv IHJld3JpdGUgSG9zdDogaGVhZGVyIGZpZWxkcy4gIFRoYXQNCj4gZGVwZW5kcyBlbnRpcmVseSBv biB0aGUgYmFja2VuZCBhcmNoaXRlY3R1cmUgb2YgZWFjaA0KPiBwYXJ0aWN1bGFyIHNvZnR3YXJl IGluc3RhbGxhdGlvbi4NCj4NCj4NCj4gV2hldGhlciBvciBub3QgYW4gYXBwbGljYXRpb24gbWF5 IHdhbnQgdG8gbWFrZSBjb25zaXN0ZW5jeQ0KPiBjaGVja3MgYmV0d2VlbiBhIEhvc3Q6IEhlYWRl ciBmaWVsZCBhbmQgYSBob3N0bmFtZSByZWNlaXZlZA0KPiB2aWEgU05JIGF0IHRoZSBzcGVjaWZp YyBwb2ludCBvZiB0aGUgYmFja2VuZCBhcmNoaXRlY3R1cmUNCj4gd2hlcmUgVExTIHdhcyB0ZXJt aW5hdGVkIGRlcGVuZHMgZW50aXJlbHkgb24gdGhlIGJhY2tlbmQNCj4gYXJjaGl0ZWN0dXJlLCBh bmQgaXMgYW4gYXBwbGljYXRpb24gaXNzdWUuDQoNCkkgYmVsaWV2ZSB0aGlzIHdvcmRpbmcgaW4g UkZDIDQzNjZiaXMgbWFrZXMgaXQgYSBUTFMgaXNzdWU6DQoNCiAgIElmIHRoZSBzZXJ2ZXJfbmFt ZSBpcyBlc3RhYmxpc2hlZCBpbiB0aGUgVExTIHNlc3Npb24gaGFuZHNoYWtlLCB0aGUNCiAgIGNs aWVudCBTSE9VTEQgTk9UIGF0dGVtcHQgdG8gcmVxdWVzdCBhIGRpZmZlcmVudCBzZXJ2ZXIgbmFt ZSBhdCB0aGUNCiAgIGFwcGxpY2F0aW9uIGxheWVyLg0KDQpJIGJlbGlldmUgdGhlcmUgYXJlIHR3 byBvcHRpb25zOg0KDQoxKSBFaXRoZXIgcmVtb3ZlIGFsbCByZXF1aXJlbWVudHMgb24gYXBwbGlj YXRpb24gYmVoYXZpb3VyIGZyb20gNDM2NmJpcw0KICAgKGluY2x1ZGluZyB0aGUgdGV4dCBhYm92 ZSkgYW5kIGV4cGxpY2l0bHkgZGVmZXIgc3VjaCBkaXNjdXNzaW9ucyB0bw0KICAgb3RoZXIgZG9j dW1lbnRzLg0KDQoyKSBBZGQgdGhlIHRleHQgSSBwcm9wb3NlZCB0byBtYWtlIHNlcnZlcnMgYWN0 dWFsbHkgdmFsaWRhdGUgcHJvcGVyDQogICBjbGllbnQgYmVoYXZpb3VyLg0KDQpJIHdlbnQgZm9y IDIpIGFzc3VtaW5nIHRoYXQgdGhlIHRleHQgYWJvdmUgd2FzIGludGVudGlvbmFsLCBidXQgSSBz aGFyZQ0KeW91ciBhcmd1bWVudHMgZm9yIGdvaW5nIHdpdGggYXBwcm9hY2ggMSkuDQoNCi9TaW1v bg0K From yngve@opera.com Thu Oct 1 07:00:09 2009 Return-Path: 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 BCBBC28C11A for ; Thu, 1 Oct 2009 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.813 X-Spam-Level: X-Spam-Status: No, score=-6.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, 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 F0ZRP+iIRIqc for ; Thu, 1 Oct 2009 07:00:08 -0700 (PDT) Received: from smtp.opera.com (sam.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 6833328C0FC for ; Thu, 1 Oct 2009 07:00:08 -0700 (PDT) Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n91E1Pos005789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Oct 2009 14:01:31 GMT Date: Thu, 01 Oct 2009 16:01:28 +0200 To: martin.rex@sap.com From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp> User-Agent: Opera Mail/9.65 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] rfc4366-bis: Certificate Status for intermediate CA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yngve@opera.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 14:00:09 -0000 On Tue, 29 Sep 2009 02:59:23 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> However, sending two CertificateStatusRequest extensions in the same >> ClientHello is forbidden by RFC 5246 sec 7.4.1.4: >> >> When multiple extensions of different types are present in the >> ClientHello or ServerHello messages, the extensions MAY appear in >> any >> order. There MUST NOT be more than one extension of the same type. > > How about always using the existing extension for the OCSP response > for the server certificate, and using a new extension for OCSP responses > for other certificates (like intermediate CA certs), probably unsorted. > > PKIs with flat hierarchies (Server-cert signed by self-signed CA cert) > use only the original extension. Servers with certs from multi-level > CA hierarchies need to use the new extension if they want to send > additional OCSP responses. If OCSP was the only game in town, to the end of time, that might work, but TLS needs to be able to handle other PKI and revocation structures than X.509/PKIX and OCSP. The main problem here, as I understand it, is that the CertificateStatusRequest was (or at least gives every appearance to be) intended to support *multiple* certificate status methods, not just OCSP. Why else use an enum for the type? With the language in RFC 5246 (quoted above) and previous versions of Extensions, a client is not able to (in a compliant fashion) to indicate to the server that it supports more than one status method, for example the methods OCSP, YACSP (Yet Another Certificate Status Protocol) and TTCSP (The Third Certificate Status Protocol), of which it prefer TTCSP. This is important because (future) servers may support only some of the alternatives, not all of them, and the client have no way to determine which protocol the server supports ahead of sending the Client Hello. To the best of my understanding, the only realistic way to fix this problem is to create a new extension, "status_request_v2", which fixes the problem by defining a list. IMO it is going to be difficult to make a good errata that changes the RFC 5246 language without making it a free for all, causing interpretation problems, and it is not possible to update the status_request extension so that is uses CertificateStatusRequestList, since there are already implementation (server and client) released that uses the current method. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From Martin.Rex@sap.com Thu Oct 1 07:53:32 2009 Return-Path: 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 E6C5C3A684B for ; Thu, 1 Oct 2009 07:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.221, 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 T-p4R3MhISBf for ; Thu, 1 Oct 2009 07:53:32 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E54003A67A8 for ; Thu, 1 Oct 2009 07:53:31 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n91EssVa007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 16:54:54 +0200 (MEST) From: Martin Rex Message-Id: <200910011454.n91EsqXT002903@fs4113.wdf.sap.corp> To: martin.rex@sap.com Date: Thu, 1 Oct 2009 16:54:52 +0200 (MEST) In-Reply-To: <200909290059.n8T0xNqH020479@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 29, 9 02:59:23 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] rfc4366-bis: Certificate Status for intermediate CA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 14:53:33 -0000 Martin Rex wrote: > > Yngve N. Pettersen wrote: > > > > However, sending two CertificateStatusRequest extensions in the same > > ClientHello is forbidden by RFC 5246 sec 7.4.1.4: > > > > When multiple extensions of different types are present in the > > ClientHello or ServerHello messages, the extensions MAY appear in any > > order. There MUST NOT be more than one extension of the same type. > > How about always using the existing extension for the OCSP response > for the server certificate, and using a new extension for OCSP responses > for other certificates (like intermediate CA certs), probably unsorted. > > PKIs with flat hierarchies (Server-cert signed by self-signed CA cert) > use only the original extension. Servers with certs from multi-level > CA hierarchies need to use the new extension if they want to send > additional OCSP responses. I mis-explained myself: Servers would always use the existing TLS extension to convey the OCSP extension for their end entity cert. If Servers want to convey additional OCSP responses (for intermediate CA certs and maybe from different cert paths), they would additionally have to use a new extension. -Martin From jsalowey@cisco.com Thu Oct 1 09:15:39 2009 Return-Path: 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 29F5D3A68CE for ; Thu, 1 Oct 2009 09:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 QWgvaSZaooC0 for ; Thu, 1 Oct 2009 09:15:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E707D3A6898 for ; Thu, 1 Oct 2009 09:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3917; q=dns/txt; s=sjiport01001; t=1254413824; x=1255623424; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20RE:=20[TLS]=20Last=20Call:=20draft-ietf -tls-rfc4366-bis=20(Transport=20Layer|Date:=20Thu,=201=20 Oct=202009=2009:17:02=20-0700|Message-ID:=20 |To:=20"Blumenthal,=20Uri"=20,=20,=0D=0A=20=20=20=20=20=20=20=20|Cc:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6B A5@LLE2K7-BE01.mitll.ad.local>|References:=20<90E934FC4BB C1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.loca l>; bh=yqsG0zLR3bl1AlhQqwC+OHg8aE1VPGeCpYznwd97+BU=; b=AwMUark6ELs/igeJeEGCKt47RCQus5FTK5ptJWZuvQWdXkCBAns27+tC pNizadt8bRLFAig4NuTKxqZRBoETfUNb4m8V6ehz1MJJibJahhgfn/R9u N1cHucG0v2PGcFWq2qJ8FlYgnf3XP+UxjR+1gdygWW67GgLCAOo4Y/Q1G U=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jsalowey@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABdzxEqrR7MV/2dsb2JhbAC/WIhbAY9QBoQpig4 X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="249705998" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2009 16:17:03 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91GH3Dc008852; Thu, 1 Oct 2009 09:17:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n91GH3iF001309; Thu, 1 Oct 2009 16:17:03 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 09:17:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Oct 2009 09:17:02 -0700 Message-ID: In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Thread-Index: AcpChmwiemOoDs36RvChbb13kLtWqQABhv2iAAkJAoA= References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> From: "Joseph Salowey (jsalowey)" To: "Blumenthal, Uri" , , X-OriginalArrivalTime: 01 Oct 2009 16:17:03.0297 (UTC) FILETIME=[9CA23B10:01CA42B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3917; t=1254413823; x=1255277823; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20Last=20Call=3A=20draft-ietf-tls -rfc4366-bis=20(Transport=20Layer |Sender:=20; bh=yqsG0zLR3bl1AlhQqwC+OHg8aE1VPGeCpYznwd97+BU=; b=UTtGYgb1YUsHqLy0tEiYxkXt1umlVqHqj/qONtTVBIXfmosEDSbQijxNWI USnQVYEgYn167eZ038wgjjMctLvz0X46vbbEpDDD5ToOpq56Tj7KfeUGA/Cb T+NMYc4fS4WrQDRB3yWxTPC+K06EtrRfdctMyIGTS2xz6n7TEb5yk=; Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:15:39 -0000 I don't think option 1 is an appropriate change for this document, although I could be convinced otherwise because I don't think the SHOULD is very enlightening. =20 For option 2 I would prefer text that explains the SHOULD, maybe something like: "Since it is possible for a client to present a different server_name in the application protocol, application server implementations that rely upon these names being the same MUST check to make sure the client did not present a different name in the application protocol."=20 Joe > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Blumenthal, Uri > Sent: Thursday, October 01, 2009 4:44 AM > To: 'simon@josefsson.org'; 'martin.rex@sap.com' > Cc: 'tls@ietf.org' > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis=20 > (Transport Layer >=20 > I support option (2) and am against option(1), for reasons=20 > expressed in earlier emails. >=20 > Tnx! >=20 >=20 > ----- Original Message ----- > From: Simon Josefsson > To: martin.rex@sap.com > Cc: Blumenthal, Uri; tls@ietf.org > Sent: Thu Oct 01 07:00:34 2009 > Subject: Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer >=20 > Martin Rex writes: >=20 > > Blumenthal, Uri wrote: > >>=20 > >> In my understanding, TLS-established server_name should be=20 > enforced=20 > >> by the server. > >>=20 > >> And Martin - I couldn't disagree more with you. The whole point of=20 > >> using TLS is to enforce who can access what. So the client=20 > makes sure=20 > >> he accesses the right server, the server makes sure he=20 > grants access=20 > >> to the right pages on the right virtual host. And if your server=20 > >> doesn't do that - please kindly tell me what commercial or=20 > freeware=20 > >> product it is included in, so I can avoid buying or using=20 > it in the=20 > >> future. > > > > There seems to be a significant misunderstanding. > > > > The Host header field of an HTTP request is a detail of an=20 > application=20 > > protocol. The hostname conveyed by the TLS extension server name=20 > > indication (SNI) happens at a competely different protocol layer. > > > > The difference becomes obvious when you add reverse proxies=20 > into the=20 > > picture (those which terminate the TLS wrapping). > > > > Conceptually, the Host: header field of a HTTP request is=20 > part of the=20 > > URL. If a reverse proxy perform URL rewriting, it may as=20 > well have to=20 > > rewrite Host: header fields. That depends entirely on the backend=20 > > architecture of each particular software installation. > > > > > > Whether or not an application may want to make consistency checks=20 > > between a Host: Header field and a hostname received via SNI at the=20 > > specific point of the backend architecture where TLS was terminated=20 > > depends entirely on the backend architecture, and is an application=20 > > issue. >=20 > I believe this wording in RFC 4366bis makes it a TLS issue: >=20 > If the server_name is established in the TLS session handshake, the > client SHOULD NOT attempt to request a different server name at the > application layer. >=20 > I believe there are two options: >=20 > 1) Either remove all requirements on application behaviour=20 > from 4366bis > (including the text above) and explicitly defer such discussions to > other documents. >=20 > 2) Add the text I proposed to make servers actually validate proper > client behaviour. >=20 > I went for 2) assuming that the text above was intentional,=20 > but I share your arguments for going with approach 1). >=20 > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From stpeter@stpeter.im Thu Oct 1 09:27:27 2009 Return-Path: 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 C3DB628C143 for ; Thu, 1 Oct 2009 09:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] 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 qDAbykZlEXcS for ; Thu, 1 Oct 2009 09:27:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CFFC13A6A11 for ; Thu, 1 Oct 2009 09:27:26 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F45A4007B; Thu, 1 Oct 2009 10:28:51 -0600 (MDT) Message-ID: <4AC4D8C3.4040306@stpeter.im> Date: Thu, 01 Oct 2009 10:28:51 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:27:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/1/09 10:17 AM, Joseph Salowey (jsalowey) wrote: > I don't think option 1 is an appropriate change for this document, > although I could be convinced otherwise because I don't think the SHOULD > is very enlightening. I now agree that we need to say something about this in the TLS spec. > For option 2 I would prefer text that explains the SHOULD, maybe > something like: > > "Since it is possible for a client to present a different server_name in > the application protocol, application server implementations that rely > upon these names being the same MUST check to make sure the client did > not present a different name in the application protocol." +1 Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrE2MIACgkQNL8k5A2w/vw9KACgrEz9EQ5YK+5Hf3t0RK3o7LYu dBoAn1Dp0RP8b8/cReUsS6xK/CGS5ee6 =3YP3 -----END PGP SIGNATURE----- From simon@josefsson.org Thu Oct 1 09:48:16 2009 Return-Path: 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 0037628C120 for ; Thu, 1 Oct 2009 09:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 QHnL4SMkY-7f for ; Thu, 1 Oct 2009 09:48:15 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id ADB6628C125 for ; Thu, 1 Oct 2009 09:48:14 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n91GnWnv015080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Oct 2009 18:49:34 +0200 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BA5@LLE2K7-BE01.mitll.ad.local> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091001:martin.rex@sap.com::2pfiYREofjnyZKSn:42Ym X-Hashcash: 1:22:091001:jsalowey@cisco.com:://mC6gSyRdrqvc86:X0X1 X-Hashcash: 1:22:091001:tls@ietf.org::R9BBLBTBvnGF1/5y:Vg1e X-Hashcash: 1:22:091001:uri@ll.mit.edu::V7pcIZ7TrUrw0GY0:wbQV Date: Thu, 01 Oct 2009 18:49:32 +0200 In-Reply-To: (Joseph Salowey's message of "Thu, 1 Oct 2009 09:17:02 -0700") Message-ID: <87r5tnt5yb.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:48:16 -0000 "Joseph Salowey (jsalowey)" writes: > I don't think option 1 is an appropriate change for this document, > although I could be convinced otherwise because I don't think the SHOULD > is very enlightening. > > For option 2 I would prefer text that explains the SHOULD, maybe > something like: > > "Since it is possible for a client to present a different server_name in > the application protocol, application server implementations that rely > upon these names being the same MUST check to make sure the client did > not present a different name in the application protocol." I believe that would resolve my concern. Thanks, /Simon > Joe > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On >> Behalf Of Blumenthal, Uri >> Sent: Thursday, October 01, 2009 4:44 AM >> To: 'simon@josefsson.org'; 'martin.rex@sap.com' >> Cc: 'tls@ietf.org' >> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis >> (Transport Layer >> >> I support option (2) and am against option(1), for reasons >> expressed in earlier emails. >> >> Tnx! >> >> >> ----- Original Message ----- >> From: Simon Josefsson >> To: martin.rex@sap.com >> Cc: Blumenthal, Uri; tls@ietf.org >> Sent: Thu Oct 01 07:00:34 2009 >> Subject: Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer >> >> Martin Rex writes: >> >> > Blumenthal, Uri wrote: >> >> >> >> In my understanding, TLS-established server_name should be >> enforced >> >> by the server. >> >> >> >> And Martin - I couldn't disagree more with you. The whole point of >> >> using TLS is to enforce who can access what. So the client >> makes sure >> >> he accesses the right server, the server makes sure he >> grants access >> >> to the right pages on the right virtual host. And if your server >> >> doesn't do that - please kindly tell me what commercial or >> freeware >> >> product it is included in, so I can avoid buying or using >> it in the >> >> future. >> > >> > There seems to be a significant misunderstanding. >> > >> > The Host header field of an HTTP request is a detail of an >> application >> > protocol. The hostname conveyed by the TLS extension server name >> > indication (SNI) happens at a competely different protocol layer. >> > >> > The difference becomes obvious when you add reverse proxies >> into the >> > picture (those which terminate the TLS wrapping). >> > >> > Conceptually, the Host: header field of a HTTP request is >> part of the >> > URL. If a reverse proxy perform URL rewriting, it may as >> well have to >> > rewrite Host: header fields. That depends entirely on the backend >> > architecture of each particular software installation. >> > >> > >> > Whether or not an application may want to make consistency checks >> > between a Host: Header field and a hostname received via SNI at the >> > specific point of the backend architecture where TLS was terminated >> > depends entirely on the backend architecture, and is an application >> > issue. >> >> I believe this wording in RFC 4366bis makes it a TLS issue: >> >> If the server_name is established in the TLS session handshake, the >> client SHOULD NOT attempt to request a different server name at the >> application layer. >> >> I believe there are two options: >> >> 1) Either remove all requirements on application behaviour >> from 4366bis >> (including the text above) and explicitly defer such discussions to >> other documents. >> >> 2) Add the text I proposed to make servers actually validate proper >> client behaviour. >> >> I went for 2) assuming that the text above was intentional, >> but I share your arguments for going with approach 1). >> >> /Simon >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From uri@ll.mit.edu Thu Oct 1 09:51:36 2009 Return-Path: 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 044283A6A6F for ; Thu, 1 Oct 2009 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 h34azof80PJm for ; Thu, 1 Oct 2009 09:51:35 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id CE9DC3A6855 for ; Thu, 1 Oct 2009 09:51:34 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n91Gqdr2027216; Thu, 1 Oct 2009 12:52:39 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAACTaqMm; Thu Oct 1 12:41:49 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 1 Oct 2009 12:41:49 -0400 From: "Blumenthal, Uri" To: "'stpeter@stpeter.im'" , "'jsalowey@cisco.com'" Date: Thu, 1 Oct 2009 12:41:40 -0400 Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Thread-Index: AcpCtEhyU7xLDYySRHeHs+o8WGfjSgAAclj/ Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BAB@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'simon@josefsson.org'" , "'tls@ietf.org'" Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:51:36 -0000 WWVzLCArMS4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBQZXRlciBT YWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPg0KVG86IEpvc2VwaCBTYWxvd2V5IChqc2Fs b3dleSkgPGpzYWxvd2V5QGNpc2NvLmNvbT4NCkNjOiBCbHVtZW50aGFsLCBVcmk7IHNpbW9uQGpv c2Vmc3Nvbi5vcmcgPHNpbW9uQGpvc2Vmc3Nvbi5vcmc+OyBtYXJ0aW4ucmV4QHNhcC5jb20gPG1h cnRpbi5yZXhAc2FwLmNvbT47IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogVGh1 IE9jdCAwMSAxMjoyODo1MSAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBMYXN0IENhbGw6IGRyYWZ0 LWlldGYtdGxzLXJmYzQzNjYtYmlzIChUcmFuc3BvcnQgTGF5ZXINCg0KLS0tLS1CRUdJTiBQR1Ag U0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiAxMC8xLzA5IDEwOjE3IEFNLCBK b3NlcGggU2Fsb3dleSAoanNhbG93ZXkpIHdyb3RlOg0KPiBJIGRvbid0IHRoaW5rIG9wdGlvbiAx IGlzIGFuIGFwcHJvcHJpYXRlIGNoYW5nZSBmb3IgdGhpcyBkb2N1bWVudCwNCj4gYWx0aG91Z2gg SSBjb3VsZCBiZSBjb252aW5jZWQgb3RoZXJ3aXNlIGJlY2F1c2UgSSBkb24ndCB0aGluayB0aGUg U0hPVUxEDQo+IGlzIHZlcnkgZW5saWdodGVuaW5nLg0KDQpJIG5vdyBhZ3JlZSB0aGF0IHdlIG5l ZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCB0aGlzIGluIHRoZSBUTFMgc3BlYy4NCg0KPiBGb3Ig b3B0aW9uIDIgSSB3b3VsZCBwcmVmZXIgdGV4dCB0aGF0IGV4cGxhaW5zIHRoZSBTSE9VTEQsIG1h eWJlDQo+IHNvbWV0aGluZyBsaWtlOg0KPiANCj4gIlNpbmNlIGl0IGlzIHBvc3NpYmxlIGZvciBh IGNsaWVudCB0byBwcmVzZW50IGEgZGlmZmVyZW50IHNlcnZlcl9uYW1lIGluDQo+IHRoZSBhcHBs aWNhdGlvbiBwcm90b2NvbCwgYXBwbGljYXRpb24gc2VydmVyIGltcGxlbWVudGF0aW9ucyB0aGF0 IHJlbHkNCj4gdXBvbiB0aGVzZSBuYW1lcyBiZWluZyB0aGUgc2FtZSBNVVNUIGNoZWNrIHRvIG1h a2Ugc3VyZSB0aGUgY2xpZW50IGRpZA0KPiBub3QgcHJlc2VudCBhIGRpZmZlcmVudCBuYW1lIGlu IHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbC4iIA0KDQorMQ0KDQpQZXRlcg0KDQotIC0tDQpQZXRl ciBTYWludC1BbmRyZQ0KaHR0cHM6Ly9zdHBldGVyLmltLw0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJ R05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjggKERhcndpbikNCkNvbW1lbnQ6IFVz aW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLw0KDQpp RVlFQVJFQ0FBWUZBa3JFMk1JQUNna1FOTDhrNUEydy92dzlLQUNnckV6OUVRNVlLKzVIZjN0MFJL M283TFl1DQpkQm9BbjFEcDBSUDhiOC9jUmVVc1M2eEsvQ0dTNWVlNg0KPTNZUDMNCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQ0K From uri@ll.mit.edu Thu Oct 1 09:55:58 2009 Return-Path: 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 6638F3A69C2 for ; Thu, 1 Oct 2009 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 8Cox5Mqlhjy8 for ; Thu, 1 Oct 2009 09:55:58 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 100043A68B3 for ; Thu, 1 Oct 2009 09:55:57 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n91GvFWe008045; Thu, 1 Oct 2009 12:57:15 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAACTaqMm; Thu Oct 1 12:41:49 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 1 Oct 2009 12:41:49 -0400 From: "Blumenthal, Uri" To: "'stpeter@stpeter.im'" , "'jsalowey@cisco.com'" Date: Thu, 1 Oct 2009 12:41:40 -0400 Thread-Topic: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Thread-Index: AcpCtEhyU7xLDYySRHeHs+o8WGfjSgAAclj/ Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BAB@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'simon@josefsson.org'" , "'tls@ietf.org'" Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:55:58 -0000 WWVzLCArMS4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBQZXRlciBT YWludC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPg0KVG86IEpvc2VwaCBTYWxvd2V5IChqc2Fs b3dleSkgPGpzYWxvd2V5QGNpc2NvLmNvbT4NCkNjOiBCbHVtZW50aGFsLCBVcmk7IHNpbW9uQGpv c2Vmc3Nvbi5vcmcgPHNpbW9uQGpvc2Vmc3Nvbi5vcmc+OyBtYXJ0aW4ucmV4QHNhcC5jb20gPG1h cnRpbi5yZXhAc2FwLmNvbT47IHRsc0BpZXRmLm9yZyA8dGxzQGlldGYub3JnPg0KU2VudDogVGh1 IE9jdCAwMSAxMjoyODo1MSAyMDA5ClN1YmplY3Q6IFJlOiBbVExTXSBMYXN0IENhbGw6IGRyYWZ0 LWlldGYtdGxzLXJmYzQzNjYtYmlzIChUcmFuc3BvcnQgTGF5ZXINCg0KLS0tLS1CRUdJTiBQR1Ag U0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiAxMC8xLzA5IDEwOjE3IEFNLCBK b3NlcGggU2Fsb3dleSAoanNhbG93ZXkpIHdyb3RlOg0KPiBJIGRvbid0IHRoaW5rIG9wdGlvbiAx IGlzIGFuIGFwcHJvcHJpYXRlIGNoYW5nZSBmb3IgdGhpcyBkb2N1bWVudCwNCj4gYWx0aG91Z2gg SSBjb3VsZCBiZSBjb252aW5jZWQgb3RoZXJ3aXNlIGJlY2F1c2UgSSBkb24ndCB0aGluayB0aGUg U0hPVUxEDQo+IGlzIHZlcnkgZW5saWdodGVuaW5nLg0KDQpJIG5vdyBhZ3JlZSB0aGF0IHdlIG5l ZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCB0aGlzIGluIHRoZSBUTFMgc3BlYy4NCg0KPiBGb3Ig b3B0aW9uIDIgSSB3b3VsZCBwcmVmZXIgdGV4dCB0aGF0IGV4cGxhaW5zIHRoZSBTSE9VTEQsIG1h eWJlDQo+IHNvbWV0aGluZyBsaWtlOg0KPiANCj4gIlNpbmNlIGl0IGlzIHBvc3NpYmxlIGZvciBh IGNsaWVudCB0byBwcmVzZW50IGEgZGlmZmVyZW50IHNlcnZlcl9uYW1lIGluDQo+IHRoZSBhcHBs aWNhdGlvbiBwcm90b2NvbCwgYXBwbGljYXRpb24gc2VydmVyIGltcGxlbWVudGF0aW9ucyB0aGF0 IHJlbHkNCj4gdXBvbiB0aGVzZSBuYW1lcyBiZWluZyB0aGUgc2FtZSBNVVNUIGNoZWNrIHRvIG1h a2Ugc3VyZSB0aGUgY2xpZW50IGRpZA0KPiBub3QgcHJlc2VudCBhIGRpZmZlcmVudCBuYW1lIGlu IHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbC4iIA0KDQorMQ0KDQpQZXRlcg0KDQotIC0tDQpQZXRl ciBTYWludC1BbmRyZQ0KaHR0cHM6Ly9zdHBldGVyLmltLw0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJ R05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjggKERhcndpbikNCkNvbW1lbnQ6IFVz aW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLw0KDQpp RVlFQVJFQ0FBWUZBa3JFMk1JQUNna1FOTDhrNUEydy92dzlLQUNnckV6OUVRNVlLKzVIZjN0MFJL M283TFl1DQpkQm9BbjFEcDBSUDhiOC9jUmVVc1M2eEsvQ0dTNWVlNg0KPTNZUDMNCi0tLS0tRU5E IFBHUCBTSUdOQVRVUkUtLS0tLQ0K From Martin.Rex@sap.com Thu Oct 1 12:06:44 2009 Return-Path: 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 C7CF728C1A2 for ; Thu, 1 Oct 2009 12:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 7evcYSODNma8 for ; Thu, 1 Oct 2009 12:06:44 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id CDBF628C19A for ; Thu, 1 Oct 2009 12:06:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n91J85jh029972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Oct 2009 21:08:05 +0200 (MEST) From: Martin Rex Message-Id: <200910011908.n91J84gC018022@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 1 Oct 2009 21:08:04 +0200 (MEST) In-Reply-To: from "Joseph Salowey" at Oct 1, 9 09:17:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: simon@josefsson.org, tls@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: martin.rex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 19:06:44 -0000 Joseph Salowey wrote: > > For option 2 I would prefer text that explains the SHOULD, maybe > something like: > > "Since it is possible for a client to present a different server_name in > the application protocol, application server implementations that rely > upon these names being the same MUST check to make sure the client did > not present a different name in the application protocol." OK. +1 -Martin From wwwrun@core3.amsl.com Mon Oct 5 09:27:04 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8C1B43A6873; Mon, 5 Oct 2009 09:27:04 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091005162704.8C1B43A6873@core3.amsl.com> Date: Mon, 5 Oct 2009 09:27:04 -0700 (PDT) Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 16:27:04 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Channel Bindings for TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15087&rfc_flag=0 From paul.hoffman@vpnc.org Mon Oct 5 11:16:26 2009 Return-Path: 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 DEC1C3A6994 for ; Mon, 5 Oct 2009 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=0.848, 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 iIHx0aBAdZS2 for ; Mon, 5 Oct 2009 11:16:26 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 155A63A6A26 for ; Mon, 5 Oct 2009 11:16:26 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n95IHxql038720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Oct 2009 11:18:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 5 Oct 2009 11:17:58 -0700 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:16:27 -0000 >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Additional PRF Inputs for TLS > > Author(s) : J. Solinas, P. Hoffman > Filename : draft-solinas-tls-additional-prf-input-00.txt > Pages : 6 > Date : 2009-10-5 > >This document describes a mechanism for using additional PRF inputs > with Transport Layer Security (TLS) and Datagram TLS (DTLS). > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-input-00.txt Greetings again. We would like to hear input on this draft from the TLS community. The basic idea is an extension that would allow the two parties to give additional information that is directly mixed into the master secret through the PRF. --Paul Hoffman, Director --VPN Consortium From simon@josefsson.org Tue Oct 6 06:32:34 2009 Return-Path: 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 A42BF3A691E for ; Tue, 6 Oct 2009 06:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] 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 H1SxHOQal7cy for ; Tue, 6 Oct 2009 06:32:33 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4D5493A67AE for ; Tue, 6 Oct 2009 06:32:32 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n96DY4vZ005623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Oct 2009 15:34:06 +0200 From: Simon Josefsson To: Paul Hoffman References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091006:tls@ietf.org::r5AFORus48LDyU5w:5yqv X-Hashcash: 1:22:091006:paul.hoffman@vpnc.org::+oDI3kZdVQmc8rIX:bxOm Date: Tue, 06 Oct 2009 15:34:04 +0200 In-Reply-To: (Paul Hoffman's message of "Mon\, 5 Oct 2009 11\:17\:58 -0700") Message-ID: <87bpkkd4tv.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 13:32:34 -0000 Paul Hoffman writes: >>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-input-00.txt > > Greetings again. We would like to hear input on this draft from the > TLS community. The basic idea is an extension that would allow the two > parties to give additional information that is directly mixed into the > master secret through the PRF. The document seems fine to me. As far as I can tell, any implementation (including mine) of draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with draft-solinas-tls-additional-prf-input-00.txt, and that is good. The two last examples in section 1.1 doesn't appear fully baked to me. Quoting: TLS servers may arrange for their clients to provide authentication data early in the protocol (such as an HMAC value computed over a fresh random value using a shared secret as the key) in order to authenticate the client as a member of a private network or as an additional means of mitigating the impact of a denial-of-service attack. Implementors may want to provide a mechanism for relaying identity and version information similar to the "Vendor ID Payload" used in ISAKMP [RFC2408]. 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: enum { entropy(0), (65535) } AdditionalPRFInputType; struct { AdditionalPRFInputType type; opaque value<0..2^16-1>; } AdditionalPRFInput; AdditionalPRFInput prfinputs<2..2^16-2>; The AdditionalPRFInputType could be a FCFS registry. The intention with the "entropy" field is that it should contain random data with no intended meaning, which appears to be the typical use-case. Other types can be allocated to signal the two use-cases in the example if/when needed. Alternatively, and considering the complexities in my proposed change, I would suggest that you remove other use cases than the one to provide additional entropy to the MS key computation and say that there is only one intended use-case for this extension. If other use-cases of the extension are important, they can be described in separate documents. Thanks, /Simon From mickgray@au1.ibm.com Tue Oct 6 16:34:35 2009 Return-Path: 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 E0DF73A683D for ; Tue, 6 Oct 2009 16:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 YPr-FkrNG-Tq for ; Tue, 6 Oct 2009 16:34:34 -0700 (PDT) Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id DE2F23A6407 for ; Tue, 6 Oct 2009 16:34:33 -0700 (PDT) Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id n96Na5IN032601 for ; Wed, 7 Oct 2009 10:36:05 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n96Na97r467002 for ; Wed, 7 Oct 2009 10:36:09 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n96Na8BE020899 for ; Wed, 7 Oct 2009 10:36:09 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av04.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n96Na8oC020894; Wed, 7 Oct 2009 10:36:08 +1100 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Wed, 7 Oct 2009 09:35:52 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 10:42:19 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 23:34:36 -0000 Paul Hoffman wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Additional PRF Inputs for TLS > > > > Author(s) : J. Solinas, P. Hoffman > > Filename : draft-solinas-tls-additional-prf-input-00.txt > > Pages : 6 > > Date : 2009-10-5 > > > >This document describes a mechanism for using additional PRF inputs > > with Transport Layer Security (TLS) and Datagram TLS (DTLS). > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-solinas-tls-additional- > prf-input-00.txt > > Greetings again. We would like to hear input on this draft from the > TLS community. The basic idea is an extension that would allow the > two parties to give additional information that is directly mixed > into the master secret through the PRF. > > --Paul Hoffman, Director > --VPN Consortium Comparing this with draft-rescorla-tls-extended-random-02.txt I see the requirement for the size of Server response is missing and thus undefined. >From 3.1 in the above we have: If the server wishes to use the extended randomness feature, it MUST send its own "extended_random" extension with an extended_random_value equal in length to the client's extended_random_value Additionally, I think some limitation of the size/amount of data that can be requested from a server is needed as large sizes could pose an attack on a server by exhausting the entropy pool and/or causing server performance degradation. Our prototype implementation allows servers to ignore or respond with error, depending on configuration, requests from clients that are larger than 256 octets. Mick Gray IBM _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Tue Oct 6 16:50:23 2009 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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, 6 Oct 2009 18:40:43 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091006234043.GP887@Sun.COM> References: <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 , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 -- From paul.hoffman@vpnc.org Tue Oct 6 17:15:16 2009 Return-Path: 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 5D6C428C1D2 for ; Tue, 6 Oct 2009 17:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[AWL=0.836, 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 dH9BD4GmpKBe for ; Tue, 6 Oct 2009 17:15:15 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8B57B28C0E1 for ; Tue, 6 Oct 2009 17:15:15 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n970GnA3048329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 17:16:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 6 Oct 2009 17:16:38 -0700 To: Michael Gray From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 00:15:16 -0000 At 9:35 AM +1000 10/7/09, Michael Gray wrote: >Comparing this with draft-rescorla-tls-extended-random-02.txt I see the >requirement for the size of Server response is missing and thus undefined. Correct. Both sides send arbitrary-length values. >From 3.1 in the above we have: > > If the server wishes to use the extended randomness feature, it MUST > send its own "extended_random" extension with an > extended_random_value equal in length to the client's > extended_random_value > >Additionally, I think some limitation of the size/amount of data that can >be requested from a server is needed as large sizes could pose an attack on >a server by exhausting the entropy pool and/or causing server performance >degradation. In this proposal, server never "requests" any particular size. The client offers its value in the extended_random extension, and the server offers its value in the reply. > Our prototype implementation allows servers to ignore or >respond with error, depending on configuration, requests from clients that >are larger than 256 octets. ...which is a good reason why we abandoned the "request a size" semantics. --Paul Hoffman, Director --VPN Consortium From mickgray@au1.ibm.com Tue Oct 6 18:32:49 2009 Return-Path: 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 590F53A67EC for ; Tue, 6 Oct 2009 18:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2RwyXndfZTO4 for ; Tue, 6 Oct 2009 18:32:48 -0700 (PDT) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id 3FA113A6782 for ; Tue, 6 Oct 2009 18:32:47 -0700 (PDT) Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id n971Vp7f031706 for ; Wed, 7 Oct 2009 12:31:51 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n971YLlq610536 for ; Wed, 7 Oct 2009 12:34:22 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n971YLNo028956 for ; Wed, 7 Oct 2009 12:34:21 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n971YLKV028953; Wed, 7 Oct 2009 12:34:21 +1100 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Wed, 7 Oct 2009 11:33:49 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 12:40:31 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 01:32:49 -0000 Paul Hoffman wrote on 07/10/2009 10:16:38 AM: > At 9:35 AM +1000 10/7/09, Michael Gray wrote: > >Comparing this with draft-rescorla-tls-extended-random-02.txt I see the > >requirement for the size of Server response is missing and thus undefined. > > Correct. Both sides send arbitrary-length values. > > >From 3.1 in the above we have: > > > > If the server wishes to use the extended randomness feature, it MUST > > send its own "extended_random" extension with an > > extended_random_value equal in length to the client's > > extended_random_value > > > >Additionally, I think some limitation of the size/amount of data that can > >be requested from a server is needed as large sizes could pose an attack on > >a server by exhausting the entropy pool and/or causing server performance > >degradation. > > In this proposal, server never "requests" any particular size. The > client offers its value in the extended_random extension, and the > server offers its value in the reply. > > > Our prototype implementation allows servers to ignore or > >respond with error, depending on configuration, requests from clients that > >are larger than 256 octets. > > ...which is a good reason why we abandoned the "request a size" semantics. In this case should be this draft also indicate that the client MAY generate a fatal "handshake_failure" alert in the event that the Server provides insufficient data? Would this again be true for the Server, if a Client sends insufficient data? i.e. A Server MAY generate a fatal "handshake_failure" alert in the event that the Client provides insufficient data? Additionally, can the Server use the Client size as an indication of how much the Server should send? else how does the Client convey a minimum/desired requirement information to a Server? Mick Gray IBM > > --Paul Hoffman, Director > --VPN Consortium From paul.hoffman@vpnc.org Tue Oct 6 19:35:16 2009 Return-Path: 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 C194228C1D0 for ; Tue, 6 Oct 2009 19:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=0.827, 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 4KvcHTcqX03Q for ; Tue, 6 Oct 2009 19:35:16 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 17C5A3A6915 for ; Tue, 6 Oct 2009 19:35:16 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n972amAX055536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Oct 2009 19:36:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 6 Oct 2009 19:36:47 -0700 To: Michael Gray From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 02:35:16 -0000 At 11:33 AM +1000 10/7/09, Michael Gray wrote: >In this case should be this draft also indicate that the client MAY >generate a fatal "handshake_failure" alert in the event that the Server >provides insufficient data? > >Would this again be true for the Server, if a Client sends insufficient >data? i.e. A Server MAY generate a fatal "handshake_failure" alert in the >event that the Client provides insufficient data? Either side MAY decide for many reasons to stop when they see the other sides's extension. I can add something to this effect to the next draft. >Additionally, can the Server use the Client size as an indication of how >much the Server should send? else how does the Client convey a >minimum/desired requirement information to a Server? It doesn't. This is really a different set of semantics than the previous draft. We realized that there was too many expectations being signalled, and decided to simplify. --Paul Hoffman, Director --VPN Consortium From mickgray@au1.ibm.com Tue Oct 6 23:05:42 2009 Return-Path: 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 D3DC23A6974 for ; Tue, 6 Oct 2009 23:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, 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 T-FsmTqgfmAs for ; Tue, 6 Oct 2009 23:05:42 -0700 (PDT) Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by core3.amsl.com (Postfix) with ESMTP id 8D3BA3A6970 for ; Tue, 6 Oct 2009 23:05:41 -0700 (PDT) Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp06.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9767Eai011277 for ; Wed, 7 Oct 2009 17:07:14 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9764oM71614050 for ; Wed, 7 Oct 2009 17:04:50 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9767IDo023058 for ; Wed, 7 Oct 2009 17:07:18 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9767IgF023055; Wed, 7 Oct 2009 17:07:18 +1100 In-Reply-To: To: Paul Hoffman X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Wed, 7 Oct 2009 16:07:02 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 07/10/2009 17:13:29 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 06:05:42 -0000 UGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+IHdyb3RlIG9uIDA3LzEwLzIwMDkg MTI6MzY6NDcgUE06DQoNCj4gQXQgMTE6MzMgQU0gKzEwMDAgMTAvNy8wOSwgTWljaGFlbCBHcmF5 IHdyb3RlOg0KPiA+SW4gdGhpcyBjYXNlIHNob3VsZCBiZSB0aGlzIGRyYWZ0IGFsc28gaW5kaWNh dGUgdGhhdCB0aGUgY2xpZW50IE1BWQ0KPiA+Z2VuZXJhdGUgYSBmYXRhbCAiaGFuZHNoYWtlX2Zh aWx1cmUiIGFsZXJ0IGluIHRoZSBldmVudCB0aGF0IHRoZSBTZXJ2ZXINCj4gPnByb3ZpZGVzIGlu c3VmZmljaWVudCBkYXRhPw0KPiA+DQo+ID5Xb3VsZCB0aGlzIGFnYWluIGJlIHRydWUgZm9yIHRo ZSBTZXJ2ZXIsIGlmIGEgQ2xpZW50IHNlbmRzIGluc3VmZmljaWVudA0KPiA+ZGF0YT8gaS5lLiBB IFNlcnZlciBNQVkgZ2VuZXJhdGUgYSBmYXRhbCAiaGFuZHNoYWtlX2ZhaWx1cmUiIGFsZXJ0IGlu DQp0aGUNCj4gPmV2ZW50IHRoYXQgdGhlIENsaWVudCBwcm92aWRlcyBpbnN1ZmZpY2llbnQgZGF0 YT8NCj4NCj4gRWl0aGVyIHNpZGUgTUFZIGRlY2lkZSBmb3IgbWFueSByZWFzb25zIHRvIHN0b3Ag d2hlbiB0aGV5IHNlZSB0aGUNCj4gb3RoZXIgc2lkZXMncyBleHRlbnNpb24uIEkgY2FuIGFkZCBz b21ldGhpbmcgdG8gdGhpcyBlZmZlY3QgdG8gdGhlIG5leHQNCmRyYWZ0Lg0KPg0KPiA+QWRkaXRp b25hbGx5LCBjYW4gdGhlIFNlcnZlciB1c2UgdGhlIENsaWVudCBzaXplIGFzIGFuIGluZGljYXRp b24gb2YgaG93DQo+ID5tdWNoIHRoZSBTZXJ2ZXIgc2hvdWxkIHNlbmQ/IGVsc2UgaG93IGRvZXMg dGhlIENsaWVudCBjb252ZXkgYQ0KPiA+bWluaW11bS9kZXNpcmVkIHJlcXVpcmVtZW50IGluZm9y bWF0aW9uIHRvIGEgU2VydmVyPw0KPg0KPiBJdCBkb2Vzbid0LiBUaGlzIGlzIHJlYWxseSBhIGRp ZmZlcmVudCBzZXQgb2Ygc2VtYW50aWNzIHRoYW4gdGhlDQo+IHByZXZpb3VzIGRyYWZ0LiBXZSBy ZWFsaXplZCB0aGF0IHRoZXJlIHdhcyB0b28gbWFueSBleHBlY3RhdGlvbnMNCj4gYmVpbmcgc2ln bmFsbGVkLCBhbmQgZGVjaWRlZCB0byBzaW1wbGlmeS4NCg0KSU1ITyB0aGUgcHJldmlvdXMgZHJh ZnQgd2FzIGVhc2llciBmcm9tIGEgU2VydmVyIGNvbmZpZ3VyYXRpb24gcG9pbnQgb2YNCnZpZXcu ICBXZSB3YW50IG91ciBTZXJ2ZXIgY29uZmlndXJhdGlvbiB0byBiZSBhcyBzaW1wbGUgYW5kIGFj Y29tbW9kYXRpbmcNCmFzIHBvc3NpYmxlIHRvIG1pbmltaXplIHRoZSBudW1iZXIgb2YgY29uZmln dXJhdGlvbiBvcHRpb25zIG91ciBjb25zdW1pbmcNCnByb2R1Y3RzIG5lZWQgdG8gZGVhbCB3aXRo LCB3aGljaCBhbHNvIHNpbXBsaWZpZXMgdGhpbmdzIGZvciBvdXIgY3VzdG9tZXJzLg0KVGh1cyBp biB0aGUgcHJldmlvdXMgZHJhZnQgdmVyc2lvbiB3ZSBuZWVkZWQgIG5vIFNlcnZlciBjb25maWd1 cmF0aW9uIGJ5DQpkZWZhdWx0IGluIHRoYXQgdGhlIFNlcnZlciBjb21lcyBwcmVjb25maWd1cmVk IHdpdGggYSBkZWZhdWx0IHNhZmUgbWF4aW11bQ0KdmFsdWUuICBUaHVzIHdoYXQgZXZlciB0aGUg Q2xpZW50IGFza3MgZm9yLCB0aGUgU2VydmVyIHdpbGwgYm90aCBhY2NlcHQgYW5kDQpwcm92aWRl LCB1cCB1bnRpbCBpdOKAmXMgbWF4aW11bSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gd2l0aG91dCBu ZWVkaW5nIGENCmNvbmZpZ3VyYXRpb24gdXBkYXRlIGZyb20gYSBjdXN0b21lci4NCg0KV2UgZW5k ZWQgdXAgd2l0aCB0d28gb3B0aW9uYWwgY29uZmlndXJhdGlvbiB2YWx1ZXMgZm9yIGEgU2VydmVy OiBBIG9wdGlvbmFsDQp2YWx1ZSBmb3IgdGhlIE1heGltdW0gYW1vdW50IG9mIHJhbmRvbSBkYXRh IGl0IHdpbGwgcHJvdmlkZSBvbiByZXF1ZXN0LCBhbmQNCmFuIG9wdGlvbmFsIHZhbHVlIGZvciBN aW5pbXVtIGFtb3VudCB0aGF0IHRoZSBTZXJ2ZXIgd2lsbCBhY2NlcHQgZnJvbSBhDQpDbGllbnQg aS5lLiB0aGUgU2VydmVyIE1VU1QgcmVjZWl2ZSB0aGlzIG1pbmltYWwgYW1vdW50IG9mIGFkZGl0 aW9uYWwgUFJGDQppbnB1dC4NCg0KSW4gdGhpcyBkcmFmdCB3ZSBjb3VsZCBoYXZlIHRoZSBTZXJ2 ZXIgYWx3YXlzIHJlc3BvbmQgd2l0aCBpdOKAmXMgTWF4aW11bQ0Kc2FmZSB2YWx1ZSBvciBmb3Jj ZSB0aGUgY3VzdG9tZXIgdG8gYWx3YXlzIHNldCBhIGNvbmZpZ3VyYXRpb24gdmFsdWUgd2hpY2gN CmltbWVkaWF0ZWx5IGNhdXNlcyBjdXN0b21lciBwYWluLiAgU2VuZGluZyB0aGUgbWF4aW11bSBz YWZlIHZhbHVlIHNlZW1zIGFuDQpvdmVyIGtpbGwgaWYgdGhlIGNsaWVudCBkb2VzIG5vdCBuZWVk IG9yIHdhbnQgaXQ7IHRoZSBjbGllbnQgaXMgYWZ0ZXIgYWxsDQppbmRpY2F0aW5nIGhvdyBtdWNo IGl0IHdhbnRzIHRvIGFkZCBvbiBpdCdzIHNpZGUgdG8gdGhlIFBSRiBhbmQgaXQgc2VlbXMNCmlu dHVpdGl2ZSBJTU8gZm9yIHRoZSBTZXJ2ZXIgdG8gcGxheSBiYWxsIGFuZCByZXNwb25kIGluIGtp bmQuICBJZiB0aGUNCmN1c3RvbWVyIHRoZW4gbWFrZXMgdGhlIFNlcnZlciBjb25maWd1cmF0aW9u IHZhbHVlIHRvbyBzbWFsbCB3ZSBjb3VsZCBoYXZlDQpoYW5kc2hha2UgZmFpbHMgd2l0aCBjZXJ0 YWluIGNsaWVudHMsIHJlZHVjaW5nIFNlcnZlciBhdmFpbGFiaWxpdHksIGENCnNpdHVhdGlvbiB0 aGF0IHdpbGwgcmVxdWlyZSBwcm9ibGVtIGRldGVybWluYXRpb24gdG8gcmVzb2x2ZSwgYW5kIHJl bGF0ZWQNCmN1c3RvbWVyIGFubm95YW5jZS4NCg0KTWljayBHcmF5DQpJQk0NCg0KPg0KPiAtLVBh dWwgSG9mZm1hbiwgRGlyZWN0b3INCj4gLS1WUE4gQ29uc29ydGl1bQ== From carolin.latze@unifr.ch Wed Oct 7 08:16:07 2009 Return-Path: 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 3BDB128C0E6 for ; Wed, 7 Oct 2009 08:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, 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 BRmf7Uumx4WN for ; Wed, 7 Oct 2009 08:16:06 -0700 (PDT) Received: from siufsrv104.unifr.ch (siufsrv104.unifr.ch [134.21.214.74]) by core3.amsl.com (Postfix) with ESMTP id E48E73A657C for ; Wed, 7 Oct 2009 08:16:05 -0700 (PDT) Received: from diufpc272.unifr.ch ([134.21.72.156]) by siufsrv104.unifr.ch stage1 with esmtp with id 1MvYGu-0005fm-C1 for from ; Wed, 07 Oct 2009 17:17:44 +0200 Message-ID: <4ACCB0E4.4000801@unifr.ch> Date: Wed, 07 Oct 2009 17:16:52 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.23 (X11/20090916) MIME-Version: 1.0 To: tls@ietf.org Content-Type: multipart/mixed; boundary="------------080303030202010204080100" Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:16:07 -0000 This is a multi-part message in MIME format. --------------080303030202010204080100 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, after several experiments with TPMs as authentication devices in EAP-TLS, we figured out, that the specific modifications in order to use TPMs might be rather an extension to TLS than an EAP extension. Therefore, we gave it a try and defined a new TLS extension in order to use TPM certified keys directly with TLS. We are aware of the fact, that there is a possibility to request new valid X.509 certificates for those keys which allows to use them with standard TLS (and do not require a new extension), but since we want to avoid that request (and we think that this does not introduce any security issues), we propose this extension. We are always open for discussions, (critical) feedback, suggestions, ... Regards Carolin Latze -------- Original Message -------- Subject: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt Date: Wed, 7 Oct 2009 16:45:01 +0200 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM) Author(s) : C. Latze, et al. Filename : draft-latze-tls-tpm-extns-00.txt Pages : 10 Date : 2009-10-07 Trusted Platform Modules (TPMs) become more and more widespread in modern desktop and laptop computers and provide secure storage and cryptographic functions. As one nice feature of TPMs is that they can be identified uniquely, they provide a good base for device authentication in protocols like TLS.This document specifies a TLS extension that allows to use TPM certified keys with TLS in order to allow for a secure and comfortable device authentication in TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de Pérolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec --------------080303030202010204080100 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ATT00001.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------080303030202010204080100-- From uri@ll.mit.edu Wed Oct 7 08:41:27 2009 Return-Path: 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 22F083A6962 for ; Wed, 7 Oct 2009 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 OjFi93vw2vCP for ; Wed, 7 Oct 2009 08:41:25 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 465483A686C for ; Wed, 7 Oct 2009 08:41:25 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n97Fh18s000598; Wed, 7 Oct 2009 11:43:01 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAxwaizM; Wed Oct 7 11:35:20 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Wed, 7 Oct 2009 11:35:20 -0400 From: "Blumenthal, Uri" To: "'carolin.latze@unifr.ch'" , "'tls@ietf.org'" Date: Wed, 7 Oct 2009 11:34:48 -0400 Thread-Topic: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] Thread-Index: AcpHYU9UFwobvWm7RraAZtAwfuyEdAAAndrQ Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BBC@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:41:27 -0000 QW5kIHRoZSByZWFzb24geW91IHdhbnQgdG8gZG8gdGhpcyBpbnN0ZWFkIG9mIHVzaW5nIHZhbGlk IFguNTA5IGNlcnRzIGlzLi4uPw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206IHRscy1ib3VuY2VzQGlldGYub3JnIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiB0bHNA aWV0Zi5vcmcgPHRsc0BpZXRmLm9yZz4NClNlbnQ6IFdlZCBPY3QgMDcgMTE6MTY6NTIgMjAwOQpT dWJqZWN0OiBbVExTXSBbRndkOiB7VmlydXM/fSBJLUQgQWN0aW9uOmRyYWZ0LWxhdHplLXRscy10 cG0tZXh0bnMtMDAudHh0XQ0KDQpIaSBhbGwsDQoNCmFmdGVyIHNldmVyYWwgZXhwZXJpbWVudHMg d2l0aCBUUE1zIGFzIGF1dGhlbnRpY2F0aW9uIGRldmljZXMgaW4NCkVBUC1UTFMsIHdlIGZpZ3Vy ZWQgb3V0LCB0aGF0IHRoZSBzcGVjaWZpYyBtb2RpZmljYXRpb25zIGluIG9yZGVyIHRvIHVzZQ0K VFBNcyBtaWdodCBiZSByYXRoZXIgYW4gZXh0ZW5zaW9uIHRvIFRMUyB0aGFuIGFuIEVBUCBleHRl bnNpb24uDQpUaGVyZWZvcmUsIHdlIGdhdmUgaXQgYSB0cnkgYW5kIGRlZmluZWQgYSBuZXcgVExT IGV4dGVuc2lvbiBpbiBvcmRlciB0bw0KdXNlIFRQTSBjZXJ0aWZpZWQga2V5cyBkaXJlY3RseSB3 aXRoIFRMUy4gV2UgYXJlIGF3YXJlIG9mIHRoZSBmYWN0LCB0aGF0DQp0aGVyZSBpcyBhIHBvc3Np YmlsaXR5IHRvIHJlcXVlc3QgbmV3IHZhbGlkIFguNTA5IGNlcnRpZmljYXRlcyBmb3IgdGhvc2UN CmtleXMgd2hpY2ggYWxsb3dzIHRvIHVzZSB0aGVtIHdpdGggc3RhbmRhcmQgVExTIChhbmQgZG8g bm90IHJlcXVpcmUgYQ0KbmV3IGV4dGVuc2lvbiksIGJ1dCBzaW5jZSB3ZSB3YW50IHRvIGF2b2lk IHRoYXQgcmVxdWVzdCAoYW5kIHdlIHRoaW5rDQp0aGF0IHRoaXMgZG9lcyBub3QgaW50cm9kdWNl IGFueSBzZWN1cml0eSBpc3N1ZXMpLCB3ZSBwcm9wb3NlIHRoaXMNCmV4dGVuc2lvbi4NCg0KV2Ug YXJlIGFsd2F5cyBvcGVuIGZvciBkaXNjdXNzaW9ucywgKGNyaXRpY2FsKSBmZWVkYmFjaywgc3Vn Z2VzdGlvbnMsIC4uLg0KDQpSZWdhcmRzDQpDYXJvbGluIExhdHplDQoNCg0KLS0tLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogCXtWaXJ1cz99IEktRCBBY3Rpb246ZHJh ZnQtbGF0emUtdGxzLXRwbS1leHRucy0wMC50eHQNCkRhdGU6IAlXZWQsIDcgT2N0IDIwMDkgMTY6 NDU6MDEgKzAyMDANCkZyb206IAlJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgPEludGVybmV0LURy YWZ0c0BpZXRmLm9yZz4NClJlcGx5LVRvOiAJaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpUbzogCWktZC1hbm5vdW5jZUBpZXRmLm9yZyA8aS1kLWFu bm91bmNlQGlldGYub3JnPg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoJVGl0bGUg ICAgICAgICAgIDogVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIEV4dGVuc2lvbnMgZm9y IHRoZSBUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZSAoVFBNKQ0KCUF1dGhvcihzKSAgICAgICA6IEMu IExhdHplLCBldCBhbC4NCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1sYXR6ZS10bHMtdHBtLWV4 dG5zLTAwLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDEwDQoJRGF0ZSAgICAgICAgICAgIDogMjAw OS0xMC0wNw0KDQpUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZXMgKFRQTXMpIGJlY29tZSBtb3JlIGFu ZCBtb3JlIHdpZGVzcHJlYWQgaW4NCm1vZGVybiBkZXNrdG9wIGFuZCBsYXB0b3AgY29tcHV0ZXJz IGFuZCBwcm92aWRlIHNlY3VyZSBzdG9yYWdlIGFuZA0KY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbnMu ICBBcyBvbmUgbmljZSBmZWF0dXJlIG9mIFRQTXMgaXMgdGhhdCB0aGV5DQpjYW4gYmUgaWRlbnRp ZmllZCB1bmlxdWVseSwgdGhleSBwcm92aWRlIGEgZ29vZCBiYXNlIGZvciBkZXZpY2UNCmF1dGhl bnRpY2F0aW9uIGluIHByb3RvY29scyBsaWtlIFRMUy5UaGlzIGRvY3VtZW50IHNwZWNpZmllcyBh IFRMUw0KZXh0ZW5zaW9uIHRoYXQgYWxsb3dzIHRvIHVzZSBUUE0gY2VydGlmaWVkIGtleXMgd2l0 aCBUTFMgaW4gb3JkZXIgdG8NCmFsbG93IGZvciBhIHNlY3VyZSBhbmQgY29tZm9ydGFibGUgZGV2 aWNlIGF1dGhlbnRpY2F0aW9uIGluIFRMUy4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJh ZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYXR6ZS10 bHMtdHBtLWV4dG5zLTAwLnR4dA0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50 IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRo ZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50ZXJuZXQtRHJhZnQuDQoNCg0KDQotLSANCkNhcm9s aW4gTGF0emUNClBoRCBTdHVkZW50CQkJCUlDVCBFbmdpbmVlcg0KDQpEZXBhcnRtZW50IG9mIENv bXB1dGVyIFNjaWVuY2UJCVN3aXNzY29tIFN0cmF0ZWd5IGFuZCBJbm5vdmF0aW9uDQpCb3VsZXZh cmQgZGUgUMOpcm9sbGVzIDkwCQlPc3Rlcm11bmRpZ2Vuc3RyYXNzZSA5Mw0KQ0gtMTcwMCBGcmli b3VyZyAgICAgIAkJCUNILTMwMDYgQmVybg0KCQ0KcGhvbmU6ICs0MSAyNiAzMDAgODMgMzAJCQkr NDEgNzkgNzIgOTY1IDI3DQpob21lcGFnZTogaHR0cDovL2RpdWYudW5pZnIuY2gvcGVvcGxlL2xh dHplYw0KDQoNCg== From root@core3.amsl.com Wed Oct 7 10:45:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 674053A68F0; Wed, 7 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091007174501.674053A68F0@core3.amsl.com> Date: Wed, 7 Oct 2009 10:45:01 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Datagram Transport Layer Security version 1.2 Author(s) : E. Rescorla, N. Modadugu Filename : draft-ietf-tls-rfc4347-bis-03.txt Pages : 29 Date : 2009-10-07 This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rfc4347-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07104049.I-D@ietf.org> --NextPart-- From ekr@networkresonance.com Wed Oct 7 10:46:17 2009 Return-Path: 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 78F463A6872 for ; Wed, 7 Oct 2009 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599] 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 SdqGThxoW25h for ; Wed, 7 Oct 2009 10:46:16 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A3FE028C16D for ; Wed, 7 Oct 2009 10:46:11 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5DE5E50822; Wed, 7 Oct 2009 10:47:44 -0700 (PDT) Date: Wed, 07 Oct 2009 10:47:44 -0700 From: Eric Rescorla To: "Blumenthal, Uri" In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BBC@LLE2K7-BE01.mitll.ad.local> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BBC@LLE2K7-BE01.mitll.ad.local> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091007174744.5DE5E50822@romeo.rtfm.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:46:17 -0000 At Wed, 7 Oct 2009 11:34:48 -0400, Blumenthal, Uri wrote: > > And the reason you want to do this instead of using valid X.509 certs is...? This would be my question as well... -Ekr From carolin.latze@unifr.ch Thu Oct 8 01:02:21 2009 Return-Path: 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 BA09928C233 for ; Thu, 8 Oct 2009 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751] 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 TwH9+dQsG-mR for ; Thu, 8 Oct 2009 01:02:20 -0700 (PDT) Received: from sr-svx-320.unifr.ch (sr-svx-320.unifr.ch [134.21.214.75]) by core3.amsl.com (Postfix) with ESMTP id 5F9E128C228 for ; Thu, 8 Oct 2009 01:02:20 -0700 (PDT) Received: from diufpc272.unifr.ch ([134.21.72.156]) by sr-svx-320.unifr.ch stage1 with esmtp with id 1MvnyY-0000g7-QJ for from ; Thu, 08 Oct 2009 10:03:50 +0200 Message-ID: <4ACD9CAB.7040605@unifr.ch> Date: Thu, 08 Oct 2009 10:02:51 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.23 (X11/20090916) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: [TLS] [Fwd: Re: [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 08:02:21 -0000 sorry, forgot to include the list... -------- Original Message -------- Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] Date: Thu, 8 Oct 2009 10:02:09 +0200 From: Carolin Latze To: Blumenthal, Uri References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BBC@LLE2K7-BE01.mitll.ad.local> They are still valid X.509... the only difference is that they are self-signed and not CA-signed. And the reason to use self-signed certificates is that you don't need to send another certificate request without loosing security since the self-signed certificates are bound to identity certificates that are signed by a CA. Blumenthal, Uri wrote: > And the reason you want to do this instead of using valid X.509 certs is...? > > > ----- Original Message ----- > From: tls-bounces@ietf.org > To: tls@ietf.org > Sent: Wed Oct 07 11:16:52 2009 > Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] > > Hi all, > > after several experiments with TPMs as authentication devices in > EAP-TLS, we figured out, that the specific modifications in order to use > TPMs might be rather an extension to TLS than an EAP extension. > Therefore, we gave it a try and defined a new TLS extension in order to > use TPM certified keys directly with TLS. We are aware of the fact, that > there is a possibility to request new valid X.509 certificates for those > keys which allows to use them with standard TLS (and do not require a > new extension), but since we want to avoid that request (and we think > that this does not introduce any security issues), we propose this > extension. > > We are always open for discussions, (critical) feedback, suggestions, ... > > Regards > Carolin Latze > > > -------- Original Message -------- > Subject: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt > Date: Wed, 7 Oct 2009 16:45:01 +0200 > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM) > Author(s) : C. Latze, et al. > Filename : draft-latze-tls-tpm-extns-00.txt > Pages : 10 > Date : 2009-10-07 > > Trusted Platform Modules (TPMs) become more and more widespread in > modern desktop and laptop computers and provide secure storage and > cryptographic functions. As one nice feature of TPMs is that they > can be identified uniquely, they provide a good base for device > authentication in protocols like TLS.This document specifies a TLS > extension that allows to use TPM certified keys with TLS in order to > allow for a secure and comfortable device authentication in TLS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de Pérolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de Pérolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From uri@ll.mit.edu Thu Oct 8 09:22:18 2009 Return-Path: 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 EA42228C188 for ; Thu, 8 Oct 2009 09:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 xpQsOmRVu6IK for ; Thu, 8 Oct 2009 09:22:17 -0700 (PDT) Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id A62B13A6860 for ; Thu, 8 Oct 2009 09:22:17 -0700 (PDT) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n98GNscN012634; Thu, 8 Oct 2009 12:23:54 -0400 (EDT) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAyvaOMQ; Thu Oct 8 12:04:47 2009 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 8 Oct 2009 12:04:47 -0400 From: "Blumenthal, Uri" To: "'carolin.latze@unifr.ch'" , "'tls@ietf.org'" Date: Thu, 8 Oct 2009 12:04:11 -0400 Thread-Topic: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] Thread-Index: AcpH7biOACVip5dLSNu7jpA2KFr1LQAQ1WYT Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 16:22:19 -0000 SSBkb24ndCB0aGluayBJIHVuZGVyc3RhbmQgeW91Lg0KDQpBcmUgeW91IGltcGx5aW5nIHRoYXQg Q0EtY2VydGlmaWVkIGNlcnRzIGFyZSBsZXNzIHNlY3VyZSB0aGFuIHNlbGYtc2lnbmVkIG9uZXM/ ISBPciB0aGF0IGdldHRpbmcgeW91ciBUUE0tcHJvdmlkZWQgUHVibGljIEtleSBzaWduZWQgYnkg YSBDQSBsZXNzZW5zIGl0cyBzZWN1cml0eT8NCg0KQW5kIGhvdyBjYW4gc2VsZi1zaWduZWQgY2Vy dHMgYmUgcG9zc2libHkgYm91bmQgdG8gImlkZW50aXR5IGNlcnRzIHNpZ25lZCBieSBhIENBIj8N Cg0KSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHlvdXIganVzdGlmaWNhdGlvbiAob3IgcmVhc29u cykgZm9yIG11Y2tpbmcgd2l0aCBhIHBlcmZlY3RseSB1c2FibGUgVExTIG1vZGVsLg0KDQpQZXJo YXBzIHlvdSdkIHdhbnQgdG8gZGVzY3JpYmUgaW4gYSBmZXcgc2VudGVuY2VzIHdoYXQgaXQgaXMg dGhhdCB5b3UncmUgdHJ5aW5nIHRvIGFjY29tcGxpc2ggd2l0aCBUUE0tZ2VuZXJhdGVkIHB1Ymxp YyBrZXlzLCBhbmQgaG93IFRMUyBhcy1pcyBkb2VzIG5vdCBhbGxvdyB0aGF0PyBBbmQgd2h5IHdo YXQgeW91J3JlIHRyeWluZyB0byBkbyB3b3VsZCBvZiBpbnRlcmVzdCB0byBhbnlib2R5IGVsc2Ug b24gdGhlIHBsYW5ldCB3aG8gdXNlcyBUUE0gYW5kL29yIFRMUz8NCg0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBDYXJvbGluIExhdHplIDxjYXJvbGluLmxhdHplQHVuaWZy LmNoPg0KVG86IEJsdW1lbnRoYWwsIFVyaQ0KU2VudDogVGh1IE9jdCAwOCAwNDowMjowOSAyMDA5 ClN1YmplY3Q6IFJlOiBbVExTXSBbRndkOiB7VmlydXM/fSBJLUQgQWN0aW9uOmRyYWZ0LWxhdHpl LXRscy10cG0tZXh0bnMtMDAudHh0XQ0KDQpUaGV5IGFyZSBzdGlsbCB2YWxpZCBYLjUwOS4uLiB0 aGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhleSBhcmUNCnNlbGYtc2lnbmVkIGFuZCBub3Qg Q0Etc2lnbmVkLiBBbmQgdGhlIHJlYXNvbiB0byB1c2Ugc2VsZi1zaWduZWQNCmNlcnRpZmljYXRl cyBpcyB0aGF0IHlvdSBkb24ndCBuZWVkIHRvIHNlbmQgYW5vdGhlciBjZXJ0aWZpY2F0ZSByZXF1 ZXN0DQp3aXRob3V0IGxvb3Npbmcgc2VjdXJpdHkgc2luY2UgdGhlIHNlbGYtc2lnbmVkIGNlcnRp ZmljYXRlcyBhcmUgYm91bmQgdG8NCmlkZW50aXR5IGNlcnRpZmljYXRlcyB0aGF0IGFyZSBzaWdu ZWQgYnkgYSBDQS4NCg0KQmx1bWVudGhhbCwgVXJpIHdyb3RlOg0KPiBBbmQgdGhlIHJlYXNvbiB5 b3Ugd2FudCB0byBkbyB0aGlzIGluc3RlYWQgb2YgdXNpbmcgdmFsaWQgWC41MDkgY2VydHMgaXMu Li4/DQo+DQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogdGxzLWJv dW5jZXNAaWV0Zi5vcmcgPHRscy1ib3VuY2VzQGlldGYub3JnPg0KPiBUbzogdGxzQGlldGYub3Jn IDx0bHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZCBPY3QgMDcgMTE6MTY6NTIgMjAwOQ0KPiBTdWJq ZWN0OiBbVExTXSBbRndkOiB7VmlydXM/fSBJLUQgQWN0aW9uOmRyYWZ0LWxhdHplLXRscy10cG0t ZXh0bnMtMDAudHh0XQ0KPg0KPiBIaSBhbGwsDQo+DQo+IGFmdGVyIHNldmVyYWwgZXhwZXJpbWVu dHMgd2l0aCBUUE1zIGFzIGF1dGhlbnRpY2F0aW9uIGRldmljZXMgaW4NCj4gRUFQLVRMUywgd2Ug ZmlndXJlZCBvdXQsIHRoYXQgdGhlIHNwZWNpZmljIG1vZGlmaWNhdGlvbnMgaW4gb3JkZXIgdG8g dXNlDQo+IFRQTXMgbWlnaHQgYmUgcmF0aGVyIGFuIGV4dGVuc2lvbiB0byBUTFMgdGhhbiBhbiBF QVAgZXh0ZW5zaW9uLg0KPiBUaGVyZWZvcmUsIHdlIGdhdmUgaXQgYSB0cnkgYW5kIGRlZmluZWQg YSBuZXcgVExTIGV4dGVuc2lvbiBpbiBvcmRlciB0bw0KPiB1c2UgVFBNIGNlcnRpZmllZCBrZXlz IGRpcmVjdGx5IHdpdGggVExTLiBXZSBhcmUgYXdhcmUgb2YgdGhlIGZhY3QsIHRoYXQNCj4gdGhl cmUgaXMgYSBwb3NzaWJpbGl0eSB0byByZXF1ZXN0IG5ldyB2YWxpZCBYLjUwOSBjZXJ0aWZpY2F0 ZXMgZm9yIHRob3NlDQo+IGtleXMgd2hpY2ggYWxsb3dzIHRvIHVzZSB0aGVtIHdpdGggc3RhbmRh cmQgVExTIChhbmQgZG8gbm90IHJlcXVpcmUgYQ0KPiBuZXcgZXh0ZW5zaW9uKSwgYnV0IHNpbmNl IHdlIHdhbnQgdG8gYXZvaWQgdGhhdCByZXF1ZXN0IChhbmQgd2UgdGhpbmsNCj4gdGhhdCB0aGlz IGRvZXMgbm90IGludHJvZHVjZSBhbnkgc2VjdXJpdHkgaXNzdWVzKSwgd2UgcHJvcG9zZSB0aGlz DQo+IGV4dGVuc2lvbi4NCj4NCj4gV2UgYXJlIGFsd2F5cyBvcGVuIGZvciBkaXNjdXNzaW9ucywg KGNyaXRpY2FsKSBmZWVkYmFjaywgc3VnZ2VzdGlvbnMsIC4uLg0KPg0KPiBSZWdhcmRzDQo+IENh cm9saW4gTGF0emUNCj4NCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0K PiBTdWJqZWN0OiAJe1ZpcnVzP30gSS1EIEFjdGlvbjpkcmFmdC1sYXR6ZS10bHMtdHBtLWV4dG5z LTAwLnR4dA0KPiBEYXRlOiAJV2VkLCA3IE9jdCAyMDA5IDE2OjQ1OjAxICswMjAwDQo+IEZyb206 IAlJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgPEludGVybmV0LURyYWZ0c0BpZXRmLm9yZz4NCj4g UmVwbHktVG86IAlpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4NCj4gVG86IAlpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgPGktZC1hbm5vdW5jZUBpZXRmLm9y Zz4NCj4NCj4NCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPg0KPiAJVGl0bGUgICAgICAg ICAgIDogVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIEV4dGVuc2lvbnMgZm9yIHRoZSBU cnVzdGVkIFBsYXRmb3JtIE1vZHVsZSAoVFBNKQ0KPiAJQXV0aG9yKHMpICAgICAgIDogQy4gTGF0 emUsIGV0IGFsLg0KPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtbGF0emUtdGxzLXRwbS1leHRu cy0wMC50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDEwDQo+IAlEYXRlICAgICAgICAgICAgOiAy MDA5LTEwLTA3DQo+DQo+IFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlcyAoVFBNcykgYmVjb21lIG1v cmUgYW5kIG1vcmUgd2lkZXNwcmVhZCBpbg0KPiBtb2Rlcm4gZGVza3RvcCBhbmQgbGFwdG9wIGNv bXB1dGVycyBhbmQgcHJvdmlkZSBzZWN1cmUgc3RvcmFnZSBhbmQNCj4gY3J5cHRvZ3JhcGhpYyBm dW5jdGlvbnMuICBBcyBvbmUgbmljZSBmZWF0dXJlIG9mIFRQTXMgaXMgdGhhdCB0aGV5DQo+IGNh biBiZSBpZGVudGlmaWVkIHVuaXF1ZWx5LCB0aGV5IHByb3ZpZGUgYSBnb29kIGJhc2UgZm9yIGRl dmljZQ0KPiBhdXRoZW50aWNhdGlvbiBpbiBwcm90b2NvbHMgbGlrZSBUTFMuVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgYSBUTFMNCj4gZXh0ZW5zaW9uIHRoYXQgYWxsb3dzIHRvIHVzZSBUUE0gY2Vy dGlmaWVkIGtleXMgd2l0aCBUTFMgaW4gb3JkZXIgdG8NCj4gYWxsb3cgZm9yIGEgc2VjdXJlIGFu ZCBjb21mb3J0YWJsZSBkZXZpY2UgYXV0aGVudGljYXRpb24gaW4gVExTLg0KPg0KPiBBIFVSTCBm b3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtbGF0emUtdGxzLXRwbS1leHRucy0wMC50eHQNCj4NCj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGlj aCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQo+IGltcGxlbWVudGF0 aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQo+ IEludGVybmV0LURyYWZ0Lg0KPg0KPg0KPg0KPiAgIA0KDQotLSANCkNhcm9saW4gTGF0emUNClBo RCBTdHVkZW50CQkJCUlDVCBFbmdpbmVlcg0KDQpEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVu Y2UJCVN3aXNzY29tIFN0cmF0ZWd5IGFuZCBJbm5vdmF0aW9uDQpCb3VsZXZhcmQgZGUgUMOpcm9s bGVzIDkwCQlPc3Rlcm11bmRpZ2Vuc3RyYXNzZSA5Mw0KQ0gtMTcwMCBGcmlib3VyZyAgICAgIAkJ CUNILTMwMDYgQmVybg0KCQ0KcGhvbmU6ICs0MSAyNiAzMDAgODMgMzAJCQkrNDEgNzkgNzIgOTY1 IDI3DQpob21lcGFnZTogaHR0cDovL2RpdWYudW5pZnIuY2gvcGVvcGxlL2xhdHplYw0KDQoNCg== From jsalowey@cisco.com Thu Oct 8 11:00:06 2009 Return-Path: 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 8F06E3A6831 for ; Thu, 8 Oct 2009 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 GIjjC2S3S3Dn for ; Thu, 8 Oct 2009 11:00:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BCD093A681B for ; Thu, 8 Oct 2009 11:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=419; q=dns/txt; s=sjiport04001; t=1255024907; x=1256234507; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20Working=20group=20last=20call=20for=20d raft-ietf-tls-rfc4347-bis-03.txt|Date:=20Thu,=208=20Oct =202009=2011:01:47=20-0700|Message-ID:=20|To: =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable; bh=I3UYRG+jhDUqFT/0FNVU3Z3l7GPmgMK3cvYTI+qP2M4=; b=Y5jnOeWCyXbV8fC+0mDbrwNaGFnvw5ikrSyKEWlkid2GLRu7CIUpO+jI 6LUtxb1AaaqKCpEcDVQka2fMT97iongfSU+Y9ZgIvoOiOpVw2fJMApLhG bHThEzQ3m5wuhMeGFkBKgvC9NXMSoU0fhc4X7W4491QmCMOsC2vOgeb7T 4=; Authentication-Results: sj-iport-4.cisco.com; dkim=pass (signature verified [TEST]) header.i=jsalowey@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEbGzUqrR7PD/2dsb2JhbADDDIhkAY9GBoQq X-IronPort-AV: E=Sophos;i="4.44,526,1249257600"; d="scan'208";a="45202611" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 08 Oct 2009 18:01:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n98I1m33019977 for ; Thu, 8 Oct 2009 11:01:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n98I1mZH018811 for ; Thu, 8 Oct 2009 18:01:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 11:01:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Oct 2009 11:01:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working group last call for draft-ietf-tls-rfc4347-bis-03.txt Thread-Index: AcpIQWb+QX51VJ/sQuCYtXJYaFMzGQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 08 Oct 2009 18:01:48.0111 (UTC) FILETIME=[6790FDF0:01CA4841] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=419; t=1255024908; x=1255888908; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Working=20group=20last=20call=20for=20draft-iet f-tls-rfc4347-bis-03.txt |Sender:=20; bh=I3UYRG+jhDUqFT/0FNVU3Z3l7GPmgMK3cvYTI+qP2M4=; b=AhJcupj2a3u5eEHhuyaBHgViq5QPzEp48wiinElzdB6hAE9vjvcqi1QR+e Qb0Efn2t1OF5L3g2SxsJ/WaZ1A8ueZ5meAYAQgPHK7dx/8qRNJfVaAexrSA8 xNTeLc/xZT; Subject: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:00:06 -0000 This is an announcement for working group last call on DTLS 1.2 (RFC 4347-bis). The document is available here: http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03 Please send any comments to the list by October 26, 2009. It is useful to send an indication to the list if you have read the document and think it is ready for publication even if you don't have specific comments. =20 Thanks, Joe From carolin.latze@unifr.ch Fri Oct 9 01:04:47 2009 Return-Path: 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 8058428C1D8 for ; Fri, 9 Oct 2009 01:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 HxE7I7GEO1KZ for ; Fri, 9 Oct 2009 01:04:46 -0700 (PDT) Received: from siufsrv104.unifr.ch (siufsrv104.unifr.ch [134.21.214.74]) by core3.amsl.com (Postfix) with ESMTP id B4BA428C1D1 for ; Fri, 9 Oct 2009 01:04:45 -0700 (PDT) Received: from diufpc272.unifr.ch ([134.21.72.156]) by siufsrv104.unifr.ch stage1 with esmtp with id 1MwAUU-0005c9-FE from ; Fri, 09 Oct 2009 10:06:18 +0200 Message-ID: <4ACEEEB5.9000803@unifr.ch> Date: Fri, 09 Oct 2009 10:05:09 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.23 (X11/20090916) MIME-Version: 1.0 To: "Blumenthal, Uri" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 08:04:47 -0000 Ok, > > Are you implying that CA-certified certs are less secure than self-signed ones?! Or that getting your TPM-provided Public Key signed by a CA lessens its security? > [CL] No, nothing like that. I think my english might be a problem, but I try to explain what I mean: TPMs come with the possibility to create so called attestation identity keys (AIKs) that will be signed by a certain certificate authority called Privacy CA resulting in an AIK certificate. The process of signing by the Privacy CA includes verifying that those keys have been generated by a genuine TPM. The private part of the AIK never leaves the TPM, which means that the AIK certificates prove that they belong to a genuine, given TPM. The AIK certificate is a valid X.509 certificate, which can be verified using the standard X.509 verification functions. So if you use those certificates in authentication protocols you can authenticate devices (using their TPM). But, unfortunatly, those keys have some restrictions which makes it impossible to use them in TLS direclty: 1) they are restricted to SHA-1 signing (well, that should not be a problem with TLS 1.2) 2) they only sign data that originates in the TPM (that means in order to use them with TLS, every data that has to be signed has to originate in the TPM, which is not impossible and might be useful in some cases, but is rather complicated) In order to be able to use something like the AIKs in authentication, the TPM standard propose to define new keys (with the property that the private part never leaves the TPM) and sign them using the AIK. That signing process is also defined in the standard and results in a special structure called TCPA_CERTIFY_INFO. That structure proves that a certified key has been signed by a valid AIK, which itself can be verified using standard X.509 verification techniques. Unfortunatly, TCPA_CERTIFY_INFO does not have the same format like X.509. The certified key could be used in TLS directly, but how do we verify that it belongs to a given TPM? There are several solutions that all rely on the fact, that the AIK certificate proves that this certificate key belongs to a genuine, given TPM: 1) Make it an X.509 certificate signed by the AIK (=> results in complete easy to verify chain). This is not possible since the AIK certificate carries the CA:false constraint. 2) Make it an X.509 proxy certificate of the AIK. Not possible since the subject of the AIK is NULL. Those would be the easy possibilities, but since they do not work, the TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO structure called SKAE. Again two possibilities arise to make use of that extension: 1) Generate a new X.509 certificate request around the certified key, include the SKAE extension, and send the request to a CA to sign it. This results in a standard X.509 certificate that can be used for TLS. But if the server wants to ensure that this certificate is bound (= the private key never leaves the TPM) to a certain genuine TPM, he has to verify the SKAE extension too. That means he has to get the AIK certificate too, which is not part of the chain. The SKAE extension carries a hint where to find that certificate. Now my opinion to that approach: A second certificate request is needed (apart from the AIK certificate request needed anyway), which is overkill (just my opinion, I know, that other people do not have a problem with that) and - and thats the bigger problem from my point of view - if the server really wants to verify that the keys originates from a given, genuine TPM, he has to download, request, get ... the AIK in addition to what he gets out of the TLS handshake. So there has to be some kind of storage for the AIK certificates, that either sends the AIK certificates to all the servers or receives SKAE extensions from servers to validate them. I think that might result in scalability problems (just my opinion). 2) Generate an X.509 self-signed certificate around the certified key including the SKAE extension, use it in the handshake and send the AIK certificate that verifies the SKAE extension within the supplemental data handshake message. I think that approach has a better scalability. BTW: Everything I described above is only needed if you want to use those special keys. If you only want to use the TPM as a key storage and secure provider for functions like signing etc, there is no need for any modification to TLS and X.509. The reason why I want to use those special keys is that they are available and have those nice properties of being (provable) bound to a genuine, given TPM. If you ask me now to ignore those keys if they introduce those difficulties then I think that is a valid conclusion. I only think that there should be a possibility to use them if they are available. > And how can self-signed certs be possibly bound to "identity certs signed by a CA"? > [CL] Using that SKAE extension explained above. > I still don't understand your justification (or reasons) for mucking with a perfectly usable TLS model. > [CL] I think I tried to explain that above > Perhaps you'd want to describe in a few sentences what it is that you're trying to accomplish with TPM-generated public keys, and how TLS as-is does not allow that? And why what you're trying to do would of interest to anybody else on the planet who uses TPM and/or TLS? > [CL] I think I tried to explain that too. I think, AIKs and certified keys are a good possibility to authentication TPM equipped devices even if they introduce some difficulties. But I also see the problem that TLS has been available much longer than TPMs, so it would have been easy to adapt the TPM to TLS needs instead to do it vice versa. I have not been part of the TPM standardization although I try to discuss with TCG people too. There might be good reason for the things they defined that I do not see at the moment. And since TPMs are already shipped with all the features described above I try to make it usable like that. > > ----- Original Message ----- > From: Carolin Latze > To: Blumenthal, Uri > Sent: Thu Oct 08 04:02:09 2009 > Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] > > They are still valid X.509... the only difference is that they are > self-signed and not CA-signed. And the reason to use self-signed > certificates is that you don't need to send another certificate request > without loosing security since the self-signed certificates are bound to > identity certificates that are signed by a CA. > > Blumenthal, Uri wrote: > >> And the reason you want to do this instead of using valid X.509 certs is...? >> >> >> ----- Original Message ----- >> From: tls-bounces@ietf.org >> To: tls@ietf.org >> Sent: Wed Oct 07 11:16:52 2009 >> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] >> >> Hi all, >> >> after several experiments with TPMs as authentication devices in >> EAP-TLS, we figured out, that the specific modifications in order to use >> TPMs might be rather an extension to TLS than an EAP extension. >> Therefore, we gave it a try and defined a new TLS extension in order to >> use TPM certified keys directly with TLS. We are aware of the fact, that >> there is a possibility to request new valid X.509 certificates for those >> keys which allows to use them with standard TLS (and do not require a >> new extension), but since we want to avoid that request (and we think >> that this does not introduce any security issues), we propose this >> extension. >> >> We are always open for discussions, (critical) feedback, suggestions, ... >> >> Regards >> Carolin Latze >> >> >> -------- Original Message -------- >> Subject: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt >> Date: Wed, 7 Oct 2009 16:45:01 +0200 >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Transport Layer Security (TLS) Extensions for the Trusted Platform Module (TPM) >> Author(s) : C. Latze, et al. >> Filename : draft-latze-tls-tpm-extns-00.txt >> Pages : 10 >> Date : 2009-10-07 >> >> Trusted Platform Modules (TPMs) become more and more widespread in >> modern desktop and laptop computers and provide secure storage and >> cryptographic functions. As one nice feature of TPMs is that they >> can be identified uniquely, they provide a good base for device >> authentication in protocols like TLS.This document specifies a TLS >> extension that allows to use TPM certified keys with TLS in order to >> allow for a secure and comfortable device authentication in TLS. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> >> > > From Pasi.Eronen@nokia.com Wed Oct 14 03:40:42 2009 Return-Path: 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 2FAB63A6884 for ; Wed, 14 Oct 2009 03:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 8H8RLwBtdoLR for ; Wed, 14 Oct 2009 03:40:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AF0E33A680C for ; Wed, 14 Oct 2009 03:40:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9EAeFRW015069; Wed, 14 Oct 2009 13:40:39 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:40:15 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:39:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:39:54 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 14 Oct 2009 12:39:53 +0200 From: To: , Date: Wed, 14 Oct 2009 12:39:51 +0200 Thread-Topic: [TLS] Decryption_failed alert in TLS 1.1 Thread-Index: AcnJsYvQ+I/CT+uWReiAwKtlCgEV7hz/oICAA8KXwOA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099FDE71@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F24D50BE@NOK-EUMSG-01.mgdnok.nokia.com> <20090430163727.17D9A194FC4@kilo.networkresonance.com> <808FD6E27AD4884E94820BC333B2DB773C096DD1FA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C096DD1FA@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 10:39:54.0304 (UTC) FILETIME=[AA959C00:01CA4CBA] X-Nokia-AV: Clean Subject: Re: [TLS] Decryption_failed alert in TLS 1.1 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 10:40:42 -0000 Pasi Eronen wrote: > Unless I hear any objections soon, I will mark this as "Verified", > and Errata ID 117 as "Held for Document Update". This has now been done. Best regards, Pasi From Pasi.Eronen@nokia.com Wed Oct 14 04:08:33 2009 Return-Path: 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 5B68C3A69AD for ; Wed, 14 Oct 2009 04:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 yZcXL0rc1fAJ for ; Wed, 14 Oct 2009 04:08:32 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 47F823A6997 for ; Wed, 14 Oct 2009 04:08:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9EB8IjQ006933; Wed, 14 Oct 2009 14:08:28 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:08:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:08:22 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 14 Oct 2009 13:08:21 +0200 From: To: , Date: Wed, 14 Oct 2009 13:08:21 +0200 Thread-Topic: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt] Thread-Index: AcpIt3HuwwDn9kfTQ4OZEzl2dElcHQEBdyiQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com> References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> <4ACEEEB5.9000803@unifr.ch> In-Reply-To: <4ACEEEB5.9000803@unifr.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 11:08:22.0783 (UTC) FILETIME=[A4EAD0F0:01CA4CBE] X-Nokia-AV: Clean Cc: tls@ietf.org Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:08:33 -0000 TCG-compliant AIK Certificates are pretty much useless for authenticating devices, since the whole point of Privacy CA and AIK Certificates is to=20 hide the real device identity/identifier for privacy purposes. A valid AIK Credential asserts that the AIK private key is in *some* genuine conforming TPM, but doesn't really contain device identifiers=20 that would be useful for authentication of a specific device.=20 IMHO situations where you'd want to allow access to anyone who has a genuine TPM (but nobody else) are pretty rare... (and would=20 probably involve a "remote attestation" about what software the device is currently running -- so don't really belong in TLS anyway). Best regards, Pasi (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Carolin Latze > Sent: 09 October, 2009 11:05 > To: Blumenthal, Uri > Cc: 'tls@ietf.org' > Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns- > 00.txt] >=20 > Ok, >=20 > > > > Are you implying that CA-certified certs are less secure than self- > signed ones?! Or that getting your TPM-provided Public Key signed by a > CA lessens its security? > > > [CL] No, nothing like that. I think my english might be a problem, but > I > try to explain what I mean: >=20 > TPMs come with the possibility to create so called attestation identity > keys (AIKs) that will be signed by a certain certificate authority > called Privacy CA resulting in an AIK certificate. The process of > signing by the Privacy CA includes verifying that those keys have been > generated by a genuine TPM. The private part of the AIK never leaves > the > TPM, which means that the AIK certificates prove that they belong to a > genuine, given TPM. The AIK certificate is a valid X.509 certificate, > which can be verified using the standard X.509 verification functions. > So if you use those certificates in authentication protocols you can > authenticate devices (using their TPM). But, unfortunatly, those keys > have some restrictions which makes it impossible to use them in TLS > direclty: >=20 > 1) they are restricted to SHA-1 signing (well, that should not be a > problem with TLS 1.2) > 2) they only sign data that originates in the TPM (that means in order > to use them with TLS, every data that has to be signed has to originate > in the TPM, which is not impossible and might be useful in some cases, > but is rather complicated) >=20 > In order to be able to use something like the AIKs in authentication, > the TPM standard propose to define new keys (with the property that the > private part never leaves the TPM) and sign them using the AIK. That > signing process is also defined in the standard and results in a > special > structure called TCPA_CERTIFY_INFO. That structure proves that a > certified key has been signed by a valid AIK, which itself can be > verified using standard X.509 verification techniques. Unfortunatly, > TCPA_CERTIFY_INFO does not have the same format like X.509. The > certified key could be used in TLS directly, but how do we verify that > it belongs to a given TPM? There are several solutions that all rely on > the fact, that the AIK certificate proves that this certificate key > belongs to a genuine, given TPM: >=20 > 1) Make it an X.509 certificate signed by the AIK (=3D> results in > complete easy to verify chain). This is not possible since the AIK > certificate carries the CA:false constraint. > 2) Make it an X.509 proxy certificate of the AIK. Not possible since > the > subject of the AIK is NULL. >=20 > Those would be the easy possibilities, but since they do not work, the > TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO > structure called SKAE. Again two possibilities arise to make use of > that > extension: >=20 > 1) Generate a new X.509 certificate request around the certified key, > include the SKAE extension, and send the request to a CA to sign it. > This results in a standard X.509 certificate that can be used for TLS. > But if the server wants to ensure that this certificate is bound (=3D the > private key never leaves the TPM) to a certain genuine TPM, he has to > verify the SKAE extension too. That means he has to get the AIK > certificate too, which is not part of the chain. The SKAE extension > carries a hint where to find that certificate. Now my opinion to that > approach: A second certificate request is needed (apart from the AIK > certificate request needed anyway), which is overkill (just my opinion, > I know, that other people do not have a problem with that) and - and > thats the bigger problem from my point of view - if the server really > wants to verify that the keys originates from a given, genuine TPM, he > has to download, request, get ... the AIK in addition to what he gets > out of the TLS handshake. So there has to be some kind of storage for > the AIK certificates, that either sends the AIK certificates to all the > servers or receives SKAE extensions from servers to validate them. I > think that might result in scalability problems (just my opinion). > 2) Generate an X.509 self-signed certificate around the certified key > including the SKAE extension, use it in the handshake and send the AIK > certificate that verifies the SKAE extension within the supplemental > data handshake message. I think that approach has a better scalability. >=20 > BTW: Everything I described above is only needed if you want to use > those special keys. If you only want to use the TPM as a key storage > and > secure provider for functions like signing etc, there is no need for > any > modification to TLS and X.509. The reason why I want to use those > special keys is that they are available and have those nice properties > of being (provable) bound to a genuine, given TPM. If you ask me now to > ignore those keys if they introduce those difficulties then I think > that > is a valid conclusion. I only think that there should be a possibility > to use them if they are available. > > And how can self-signed certs be possibly bound to "identity certs > signed by a CA"? > > > [CL] Using that SKAE extension explained above. > > I still don't understand your justification (or reasons) for mucking > with a perfectly usable TLS model. > > > [CL] I think I tried to explain that above > > Perhaps you'd want to describe in a few sentences what it is that > you're trying to accomplish with TPM-generated public keys, and how TLS > as-is does not allow that? And why what you're trying to do would of > interest to anybody else on the planet who uses TPM and/or TLS? > > > [CL] I think I tried to explain that too. I think, AIKs and certified > keys are a good possibility to authentication TPM equipped devices even > if they introduce some difficulties. But I also see the problem that > TLS > has been available much longer than TPMs, so it would have been easy to > adapt the TPM to TLS needs instead to do it vice versa. I have not been > part of the TPM standardization although I try to discuss with TCG > people too. There might be good reason for the things they defined that > I do not see at the moment. And since TPMs are already shipped with all > the features described above I try to make it usable like that. > > > > ----- Original Message ----- > > From: Carolin Latze > > To: Blumenthal, Uri > > Sent: Thu Oct 08 04:02:09 2009 > > Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm- > extns-00.txt] > > > > They are still valid X.509... the only difference is that they are > > self-signed and not CA-signed. And the reason to use self-signed > > certificates is that you don't need to send another certificate > request > > without loosing security since the self-signed certificates are bound > to > > identity certificates that are signed by a CA. > > > > Blumenthal, Uri wrote: > > > >> And the reason you want to do this instead of using valid X.509 > certs is...? > >> > >> > >> ----- Original Message ----- > >> From: tls-bounces@ietf.org > >> To: tls@ietf.org > >> Sent: Wed Oct 07 11:16:52 2009 > >> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns- > 00.txt] > >> > >> Hi all, > >> > >> after several experiments with TPMs as authentication devices in > >> EAP-TLS, we figured out, that the specific modifications in order to > use > >> TPMs might be rather an extension to TLS than an EAP extension. > >> Therefore, we gave it a try and defined a new TLS extension in order > to > >> use TPM certified keys directly with TLS. We are aware of the fact, > that > >> there is a possibility to request new valid X.509 certificates for > those > >> keys which allows to use them with standard TLS (and do not require > a > >> new extension), but since we want to avoid that request (and we > think > >> that this does not introduce any security issues), we propose this > >> extension. > >> > >> We are always open for discussions, (critical) feedback, > suggestions, ... > >> > >> Regards > >> Carolin Latze > >> > >> > >> -------- Original Message -------- > >> Subject: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt > >> Date: Wed, 7 Oct 2009 16:45:01 +0200 > >> From: Internet-Drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> > >> Title : Transport Layer Security (TLS) Extensions for > the Trusted Platform Module (TPM) > >> Author(s) : C. Latze, et al. > >> Filename : draft-latze-tls-tpm-extns-00.txt > >> Pages : 10 > >> Date : 2009-10-07 > >> > >> Trusted Platform Modules (TPMs) become more and more widespread in > >> modern desktop and laptop computers and provide secure storage and > >> cryptographic functions. As one nice feature of TPMs is that they > >> can be identified uniquely, they provide a good base for device > >> authentication in protocols like TLS.This document specifies a TLS > >> extension that allows to use TPM certified keys with TLS in order to > >> allow for a secure and comfortable device authentication in TLS. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> > >> > >> > >> > > > > >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From carolin.latze@unifr.ch Wed Oct 14 07:00:57 2009 Return-Path: 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 7106B3A6A03 for ; Wed, 14 Oct 2009 07:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 9oyeH-1gJiin for ; Wed, 14 Oct 2009 07:00:55 -0700 (PDT) Received: from sr-svx-320.unifr.ch (sr-svx-320.unifr.ch [134.21.214.75]) by core3.amsl.com (Postfix) with ESMTP id 6B7CF3A691B for ; Wed, 14 Oct 2009 07:00:55 -0700 (PDT) Received: from diufpc272.unifr.ch ([134.21.72.156]) by sr-svx-320.unifr.ch stage1 with esmtp with id 1My4PB-0006e8-TQ for from ; Wed, 14 Oct 2009 16:00:41 +0200 Message-ID: <4AD5D90F.4000005@unifr.ch> Date: Wed, 14 Oct 2009 15:58:39 +0200 From: Carolin Latze User-Agent: Thunderbird 2.0.0.23 (X11/20090916) MIME-Version: 1.0 To: "tls@ietf.org" References: <90E934FC4BBC1946B3C27E673B4DB0E4A7E75F6BC8@LLE2K7-BE01.mitll.ad.local> <4ACEEEB5.9000803@unifr.ch> <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C099FDECA@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:00:57 -0000 Pasi.Eronen@nokia.com wrote: > TCG-compliant AIK Certificates are pretty much useless for authenticating > devices, since the whole point of Privacy CA and AIK Certificates is to > hide the real device identity/identifier for privacy purposes. > A valid AIK Credential asserts that the AIK private key is in *some* > genuine conforming TPM, but doesn't really contain device identifiers > that would be useful for authentication of a specific device. > > IMHO situations where you'd want to allow access to anyone who has > a genuine TPM (but nobody else) are pretty rare... [CL] At the moment, yes. But that might change in the future. I can imagine scenarios, where it is sufficient to know that the client device has a genuine TPM. Further remote attestation might follow later (or might not be necessary). Maybe it is sufficient, that the client has an AIK from a certain Privacy CA, because I, as a server, trust that Privacy CA, and since the client has a genuine TPM, I also know that the certificate really belongs to him (private key has not been copied to other machine etc). I can also imagine scenarios, where you bind a person to a device by contract or a scenario where you sell/provide devices that should be able to connect to your TLS secured services, so maybe, you run a Privacy CA yourself.... For me that depends on the business case itself.... (and I can also imagine scenarios, where it does not make any sense at all :-)). > (and would > probably involve a "remote attestation" about what software the > device is currently running -- so don't really belong in TLS anyway). > Best regards, > Pasi > (not wearing any hats) > > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Carolin Latze >> Sent: 09 October, 2009 11:05 >> To: Blumenthal, Uri >> Cc: 'tls@ietf.org' >> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns- >> 00.txt] >> >> Ok, >> >> >>> Are you implying that CA-certified certs are less secure than self- >>> >> signed ones?! Or that getting your TPM-provided Public Key signed by a >> CA lessens its security? >> >> [CL] No, nothing like that. I think my english might be a problem, but >> I >> try to explain what I mean: >> >> TPMs come with the possibility to create so called attestation identity >> keys (AIKs) that will be signed by a certain certificate authority >> called Privacy CA resulting in an AIK certificate. The process of >> signing by the Privacy CA includes verifying that those keys have been >> generated by a genuine TPM. The private part of the AIK never leaves >> the >> TPM, which means that the AIK certificates prove that they belong to a >> genuine, given TPM. The AIK certificate is a valid X.509 certificate, >> which can be verified using the standard X.509 verification functions. >> So if you use those certificates in authentication protocols you can >> authenticate devices (using their TPM). But, unfortunatly, those keys >> have some restrictions which makes it impossible to use them in TLS >> direclty: >> >> 1) they are restricted to SHA-1 signing (well, that should not be a >> problem with TLS 1.2) >> 2) they only sign data that originates in the TPM (that means in order >> to use them with TLS, every data that has to be signed has to originate >> in the TPM, which is not impossible and might be useful in some cases, >> but is rather complicated) >> >> In order to be able to use something like the AIKs in authentication, >> the TPM standard propose to define new keys (with the property that the >> private part never leaves the TPM) and sign them using the AIK. That >> signing process is also defined in the standard and results in a >> special >> structure called TCPA_CERTIFY_INFO. That structure proves that a >> certified key has been signed by a valid AIK, which itself can be >> verified using standard X.509 verification techniques. Unfortunatly, >> TCPA_CERTIFY_INFO does not have the same format like X.509. The >> certified key could be used in TLS directly, but how do we verify that >> it belongs to a given TPM? There are several solutions that all rely on >> the fact, that the AIK certificate proves that this certificate key >> belongs to a genuine, given TPM: >> >> 1) Make it an X.509 certificate signed by the AIK (=> results in >> complete easy to verify chain). This is not possible since the AIK >> certificate carries the CA:false constraint. >> 2) Make it an X.509 proxy certificate of the AIK. Not possible since >> the >> subject of the AIK is NULL. >> >> Those would be the easy possibilities, but since they do not work, the >> TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO >> structure called SKAE. Again two possibilities arise to make use of >> that >> extension: >> >> 1) Generate a new X.509 certificate request around the certified key, >> include the SKAE extension, and send the request to a CA to sign it. >> This results in a standard X.509 certificate that can be used for TLS. >> But if the server wants to ensure that this certificate is bound (= the >> private key never leaves the TPM) to a certain genuine TPM, he has to >> verify the SKAE extension too. That means he has to get the AIK >> certificate too, which is not part of the chain. The SKAE extension >> carries a hint where to find that certificate. Now my opinion to that >> approach: A second certificate request is needed (apart from the AIK >> certificate request needed anyway), which is overkill (just my opinion, >> I know, that other people do not have a problem with that) and - and >> thats the bigger problem from my point of view - if the server really >> wants to verify that the keys originates from a given, genuine TPM, he >> has to download, request, get ... the AIK in addition to what he gets >> out of the TLS handshake. So there has to be some kind of storage for >> the AIK certificates, that either sends the AIK certificates to all the >> servers or receives SKAE extensions from servers to validate them. I >> think that might result in scalability problems (just my opinion). >> 2) Generate an X.509 self-signed certificate around the certified key >> including the SKAE extension, use it in the handshake and send the AIK >> certificate that verifies the SKAE extension within the supplemental >> data handshake message. I think that approach has a better scalability. >> >> BTW: Everything I described above is only needed if you want to use >> those special keys. If you only want to use the TPM as a key storage >> and >> secure provider for functions like signing etc, there is no need for >> any >> modification to TLS and X.509. The reason why I want to use those >> special keys is that they are available and have those nice properties >> of being (provable) bound to a genuine, given TPM. If you ask me now to >> ignore those keys if they introduce those difficulties then I think >> that >> is a valid conclusion. I only think that there should be a possibility >> to use them if they are available. >> >>> And how can self-signed certs be possibly bound to "identity certs >>> >> signed by a CA"? >> >> [CL] Using that SKAE extension explained above. >> >>> I still don't understand your justification (or reasons) for mucking >>> >> with a perfectly usable TLS model. >> >> [CL] I think I tried to explain that above >> >>> Perhaps you'd want to describe in a few sentences what it is that >>> >> you're trying to accomplish with TPM-generated public keys, and how TLS >> as-is does not allow that? And why what you're trying to do would of >> interest to anybody else on the planet who uses TPM and/or TLS? >> >> [CL] I think I tried to explain that too. I think, AIKs and certified >> keys are a good possibility to authentication TPM equipped devices even >> if they introduce some difficulties. But I also see the problem that >> TLS >> has been available much longer than TPMs, so it would have been easy to >> adapt the TPM to TLS needs instead to do it vice versa. I have not been >> part of the TPM standardization although I try to discuss with TCG >> people too. There might be good reason for the things they defined that >> I do not see at the moment. And since TPMs are already shipped with all >> the features described above I try to make it usable like that. >> >>> ----- Original Message ----- >>> From: Carolin Latze >>> To: Blumenthal, Uri >>> Sent: Thu Oct 08 04:02:09 2009 >>> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm- >>> >> extns-00.txt] >> >>> They are still valid X.509... the only difference is that they are >>> self-signed and not CA-signed. And the reason to use self-signed >>> certificates is that you don't need to send another certificate >>> >> request >> >>> without loosing security since the self-signed certificates are bound >>> >> to >> >>> identity certificates that are signed by a CA. >>> >>> Blumenthal, Uri wrote: >>> >>> >>>> And the reason you want to do this instead of using valid X.509 >>>> >> certs is...? >> >>>> ----- Original Message ----- >>>> From: tls-bounces@ietf.org >>>> To: tls@ietf.org >>>> Sent: Wed Oct 07 11:16:52 2009 >>>> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns- >>>> >> 00.txt] >> >>>> Hi all, >>>> >>>> after several experiments with TPMs as authentication devices in >>>> EAP-TLS, we figured out, that the specific modifications in order to >>>> >> use >> >>>> TPMs might be rather an extension to TLS than an EAP extension. >>>> Therefore, we gave it a try and defined a new TLS extension in order >>>> >> to >> >>>> use TPM certified keys directly with TLS. We are aware of the fact, >>>> >> that >> >>>> there is a possibility to request new valid X.509 certificates for >>>> >> those >> >>>> keys which allows to use them with standard TLS (and do not require >>>> >> a >> >>>> new extension), but since we want to avoid that request (and we >>>> >> think >> >>>> that this does not introduce any security issues), we propose this >>>> extension. >>>> >>>> We are always open for discussions, (critical) feedback, >>>> >> suggestions, ... >> >>>> Regards >>>> Carolin Latze >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt >>>> Date: Wed, 7 Oct 2009 16:45:01 +0200 >>>> From: Internet-Drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> >> directories. >> >>>> Title : Transport Layer Security (TLS) Extensions for >>>> >> the Trusted Platform Module (TPM) >> >>>> Author(s) : C. Latze, et al. >>>> Filename : draft-latze-tls-tpm-extns-00.txt >>>> Pages : 10 >>>> Date : 2009-10-07 >>>> >>>> Trusted Platform Modules (TPMs) become more and more widespread in >>>> modern desktop and laptop computers and provide secure storage and >>>> cryptographic functions. As one nice feature of TPMs is that they >>>> can be identified uniquely, they provide a good base for device >>>> authentication in protocols like TLS.This document specifies a TLS >>>> extension that allows to use TPM certified keys with TLS in order to >>>> allow for a secure and comfortable device authentication in TLS. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de Pérolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From jsalowey@cisco.com Thu Oct 15 11:07:18 2009 Return-Path: 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 4D1773A69B6 for ; Thu, 15 Oct 2009 11:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eGrPfM3OS1CL for ; Thu, 15 Oct 2009 11:07:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A22C03A68FB for ; Thu, 15 Oct 2009 11:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=257; q=dns/txt; s=sjiport01001; t=1255630041; x=1256839641; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20TLS=20meeting=20at=20IETF=2076|Date:=20 Thu,=2015=20Oct=202009=2011:07:19=20-0700|Message-ID:=20< AC1CFD94F59A264488DC2BEC3E890DE508E8AAED@xmb-sjc-225.amer .cisco.com>|To:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable; bh=OUIag0Q8VJzi6/Qn+pG6Ei4Vc++mljf9ZKIe6YIHgyU=; b=Do1++HeHmPow1/5y+wN5bjUIsk1ToX3qplgx9iJ1tSz+d7ypfyFc0yCp sBpTYybNsvtJTExlaDhq96a1fWL4OenX7LdaIGpjM1nceCt0Wbca/c8Ba HpSmbMqyM+PF9Vs35/ZULiWCOnF4rQ06hqlUV4cEYZNwoMEv9ksvMhFle 0=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPkA10qrR7Hu/2dsb2JhbADBYZhJhDAE X-IronPort-AV: E=Sophos;i="4.44,567,1249257600"; d="scan'208";a="256619676" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2009 18:07:21 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9FI7Kru025474 for ; Thu, 15 Oct 2009 18:07:21 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:07:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 11:07:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS meeting at IETF 76 Thread-Index: AcpNwlY+WzTlu5BbR7mCYD2hlNGFUQ== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Oct 2009 18:07:20.0902 (UTC) FILETIME=[56D11E60:01CA4DC2] Subject: [TLS] TLS meeting at IETF 76 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:07:18 -0000 On the DRAFT agenda TLS is scheduled to meet on THURSDAY, November 12, 2009: 1510-1610 Afternoon Session II Acacia 1 SEC tls Transport Layer Security WG Let me know if you have an items you would like to add to the agenda. =20 Cheers, Joe From Pascal.Urien@enst.fr Thu Oct 15 11:36:10 2009 Return-Path: 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 2B8F13A67B1 for ; Thu, 15 Oct 2009 11:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 o9qgJ81tmNvi for ; Thu, 15 Oct 2009 11:36:09 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [137.194.2.14]) by core3.amsl.com (Postfix) with ESMTP id 58FAA3A67A7 for ; Thu, 15 Oct 2009 11:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id AF82DB8B7D; Thu, 15 Oct 2009 20:31:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from PC-de-pascal.enst.fr (sony-urien.enst.fr [137.194.164.119]) by smtp2.enst.fr (Postfix) with ESMTP id 44326B8A8F; Thu, 15 Oct 2009 20:31:34 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Oct 2009 20:31:18 +0200 To: "Joseph Salowey (jsalowey)" , From: Pascal Urien In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091015183134.44326B8A8F@smtp2.enst.fr> Subject: Re: [TLS] TLS meeting at IETF 76 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:36:10 -0000 Hi Joe, I would like a slot to present the draft http://www.ietf.org/staging/draft-urien-tls-psk-emv-00.txt Title: EMV support for TLS-PSK Creation_date: 2009-10-15 WG ID: Indvidual Submission Number_of_pages: 12 Abstract: This draft describes an authentication protocol based on TLS pre shared key (TLS-PSK), RFC 4279. Identity and psk attributes, defined in TLS-PSK are extracted from EMV chips, which are widely deployed for payments transactions. The goal of this protocol is to provide a strong mutual authentication transparent for the end users and guarantying the confidentiality and the integrity of exchanged data over Internet network. This is a new step avoiding the use of static passwords for on-line services, such as electronic banking or electronic payment. Best Regards Pascal At 20:07 15/10/2009, Joseph Salowey (jsalowey) wrote: >On the DRAFT agenda TLS is scheduled to meet on THURSDAY, November 12, >2009: > >1510-1610 Afternoon Session II >Acacia 1 SEC tls Transport Layer Security WG > >Let me know if you have an items you would like to add to the agenda. > >Cheers, > >Joe >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From yngve@opera.com Fri Oct 16 12:35:31 2009 Return-Path: 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 1F6D928C0E5 for ; Fri, 16 Oct 2009 12:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AhLMf+54MXvs for ; Fri, 16 Oct 2009 12:35:30 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 0E5EC28C0CF for ; Fri, 16 Oct 2009 12:35:29 -0700 (PDT) Received: from acorna.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9GJZGdr027227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Oct 2009 19:35:17 GMT Date: Fri, 16 Oct 2009 21:35:26 +0200 To: "tls@ietf.org" From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20091016193002.586F73A68EC@core3.amsl.com> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20091016193002.586F73A68EC@core3.amsl.com> User-Agent: Opera Mail/9.65 (Win32) Subject: [TLS] Fwd: I-D Action:draft-pettersen-tls-ext-multiple-ocsp-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:35:31 -0000 ------- Forwarded message ------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-pettersen-tls-ext-multiple-ocsp-00.txt Date: Fri, 16 Oct 2009 21:30:02 +0200 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Adding Multiple TLS Certificate Status Extension requests Author(s) : Y. Pettersen Filename : draft-pettersen-tls-ext-multiple-ocsp-00.txt Pages : 9 Date : 2009-10-16 This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. Also being introduced is a new OCSP based method that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pettersen-tls-ext-multiple-ocsp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- Sincerely, Yngve N. Pettersen   ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From ocl@gih.com Sat Oct 17 03:44:00 2009 Return-Path: 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 1BE5A3A67CC for ; Sat, 17 Oct 2009 03:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 7xpFBqrMYjhd for ; Sat, 17 Oct 2009 03:43:58 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2001:470:1f09:92d::b]) by core3.amsl.com (Postfix) with ESMTP id EA12C3A659B for ; Sat, 17 Oct 2009 03:43:54 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id 0B3CF18F3AD for ; Sat, 17 Oct 2009 11:43:57 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:from :to:subject:date:mime-version:content-type; s=mahalo1; bh=vG4IbT IdKfiZqW+5f/YpqBnJnZw=; b=g2dJNaAELhcvSZ2jhvuCIFNAIHkANv5uSqqJLr ZefbgUXdlSrhv9SMBq6sJoA7GkjjiX/scZSSGRErkdnlqeCUvwxYpogZ+KtGEjuc XyU156uWa9Eb6L6JaPldJ/saz/is26u4bdan2En3TAJNfzH0Zikkyz45TXm/fjid f/pSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:from :to:subject:date:mime-version:content-type; q=dns; s=mahalo1; b= OIAYscBrMI4Ez7fjXwNAOa1Tf1c6Ahmy3X6p8iUC0qEMJWtZQ0EoytIOW31cztol T1dN1zZjcf/ihOCZCU4xw3CwNUvKHg1aj1V47vaOpavmRENnAuqpYeA6gPR0LNVt xkc4CPRY594KnIiQ3OVvcGUJBlvBnwkt6qog+9V8X3M= Received: from ALOHA2 (ANice-151-1-13-111.w83-113.abo.wanadoo.fr [83.113.216.111]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id 2883F18F3AB for ; Sat, 17 Oct 2009 11:43:56 +0100 (BST) Message-ID: <4FD799C7F81B44C094DFF8409F368F35@GIH.CO.UK> From: "Olivier MJ Crepin-Leblond" To: Date: Sat, 17 Oct 2009 12:42:06 +0200 Organization: Global Information Highway Ltd MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0152_01CA4F27.3C56C9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [TLS] Ordered list of cypher strengths 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 10:44:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0152_01CA4F27.3C56C9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello there, could someone please point me to references or a page discussing cypher = strengths and listing them in increasing order, in an email specific = context? For example, I'm seeing emails transfers which seem to be = using: - AES256-SHA - RC4-MD5 - DHE-RSA-AES256-SHA - ADH-AES256-SHA - EDH-RSA-DES-CBC3-SHA etc. I know of the page: http://www.openssl.org/docs/apps/ciphers.html which = lists cypher suites, but are these listed in order of increasing = strength? Warm regards, --=20 Olivier MJ Cr=E9pin-Leblond, PhD http://www.gih.com/ocl.html ------=_NextPart_000_0152_01CA4F27.3C56C9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello there,
 
could someone please point me to = references or a=20 page discussing cypher strengths and listing them in increasing order, = in an=20 email specific context? For example, I'm seeing emails transfers which = seem to=20 be using:
 
- AES256-SHA
- RC4-MD5
- DHE-RSA-AES256-SHA
- ADH-AES256-SHA
- EDH-RSA-DES-CBC3-SHA
 
etc.
 
I know of the page: http://www.openssl= .org/docs/apps/ciphers.html which=20 lists cypher suites, but are these listed in order of increasing=20 strength?
 
Warm regards,
 
--
Olivier MJ Cr=E9pin-Leblond, = PhD
http://www.gih.com/ocl.html
 
 
 
------=_NextPart_000_0152_01CA4F27.3C56C9C0-- From mike-list@pobox.com Sat Oct 17 08:34:11 2009 Return-Path: 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 50A5F3A68AE for ; Sat, 17 Oct 2009 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qQaRkAoLW4lz for ; Sat, 17 Oct 2009 08:34:09 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id CD4EC3A6827 for ; Sat, 17 Oct 2009 08:34:08 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 6CC167BB18 for ; Sat, 17 Oct 2009 11:34:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=hWSb23F4uzLn gJouhEMj6yKGoXE=; b=dSu3Kf3zvtJmcr44Ox9typCN2lWQHinMLiZjLRedQUzu IzdO+aM/PEB2pFv2oUA7XRnNH+IryIJgvLS7ZPRKaX3Segd3AcgskOsAHS9y/uzB lPgKGfe/pym0DiWcpEpPtLmvuNqb2wat5NxYh8dJnvDNkrSr4syp+KgD+y5aTGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=PbRrGZ e+yqu6D1DqCDlL9VL05nAGBXVYE0i3nGBrruR5t9Kk3jOY3U8pKJfBMqpoPkLfS1 pPaTBj8qNJ/TI/KzNE5XxynwxwS0Eo0KZQ6gFdVFAO+T+tMqX62/ZUN7hgU+INlO K51a1yZ/Al+KBa+N8CVxxtJcKcbwQ6zqWD5wo= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 69EE57BB17 for ; Sat, 17 Oct 2009 11:34:13 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id E95E47BB16 for ; Sat, 17 Oct 2009 11:34:12 -0400 (EDT) Message-ID: <4AD9E408.7040709@pobox.com> Date: Sat, 17 Oct 2009 08:34:32 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4FD799C7F81B44C094DFF8409F368F35@GIH.CO.UK> In-Reply-To: <4FD799C7F81B44C094DFF8409F368F35@GIH.CO.UK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Pobox-Relay-ID: 85B8955E-BB32-11DE-9C81-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] Ordered list of cypher strengths 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 15:34:11 -0000 This is a difficult question to answer. There are three factors to consider when determining the relative strengths of cipher suites. First there is the key exchange mechanism, such as RSA, DHE_DSS, etc. Second is the bulk encryption algorithm and key length, and third is the MAC. The key exchange mechanism is problematic because there is no way to specify the key length by the client; the server selects it. Many servers use 1024-bit RSA keys and 1024-bit Diffie-Hellman parameters which roughly correspond to "only" 80 bits of security. This may be the weak link. Using AES-256 may provide no more security than RC4 if a 1024-bit RSA key exchange is done. I know this is not the answer you were hoping for, but the reality is you can't create the list you want. Also, with email, messages are only protected in transit. The server at each hop will have the full plaintext of your message. And even if the first hop uses TLS for that transfer, there is no guarantee that TLS will be used on every transfer all the way to the recipient. And then once it's at the recipient, you don't know that they've set up their mail client to use TLS with POP3 or IMAP. Mike ---- http://mikestoolbox.com Olivier MJ Crepin-Leblond wrote: > Hello there, > =20 > could someone please point me to references or a page discussing cypher= =20 > strengths and listing them in increasing order, in an email specific=20 > context? For example, I'm seeing emails transfers which seem to be usin= g: > =20 > - AES256-SHA > - RC4-MD5 > - DHE-RSA-AES256-SHA > - ADH-AES256-SHA > - EDH-RSA-DES-CBC3-SHA > =20 > etc. > =20 > I know of the page: http://www.openssl.org/docs/apps/ciphers.html which= =20 > lists cypher suites, but are these listed in order of increasing streng= th? > =20 > Warm regards, > =20 > --=20 > Olivier MJ Cr=E9pin-Leblond, PhD > http://www.gih.com/ocl.html From seggelmann@fh-muenster.de Mon Oct 19 05:25:22 2009 Return-Path: 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 5FCDD3A69CD for ; Mon, 19 Oct 2009 05:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] 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 fP+tp5ITmYtR for ; Mon, 19 Oct 2009 05:25:21 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by core3.amsl.com (Postfix) with ESMTP id 5F0843A69A0 for ; Mon, 19 Oct 2009 05:25:21 -0700 (PDT) Received: from [194.95.73.153] (helo=[10.0.1.100]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MzrIk-0002D0-Na for tls@ietf.org; Mon, 19 Oct 2009 14:25:26 +0200 Message-Id: <077092A1-F995-4880-9062-CD40B45955BA@fh-muenster.de> From: Robin Seggelmann To: tls@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 14:25:25 +0200 References: X-Mailer: Apple Mail (2.936) X-Df-Sender: mail@robin-seggelmann.de Subject: Re: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 12:25:22 -0000 On Oct 8, 2009, at 8:01 PM, Joseph Salowey (jsalowey) wrote: > This is an announcement for working group last call on DTLS 1.2 (RFC > 4347-bis). The document is available here: > > http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03 > > Please send any comments to the list by October 26, 2009. It is > useful > to send an indication to the list if you have read the document and > think it is ready for publication even if you don't have specific > comments. In my opinion it's ready and I have no further comments. Regards, Robin From Michael.Tuexen@lurchi.franken.de Thu Oct 22 09:10:13 2009 Return-Path: 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 387AD3A6891 for ; Thu, 22 Oct 2009 09:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] 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 jwwtxIgxfg1v for ; Thu, 22 Oct 2009 09:10:11 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 3623A3A67FA for ; Thu, 22 Oct 2009 09:10:11 -0700 (PDT) Received: from [192.168.1.100] (p508FD78C.dip.t-dialin.net [80.143.215.140]) by mail-n.franken.de (Postfix) with ESMTP id 375B11C0B4636; Thu, 22 Oct 2009 18:10:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Thu, 22 Oct 2009 18:10:17 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1076) Cc: tls@ietf.org Subject: Re: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:10:13 -0000 Hi Josef, I read the ID and I'm fine with it. Best regards Michael On Oct 8, 2009, at 8:01 PM, Joseph Salowey (jsalowey) wrote: > This is an announcement for working group last call on DTLS 1.2 (RFC > 4347-bis). The document is available here: > > http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03 > > Please send any comments to the list by October 26, 2009. It is > useful > to send an indication to the list if you have read the document and > think it is ready for publication even if you don't have specific > comments. > > Thanks, > > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Henry.Story@Sun.COM Thu Oct 22 09:21:33 2009 Return-Path: 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 0AFC428C16F for ; Thu, 22 Oct 2009 09:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_43=0.6, 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 gicNFG62iNO8 for ; Thu, 22 Oct 2009 09:21:32 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id B2FE728C0EB for ; Thu, 22 Oct 2009 09:21:31 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9MGLdPr021287 for ; Thu, 22 Oct 2009 16:21:40 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRX00600BTDYQ00@fe-emea-10.sun.com> for tls@ietf.org; Thu, 22 Oct 2009 17:21:20 +0100 (BST) Received: from dyn-229.club.berlin.ccc.de ([unknown] [195.160.172.2]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRX00JWTC3J0AE0@fe-emea-10.sun.com> for tls@ietf.org; Thu, 22 Oct 2009 17:21:19 +0100 (BST) Date: Thu, 22 Oct 2009 18:21:18 +0200 From: Henry Story Sender: Henry.Story@Sun.COM To: tls@ietf.org Message-id: <4FBCA55F-03F3-43AF-92DD-DC0455BB97A1@Sun.COM> X-Mailer: Apple Mail (2.1076) Subject: [TLS] Nov 2nd, Social Web Camp in Santa Clara 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:21:33 -0000 Dear TLS group, We are organising a social web camp in the Sun Microsystems offices of Santa Clara where I will be presenting foaf+ssl, which uses TLS at its core to enable a really decentralised social network that fits with the web architecture. You can see a short presentation of that which I gave at Hacking at Random http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009 (requires Firefox 3.5) The camp will look at this and the broader implications of a decentralised social web. You are all welcome to come, with friends and participate. Entry is free. ---- You are invited to the Social Web Camp, taking place in the Sun Microsystems Campus in Santa Clara on Monday November 2. It is organised by Henry Story of Sun and Daniel Appelquist of Vodafone, co- chair of the W3C Social Web Incubator. Entry is free. Imagine a world where everybody could participate easily in a distributed yet secure social web. In such a world people could place their photos, music, or other content on their web site and give access to some of it to their friends, or the friend of their friends (FOAF) some to their family, some to their colleagues, and of course have some be completely public. How can one do this without requiring every participant to create one login for each of their friends site? How does one do this in a distributed and flexible manner compatible with web architecture? What issues would need to be solved to make this possible? All topics related to the Social Web will be covered, in a bar-camp style. It will be broad and open to all. See the subjects up for discussuion on the wiki/registration page: http://barcamp.org/SocialWebCamp-Santa-Clara When: Monday, 2nd of November starting 9:00 am ( up to 5pm ) Where: The Auditorium at Sun's Campus, 4030 George Sellon Circle Santa Clara, 95054 California Please forward to interested parties, tweet, blog! Henry Story Social Web Architect Sun Microsystems Blog: http://blogs.sun.com/bblfish From n.mavrogiannopoulos@gmail.com Thu Oct 22 14:24:31 2009 Return-Path: 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 6E52928C195 for ; Thu, 22 Oct 2009 14:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 M-TZJheq6lf2 for ; Thu, 22 Oct 2009 14:24:30 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 88BDD28C198 for ; Thu, 22 Oct 2009 14:24:28 -0700 (PDT) Received: by fxm18 with SMTP id 18so9699681fxm.37 for ; Thu, 22 Oct 2009 14:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=cEaTFFyPIt/hsEIF8+rMqH56ikn5uglllTo+oPje8P8=; b=N9sT4IBVCtp9MJ2z96zHAFtq1LtJ2JDnQEJxGAuHGlFgP6xL0oQAD/rG40kqvucy/Q rQ1gci/w0z0k2hkrKo1oNXZg6bs8nA0o58FZr5j7q/scpGc+NVvQMZQnNf8o6WwWl3Kc gOKYF+lKx26/MgP3NW/YFy6WWvvBnrOPihIPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=nQWtfVwyi7oOXfT8yMtzeMtmzgThf2IdmjsrpY4G+wmDiTM3TiWPeavFLlzcDOYVfO KZz0iJukdvj4da/+slKthJbeHukR5SZOvws41b9usY498HdI0syC2TdQyqOulZqxz4fe QQEVHADNMGV2Mb9Mo/eFdvHZDouKHND45mZEE= Received: by 10.204.160.86 with SMTP id m22mr9936009bkx.82.1256246675188; Thu, 22 Oct 2009 14:24:35 -0700 (PDT) Received: from ?10.100.1.196? (adsl18-228.ath.forthnet.gr [77.49.209.228]) by mx.google.com with ESMTPS id 19sm1932002fkr.53.2009.10.22.14.24.33 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Oct 2009 14:24:34 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4AE0CD8F.6000508@gnutls.org> Date: Fri, 23 Oct 2009 00:24:31 +0300 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] TLS 1.2 and CertificateRequest message 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:24:31 -0000 Hello, I've been taking a look at TLS 1.2 and it seems that there is some new negotiation added at the CertificateRequest message. At this message the server is supposed to send a list of allowed algorithm for signature calculation, and the client should respond with a signature that depends on the previously exchanged handshake messages. In previous versions of TLS a client could just start the hash calculation for this signature during the exchange to avoid storing the actual messages up to this point. However with this negotiation at this point it is quite impossible to do that approach and as far as I understand needs to follow the store approach. My questions now are: 1. How is this implemented in compliant software today? 2. Why this negotiation was added? I see no added value of having such negotiation at a so late point. regards, Nikos From mike-list@pobox.com Thu Oct 22 15:06:26 2009 Return-Path: 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 73A8E3A67DA for ; Thu, 22 Oct 2009 15:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WCM2nBgaUxAl for ; Thu, 22 Oct 2009 15:06:25 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 6F05D3A67C0 for ; Thu, 22 Oct 2009 15:06:25 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 11F4382020 for ; Thu, 22 Oct 2009 18:06:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=O+99f9kc8AM4 4JPoCEojKoT2144=; b=aIuNyTMlQ60D2nYy3d6opGngldHY2OotmnH8mkingzV4 Cqk+jDr8xD1zpNfV+q+ZBVt0UWSmLSwU2b5RavMNXYQ8YKhnWnWUI+JwgFMHm4nb G0yWATfyGC4JKBPEbusbXYNc9EnD2qSP+Q3buHdNHciEhzylyEGDKmWC1fQ9pNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=R60dbH rfyUt9jNSubG+ZbOEmyrdhslshu0GE9y6GJvykREBIljix+N0xgTu5KpAwIXQosl dY29Ngd9prl74HuuAJpXyWHpFg2dU481DgLmfQ8/gsS4qPAYliiPOwUbY/SO/is1 6h03UltqgKxc/5tfsmrukZ+JUQKKhOBFEiV5Q= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0E09F8201F for ; Thu, 22 Oct 2009 18:06:35 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 55C8E8201E for ; Thu, 22 Oct 2009 18:06:33 -0400 (EDT) Message-ID: <4AE0D79A.5060608@pobox.com> Date: Thu, 22 Oct 2009 15:07:22 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AE0CD8F.6000508@gnutls.org> In-Reply-To: <4AE0CD8F.6000508@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 29AFF3DC-BF57-11DE-B468-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] TLS 1.2 and CertificateRequest message 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 22:06:26 -0000 I remember participating in the discussion that led to this design. I argued that since we added a signature algorithms extension to allow negotiation of the client's preferred algorithms, it made the most sense to make the extension symmetric so the server could notify the client of its preferred algorithms in its hello message as well. There was opposition to my argument, that the list of algorithms belongs where it is needed, in the certificate request message. The term "locality of reference" was thrown around as a justification. Not being an official member of the working group, and since nobody else seemed to prefer my idea, I forfeited the point. To solidify this design choice the definition of the signature algorithms extension states that the server MUST NOT send it. My own implementation holds onto all the handshake messages and calculates the hashes of them when needed. If you'd like to test interoperability with my server, https://www.mikestoolbox.net will ask you for a client certificate. Mike Nikos Mavrogiannopoulos wrote: > Hello, > I've been taking a look at TLS 1.2 and it seems that there is some new > negotiation added at the CertificateRequest message. At this message the > server is supposed to send a list of allowed algorithm for signature > calculation, and the client should respond with a signature that depends > on the previously exchanged handshake messages. > > In previous versions of TLS a client could just start the hash > calculation for this signature during the exchange to avoid storing the > actual messages up to this point. However with this negotiation at this > point it is quite impossible to do that approach and as far as I > understand needs to follow the store approach. > > My questions now are: > 1. How is this implemented in compliant software today? > > 2. Why this negotiation was added? I see no added value of having such > negotiation at a so late point. > > regards, > Nikos From mike-list@pobox.com Thu Oct 22 21:28:23 2009 Return-Path: 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 7F2073A681C for ; Thu, 22 Oct 2009 21:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 9xlORAyr55Q3 for ; Thu, 22 Oct 2009 21:28:22 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 62F623A68DE for ; Thu, 22 Oct 2009 21:28:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id AAB6D827D7 for ; Fri, 23 Oct 2009 00:28:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=V+kHTVGji599 NOXj63lispUESf8=; b=xdK/IoUIdjfqTtYcP4nrZap6n0eY9jwOLGKWnTUWoznE yVI1CpaUKuPqRB1qaOaHPjmK7VujZ3gKmo79Qj9Zc9K79oLqdolq0Gb3i88+6rzF CjIwG5g1eJG7GumLoe1jfX0C9sJ0HmtAWp3nJ6kP7Ckbs8FSAMcKa4pRsIQI0Ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Y8dhMR /Mr4pCuJXfS4xIxiB1OwVxcHmp8Hqb+NCdmeRvw7fVr/rITsc5aAJzHmSyklxGVU fx5lT4n2Znup4pHuffly5AWdVYgSJ6hrfn5IpAaSpPhF/H9PKuR+gaGHMNGGwQTR Ahr7iiTBVbVTqrNQ1bLm5AjaxJZm4qvwABmdQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A634B827D6 for ; Fri, 23 Oct 2009 00:28:30 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B6288827D5 for ; Fri, 23 Oct 2009 00:28:29 -0400 (EDT) Message-ID: <4AE1311E.5080508@pobox.com> Date: Thu, 22 Oct 2009 21:29:18 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 84769944-BF8C-11DE-986F-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 04:28:23 -0000 The link appears to go to the correct version of the draft, but the header of each page says it is draft -00 dated June 2008. Overall the draft seems to be good, but one thing I think is missing is for the server to be able to somehow tell the client to switch to a different port for DTLS over UDP (I don't know about other types of transports). The simplest scheme I can envision is that the HelloVerifyRequest and ServerHello messages would be sent from the port the client initially contacted. The ServerHello would contain a DTLS_PortChange extension listing the new port number. The remainder of the handshake and subsequent data transfer would occur on this new port. Comments on the draft: In section 3. Overview of DTLS, it says: 1. TLS's traffic encryption layer does not allow independent decryption of individual records. If record N is not received, then record N+1 cannot be decrypted. I don't believe this is always true -- if a block cipher is used, then since there is an explicit IV given, you can decrypt the record. The MAC, however, will not calculate correctly due to the wrong sequence number, so the missing record will be detected. Stream (and AEAD?) ciphers would fail to decrypt as stated. Near the top of page 9, the abbreviation CSS is used. I think that should have been CCS, but I would suggest spelling out ChangeCipher Spec rather than abbreviating. At the very end of section 4.2.1 (top of page 17) it mentions a HelloVerify message (not HelloVerifyRequest). Should that be a ClientHello message (with cookie)? Typos: - last line of page 3: "they typically requires" strike the s. - section 4.1.1 second line, "that clients" remove "that" - top of page 14 - "forget" should be "forgery" Mike Joseph Salowey (jsalowey) wrote: > This is an announcement for working group last call on DTLS 1.2 (RFC > 4347-bis). The document is available here: > > http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03 > > Please send any comments to the list by October 26, 2009. It is useful > to send an indication to the list if you have read the document and > think it is ready for publication even if you don't have specific > comments. > > Thanks, > > Joe From Pasi.Eronen@nokia.com Fri Oct 23 02:47:02 2009 Return-Path: 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 5D39C3A67EB; Fri, 23 Oct 2009 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 gyRK8RfTSfD5; Fri, 23 Oct 2009 02:47:01 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C6A663A6767; Fri, 23 Oct 2009 02:47:00 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9N9l3FZ007214; Fri, 23 Oct 2009 12:47:08 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 12:46:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 12:46:51 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 23 Oct 2009 11:46:50 +0200 From: To: , Date: Fri, 23 Oct 2009 11:46:49 +0200 Thread-Topic: Join the MashSSL Incubator Group (Call for Participation) Thread-Index: AcpTsEr7eU1574EtTp2SbCUO3PXKMgAFRENQ Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09B0BB76@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2009 09:46:51.0207 (UTC) FILETIME=[BF074D70:01CA53C5] X-Nokia-AV: Clean Subject: [TLS] FW: Join the MashSSL Incubator Group (Call for Participation) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:47:02 -0000 This is probably of interest to TLS and OAUTH WG members... Best regards, Pasi Begin forwarded message: > From: Ian Jacobs > Date: October 22, 2009 5:38:31 PM EDT > To: W3C Members > Subject: Join the MashSSL Incubator Group (Call for Participation) > Archived-At: E56D78D1-6160-4085-89E1-3EC465612C5B@w3.org> > > Dear Advisory Committee Representative, > > This is a Call for Participation in the MashSSL Incubator Group [1], > part of > the Incubator Activity [2]. > > The mission of this group is to create an open security protocol to > solve a fundamental Internet security problem. Specifically, when two > web applications communicate through a potentially untrusted user they > do not have any standard way of mutually authenticating each other and > establishing a trusted channel. The group seeks to create an open, > secure standard standard for solving this problem. > > If your organization wishes to join this group, please first > review the charter: > http://www.w3.org/2005/Incubator/MashSSL/charter > > Then use the following online form to join the group; > the form will also instruct you how to nominate participants: > > http://www.w3.org/2004/01/pp-impl/43924/join > > If you have any questions or need further information, please contact > the Incubator Group Chair, Siddharth Bajaj . > > Thank you, > > Mauro Nunez, Incubator Activity Lead, and > Ian Jacobs, Head of W3C Communications > > [1] http://www.w3.org/2005/Incubator/MashSSL/ > [2] http://www.w3.org/2005/Incubator/ > > -- > Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ > Tel: +1 718 260 9447 From agl@google.com Fri Oct 23 09:21:44 2009 Return-Path: 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 0F5473A67FB for ; Fri, 23 Oct 2009 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Gh4k3SXaozIQ for ; Fri, 23 Oct 2009 09:21:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id DCAF53A67AD for ; Fri, 23 Oct 2009 09:21:42 -0700 (PDT) Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id n9NGLpZ5017757 for ; Fri, 23 Oct 2009 17:21:52 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1256314912; bh=KtIj9Cuhu3YTRMPNwxNafXvBO8s=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=EXJeDtShyNzoB1Uhsuccks2SpaARuuPqH3AoEGDd9g+xrizFDuOu49h5BNKlTW9c9 DFol/eSuqWpYVH+BTu3qA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=vdMXgYQrBomONrX+M3oAtGZwD4Hw7fKsUnTPMdTmQuQsi/tFznTCjRtIaWlGpEMX8 Kjd+4LUFtUKd9YLiQpGaQ== Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by zps36.corp.google.com with ESMTP id n9NGLmmj018083 for ; Fri, 23 Oct 2009 09:21:49 -0700 Received: by pwj10 with SMTP id 10so2220355pwj.26 for ; Fri, 23 Oct 2009 09:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.44.17 with SMTP id w17mr1849335rvj.67.1256314908539; Fri, 23 Oct 2009 09:21:48 -0700 (PDT) Date: Fri, 23 Oct 2009 09:21:48 -0700 Message-ID: From: Adam Langley To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Subject: [TLS] Next protocol negotiation 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:21:44 -0000 We're currently in a blackout period for Internet drafts because of the Hiroshima meeting, but I present the following for your casual consideration. I'll upload it as a true ID once the blackout period ends. http://www.imperialviolet.org/binary/draft-agl-tls-nextprotoneg-00.html Abstract This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation. This allows the application layer to negotiate which protocol should be performed over the secure connection in a manner which avoids additional round trips and which is independent of the application layer protocols. We will probably be starting small scale experiments of this soon, and appreciate any feedback from the WG. Cheers AGL From n.mavrogiannopoulos@gmail.com Fri Oct 23 09:39:55 2009 Return-Path: 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 07F0B3A67F4 for ; Fri, 23 Oct 2009 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5fi7U6IWo8WZ for ; Fri, 23 Oct 2009 09:39:54 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 0351B3A67AD for ; Fri, 23 Oct 2009 09:39:53 -0700 (PDT) Received: by fxm18 with SMTP id 18so10484082fxm.37 for ; Fri, 23 Oct 2009 09:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=x+C9KKTTlpbkoYOdbHLPkhqMOZ1CXH3QvmERyXfP4PI=; b=rB/87CRYhtjcsQtiSB70szYLyDmpXVfIG0jLzh1jjOAwQ5s0QRU6ohGtspcJon1xo4 2vDmwd1g1EpLRUcUHuVvpDNkX5t8L1wzujmpokH/YTTi96L10jYVh2IZQIWhdYHBL/SM K6pKomGQoZ3jVLOY/QK1PlIDthAH0T7d2ErL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=hSyu6ZQ97LDfHoY1mwlQEzer2UhLAYPx+9p0emaZLe95ZvDfnrbGB6gCanaclbJYib /E0TJK25qtcPtc8v4Uc+SHibJhq8VoGgxc+2g6uShFhgcBPkZwTY+6WxihMeIblvePma Dti9Nic2NZ6dbjaKOKXhusnU96rbG3P06kFxU= Received: by 10.204.33.193 with SMTP id i1mr5783742bkd.75.1256316001212; Fri, 23 Oct 2009 09:40:01 -0700 (PDT) Received: from ?10.100.1.196? (adsl18-228.ath.forthnet.gr [77.49.209.228]) by mx.google.com with ESMTPS id h2sm4203016fkh.6.2009.10.23.09.39.58 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Oct 2009 09:40:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4AE1DC5D.1070305@gnutls.org> Date: Fri, 23 Oct 2009 19:39:57 +0300 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael D'Errico References: <4AE0CD8F.6000508@gnutls.org> <4AE0D79A.5060608@pobox.com> In-Reply-To: <4AE0D79A.5060608@pobox.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.2 and CertificateRequest message 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:39:55 -0000 Michael D'Errico wrote: > I remember participating in the discussion that led to this design. I > argued that since we added a signature algorithms extension to allow > negotiation of the client's preferred algorithms, it made the most > sense to make the extension symmetric so the server could notify the > client of its preferred algorithms in its hello message as well. > > There was opposition to my argument, that the list of algorithms belongs > where it is needed, in the certificate request message. The term > "locality of reference" was thrown around as a justification. Not being > an official member of the working group, and since nobody else seemed to > prefer my idea, I forfeited the point. I believe you were correct then and this is really a drawback of TLS 1.2 comparing to TLS 1.x, x<2. My main concern is that it requires totally different handling of handshake hashes, thus increasing code complexity (and memory usage). regards, Nikos From Pasi.Eronen@nokia.com Mon Oct 26 01:11:14 2009 Return-Path: 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 33A9B3A67D4 for ; Mon, 26 Oct 2009 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 tSuYG0R3EZWB for ; Mon, 26 Oct 2009 01:11:13 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 681BE3A6774 for ; Mon, 26 Oct 2009 01:11:12 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9Q8BGQ9004131; Mon, 26 Oct 2009 10:11:21 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:02 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 26 Oct 2009 09:11:02 +0100 From: To: , Date: Mon, 26 Oct 2009 09:11:00 +0100 Thread-Topic: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt Thread-Index: AcpGibwe1Ckmr7tbRC+TSHgMIBNTmAPh1z4g Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> References: <87bpkkd4tv.fsf@mocca.josefsson.org> In-Reply-To: <87bpkkd4tv.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 08:11:02.0312 (UTC) FILETIME=[DBA8CA80:01CA5613] X-Nokia-AV: Clean Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 08:11:14 -0000 I agree with Simon here that in the minimum, the extension should have a "type" field to ensure that if the recipient parses the information, it's using the same format as the sender. (Some other protocols use the Enterprise Number registry for "vendor specific" payloads, instead of creating a new FCFS registry.) However, I'd like to re-iterate my earlier concern about the original draft-rescorla-tls-opaque-prf-input draft: this defines a basically general-purpose extension mechanism to TLS. We already have a well-defined extension mechanism for TLS (TLS extensions), which would allow people to do exactly the sorts of things envisioned in Section 1.1. Its only "drawback" is that it requires going through the IETF process to obtain the IANA allocation, and thus publicly documenting what you're doing. The main "feature" of this draft seems to be allowing "interesting" extensions without going through the IETF process, or even publicly documenting what you're doing. I can certainly see that folks at NSA might be interesting in doing exactly such things, and they could have (in their opinion) good reasons. And some other IETF protocols do indeed allow pretty much unlimited vendor extensibility (by e.g. allowing "Vendor Specific" payloads anywhere). But if the WG decides that adding such extensibility to TLS is a good idea, I would predict that many folks will use this mechanism to define new TLS extension so that they can avoid the somewhat time-consuming process of consensus-building and standardization. Many of the existing TLS extension could have been done by specifying suitably "structured" PRF inputs: client/server_authz, user_mapping, trusted_ca_keys, server_name, status_request, etc. (In these cases, it doesn't really matter if the input gets fed to PRF; the interesting part is adding a free-form payload to ClientHello/ServerHello without requiring an extension number from IANA.) I know sevaral people have occasionally been frustrated that it's very difficult to extend TLS (since the requirements for IANA allocation are quite strict). Personally, I view this as a feature, and I think it has contributed to general interoperability of TLS/SSL -- it's generally viewed as a protocol that "just works" (compared to some other protocols which have large numbers of optional extensions, and it's very difficult to get implementations from different vendors to interoperate). =20 Best regards, Pasi=20 (not wearing any hats) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Simon Josefsson > Sent: 06 October, 2009 16:34 > To: Paul Hoffman > Cc: tls@ietf.org > Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input- > 00.txt >=20 > Paul Hoffman writes: >=20 > >>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf- > input-00.txt > > > > Greetings again. We would like to hear input on this draft from the > > TLS community. The basic idea is an extension that would allow the > two > > parties to give additional information that is directly mixed into > the > > master secret through the PRF. >=20 > The document seems fine to me. >=20 > As far as I can tell, any implementation (including mine) of > draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with > draft-solinas-tls-additional-prf-input-00.txt, and that is good. >=20 > The two last examples in section 1.1 doesn't appear fully baked to me. > Quoting: >=20 > TLS servers may arrange for their clients to provide authentication > data early in the protocol (such as an HMAC value computed over a > fresh random value using a shared secret as the key) in order to > authenticate the client as a member of a private network or as an > additional means of mitigating the impact of a denial-of-service > attack. >=20 > Implementors may want to provide a mechanism for relaying identity > and > version information similar to the "Vendor ID Payload" used in ISAKMP > [RFC2408]. >=20 > 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: >=20 > enum { > entropy(0), (65535) > } AdditionalPRFInputType; >=20 > struct { > AdditionalPRFInputType type; > opaque value<0..2^16-1>; > } AdditionalPRFInput; >=20 > AdditionalPRFInput prfinputs<2..2^16-2>; >=20 > The AdditionalPRFInputType could be a FCFS registry. The intention > with > the "entropy" field is that it should contain random data with no > intended meaning, which appears to be the typical use-case. Other > types > can be allocated to signal the two use-cases in the example if/when > needed. >=20 > Alternatively, and considering the complexities in my proposed change, > I > would suggest that you remove other use cases than the one to provide > additional entropy to the MS key computation and say that there is only > one intended use-case for this extension. If other use-cases of the > extension are important, they can be described in separate documents. >=20 > Thanks, > /Simon > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mike-list@pobox.com Mon Oct 26 08:21:30 2009 Return-Path: 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 2C1F63A697E for ; Mon, 26 Oct 2009 08:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 4VdcKNSHgRnH for ; Mon, 26 Oct 2009 08:21:28 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id A969B3A6858 for ; Mon, 26 Oct 2009 08:21:28 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6A283685D6 for ; Mon, 26 Oct 2009 11:21:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=YwrZIE1SLdez UsnkBkTJnimgTs4=; b=efiEFMClRY5sZHObhaE1x89WWhq91mnL4M6HGWTMS5yM r7vwxgsgZzVXpao+hULpXFKTEb5SKLFPycmBVsIdny1pWQX2GPVEPgA7OD2i7xDY SZ5ZNWauZBTzC2VKhIaqjv1iIkgqfVx8qIthGb88P89DFKVttYInFN46mQMAkHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=uRc0eI TNNXMA04OlFneheNCeuWoDxmfFbq7GtUZdXzCkA6KyBrWEnjrCL1oeTnD2K3wt7P y6hkYCJ2eEn70VgDZ/xsJcxc5SJQHfI5qwBvi7eOe/H7PRW3ugKJiEgLiuLOnCoD GIXNTR5lExOlMZPUJVvrncmD2NdZe5IENUH5I= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 68777685D5 for ; Mon, 26 Oct 2009 11:21:41 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 846BB685D4 for ; Mon, 26 Oct 2009 11:21:40 -0400 (EDT) Message-ID: <4AE5BEC8.40209@pobox.com> Date: Mon, 26 Oct 2009 08:22:48 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <87bpkkd4tv.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4337360A-C243-11DE-91D9-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:21:30 -0000 I understand your concern, but the fact is that there is already an unofficial extension mechanism available. Simply create a private cipher suite (first byte 0xFF) and then define your own formats for ServerKeyExchange and ClientKeyExchange handshake messages to go along with it. This won't work if the client needs to send info to the server first, though. Mike Pasi.Eronen@nokia.com wrote: > I agree with Simon here that in the minimum, the extension should have > a "type" field to ensure that if the recipient parses the information, > it's using the same format as the sender. (Some other protocols use > the Enterprise Number registry for "vendor specific" payloads, instead > of creating a new FCFS registry.) > > However, I'd like to re-iterate my earlier concern about the original > draft-rescorla-tls-opaque-prf-input draft: this defines a basically > general-purpose extension mechanism to TLS. > > We already have a well-defined extension mechanism for TLS (TLS > extensions), which would allow people to do exactly the sorts of > things envisioned in Section 1.1. Its only "drawback" is that it > requires going through the IETF process to obtain the IANA allocation, > and thus publicly documenting what you're doing. > > The main "feature" of this draft seems to be allowing "interesting" > extensions without going through the IETF process, or even publicly > documenting what you're doing. I can certainly see that folks at NSA > might be interesting in doing exactly such things, and they could have > (in their opinion) good reasons. And some other IETF protocols do > indeed allow pretty much unlimited vendor extensibility (by e.g. > allowing "Vendor Specific" payloads anywhere). > > But if the WG decides that adding such extensibility to TLS is a good > idea, I would predict that many folks will use this mechanism to > define new TLS extension so that they can avoid the somewhat > time-consuming process of consensus-building and standardization. > > Many of the existing TLS extension could have been done by specifying > suitably "structured" PRF inputs: client/server_authz, user_mapping, > trusted_ca_keys, server_name, status_request, etc. (In these cases, > it doesn't really matter if the input gets fed to PRF; the interesting > part is adding a free-form payload to ClientHello/ServerHello without > requiring an extension number from IANA.) > > I know sevaral people have occasionally been frustrated that it's very > difficult to extend TLS (since the requirements for IANA allocation > are quite strict). Personally, I view this as a feature, and I think > it has contributed to general interoperability of TLS/SSL -- it's > generally viewed as a protocol that "just works" (compared to some > other protocols which have large numbers of optional extensions, and > it's very difficult to get implementations from different vendors > to interoperate). > > Best regards, > Pasi > (not wearing any hats) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> ext Simon Josefsson >> Sent: 06 October, 2009 16:34 >> To: Paul Hoffman >> Cc: tls@ietf.org >> Subject: Re: [TLS] New draft: draft-solinas-tls-additional-prf-input- >> 00.txt >> >> Paul Hoffman writes: >> >>>> http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf- >> input-00.txt >>> Greetings again. We would like to hear input on this draft from the >>> TLS community. The basic idea is an extension that would allow the >> two >>> parties to give additional information that is directly mixed into >> the >>> master secret through the PRF. >> The document seems fine to me. >> >> As far as I can tell, any implementation (including mine) of >> draft-rescorla-tls-opaque-prf-input-00.txt would be compatible with >> draft-solinas-tls-additional-prf-input-00.txt, and that is good. >> >> The two last examples in section 1.1 doesn't appear fully baked to me. >> Quoting: >> >> TLS servers may arrange for their clients to provide authentication >> data early in the protocol (such as an HMAC value computed over a >> fresh random value using a shared secret as the key) in order to >> authenticate the client as a member of a private network or as an >> additional means of mitigating the impact of a denial-of-service >> attack. >> >> Implementors may want to provide a mechanism for relaying identity >> and >> version information similar to the "Vendor ID Payload" used in ISAKMP >> [RFC2408]. >> >> 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: >> >> enum { >> entropy(0), (65535) >> } AdditionalPRFInputType; >> >> struct { >> AdditionalPRFInputType type; >> opaque value<0..2^16-1>; >> } AdditionalPRFInput; >> >> AdditionalPRFInput prfinputs<2..2^16-2>; >> >> The AdditionalPRFInputType could be a FCFS registry. The intention >> with >> the "entropy" field is that it should contain random data with no >> intended meaning, which appears to be the typical use-case. Other >> types >> can be allocated to signal the two use-cases in the example if/when >> needed. >> >> Alternatively, and considering the complexities in my proposed change, >> I >> would suggest that you remove other use cases than the one to provide >> additional entropy to the MS key computation and say that there is only >> one intended use-case for this extension. If other use-cases of the >> extension are important, they can be described in separate documents. >> >> Thanks, >> /Simon >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From root@core3.amsl.com Mon Oct 26 10:30:03 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 135033A6A79; Mon, 26 Oct 2009 10:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026173003.135033A6A79@core3.amsl.com> Date: Mon, 26 Oct 2009 10:30:02 -0700 (PDT) Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4366-bis-06.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Extensions: Extension Definitions Author(s) : D. Eastlake 3rd Filename : draft-ietf-tls-rfc4366-bis-06.txt Pages : 29 Date : 2009-10-26 This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-rfc4366-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26102816.I-D@ietf.org> --NextPart-- From housley@vigilsec.com Mon Oct 26 11:41:35 2009 Return-Path: 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 E36F628C21C for ; Mon, 26 Oct 2009 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 PbKYCIlm8Nit for ; Mon, 26 Oct 2009 11:41:33 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 94AA028C203 for ; Mon, 26 Oct 2009 11:41:33 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id DE8A09A4738; Mon, 26 Oct 2009 14:42:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 4Id9r2T3g82c; Mon, 26 Oct 2009 14:41:46 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 546069A472C; Mon, 26 Oct 2009 14:42:10 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 14:41:43 -0400 To: Pasi.Eronen@nokia.com From: Russ Housley In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mg dnok.nokia.com> References: <87bpkkd4tv.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091026184210.546069A472C@odin.smetech.net> Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:41:35 -0000 Pasi: >I'd like to re-iterate my earlier concern about the original >draft-rescorla-tls-opaque-prf-input draft: this defines a basically >general-purpose extension mechanism to TLS. > >We already have a well-defined extension mechanism for TLS (TLS >extensions), which would allow people to do exactly the sorts of >things envisioned in Section 1.1. Its only "drawback" is that it >requires going through the IETF process to obtain the IANA allocation, >and thus publicly documenting what you're doing. I do not think this is a fair characterization. TLS extensions cannot provide additional PRF inputs. To my eyes, that is the fundamental difference here. Russ (also with no hats on) From paul.hoffman@vpnc.org Mon Oct 26 12:01:33 2009 Return-Path: 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 35CCC28C31C for ; Mon, 26 Oct 2009 12:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.419, 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 SLvfpW46R3md for ; Mon, 26 Oct 2009 12:01:32 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B7C6628C31A for ; Mon, 26 Oct 2009 11:55:39 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9QItpZm026169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 11:55:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> References: <87bpkkd4tv.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 26 Oct 2009 11:55:49 -0700 To: , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:01:33 -0000 Timing is everything. A few hours before Pasi sent this, I turned in the -01 which addressed Simon's concerns and started to address Pasi's. At 9:11 AM +0100 10/26/09, wrote: >I agree with Simon here that in the minimum, the extension should have >a "type" field to ensure that if the recipient parses the information, >it's using the same format as the sender. (Some other protocols use >the Enterprise Number registry for "vendor specific" payloads, instead >of creating a new FCFS registry.) For the -01, I chose a FCFS registry that requires an RFC. Requiring an RFC will increase interop. >However, I'd like to re-iterate my earlier concern about the original >draft-rescorla-tls-opaque-prf-input draft: this defines a basically >general-purpose extension mechanism to TLS. > >We already have a well-defined extension mechanism for TLS (TLS >extensions), which would allow people to do exactly the sorts of >things envisioned in Section 1.1. Its only "drawback" is that it >requires going through the IETF process to obtain the IANA allocation, >and thus publicly documenting what you're doing. That is not the only drawback. The whole purpose of this document is to put additional material in the PRF; that is not covered in the TLS Extensions document, nor should it be. >The main "feature" of this draft seems to be allowing "interesting" >extensions without going through the IETF process, or even publicly >documenting what you're doing. No, the main feature is to allow light-weight extensions (that is, ones that just contain content, not directives) to have input to the PRF. >I can certainly see that folks at NSA >might be interesting in doing exactly such things, and they could have >(in their opinion) good reasons. And some other IETF protocols do >indeed allow pretty much unlimited vendor extensibility (by e.g. >allowing "Vendor Specific" payloads anywhere). This is confusing. Are you saying you *want* the equivalent of IKE's Vendor ID payload as a TLS extension? If so, someone could write such an extension; I see no reason why that material would need to be mixed into the PRF using the mechanism I am proposing here. If you don't want a Vendor ID equivalent, that's fine, and I agree, but I don't understand why you brought it up this way. >But if the WG decides that adding such extensibility to TLS is a good >idea, I would predict that many folks will use this mechanism to >define new TLS extension so that they can avoid the somewhat >time-consuming process of consensus-building and standardization. Note that the registry in -01 is for "any RFC", not "standards track RFC". I'm happy to make it "standards track RFC required" and have it be parallel to the current TLS extensions requirements. >Many of the existing TLS extension could have been done by specifying >suitably "structured" PRF inputs: client/server_authz, user_mapping, >trusted_ca_keys, server_name, status_request, etc. (In these cases, >it doesn't really matter if the input gets fed to PRF; the interesting >part is adding a free-form payload to ClientHello/ServerHello without >requiring an extension number from IANA.) It would be quite confusing to modify the current TLS extensions mechanism to have some extensions mix content into the PRF but some not. This is why I am proposing a different mechanism altogether. If you want the two mechanisms to have the same requirements, that's fine. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@sun.com Mon Oct 26 12:04:37 2009 Return-Path: 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 ABF8B28C34F for ; Mon, 26 Oct 2009 12:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.135, 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 TtlLihHommOd for ; Mon, 26 Oct 2009 12:04:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 997FF28C361 for ; Mon, 26 Oct 2009 12:02:57 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9QJ3Arx004522 for ; Mon, 26 Oct 2009 19:03:10 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9QJ3AUa002202 for ; Mon, 26 Oct 2009 13:03:10 -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 n9QIpiaR009043; Mon, 26 Oct 2009 13:51:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9QIpibr009042; Mon, 26 Oct 2009 13:51:44 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 26 Oct 2009 13:51:43 -0500 From: Nicolas Williams To: Russ Housley Message-ID: <20091026185143.GR892@Sun.COM> References: <87bpkkd4tv.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> <20091026184210.546069A472C@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091026184210.546069A472C@odin.smetech.net> User-Agent: Mutt/1.5.7i Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:04:37 -0000 On Mon, Oct 26, 2009 at 02:41:43PM -0400, Russ Housley wrote: > Pasi: > >I'd like to re-iterate my earlier concern about the original > >draft-rescorla-tls-opaque-prf-input draft: this defines a basically > >general-purpose extension mechanism to TLS. > > > >We already have a well-defined extension mechanism for TLS (TLS > >extensions), which would allow people to do exactly the sorts of > >things envisioned in Section 1.1. Its only "drawback" is that it > >requires going through the IETF process to obtain the IANA allocation, > >and thus publicly documenting what you're doing. > > I do not think this is a fair characterization. TLS extensions > cannot provide additional PRF inputs. To my eyes, that is the > fundamental difference here. Well, one could imagine a plethora of extensions each of which says that you must modify the PRF computation in such and such ways. But that gets ugly very quickly. IMO we need this draft, and IMO it's properly seen as the TLS equivalent of the GSS-API channel bindings input to GSS_Init/Accept_sec_context(): An additional PRF input is an octet string that is checked for equality in an integrity protected manner that adds no round-trips nor half round-trips. If the equality comparison fails then authentication fails. Whether that facility is used for bonafide channel binding or, more likely, to provide integrity protection for application data sent out of band from TLS, is not important. What's important is: a) that those semantics are desirable, b) that client and server applications can agree on what they'll use as additional PRF inputs (e.g., it may be desirable to support multiple additional inputs, each tagged with a type specifier). Nico -- From jsalowey@cisco.com Mon Oct 26 20:59:54 2009 Return-Path: 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 7D99C3A6821 for ; Mon, 26 Oct 2009 20:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 57rsaio+ZG8H for ; Mon, 26 Oct 2009 20:59:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D0A013A680E for ; Mon, 26 Oct 2009 20:59:53 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFoN5kqrR7Ht/2dsb2JhbADARZgAhD8E X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="198983990" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2009 04:00:07 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R407FA009942 for ; Tue, 27 Oct 2009 04:00:07 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:00:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 21:00:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-76 TLS draft agenda Thread-Index: AcpWufhTdtIZh1E+TRmyTm8RP0lKeA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 27 Oct 2009 04:00:07.0714 (UTC) FILETIME=[F8D53020:01CA56B9] Subject: [TLS] IETF-76 TLS draft agenda 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 03:59:54 -0000 The IETF-76 draft agenda for TLS can be found here: http://www.ietf.org/proceedings/09nov/agenda/tls.txt Please let me know if you have additions or corrections. Thanks, Joe From Michael.Tuexen@lurchi.franken.de Tue Oct 27 00:25:33 2009 Return-Path: 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 3ACDC3A6806 for ; Tue, 27 Oct 2009 00:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] 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 xw+bMOu8d1H6 for ; Tue, 27 Oct 2009 00:25:32 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4326E3A67E5 for ; Tue, 27 Oct 2009 00:25:31 -0700 (PDT) Received: from [IPv6:2002:508f:ed2c::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:ed2c:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id 1807A1C0B4612; Tue, 27 Oct 2009 08:25:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Tue, 27 Oct 2009 08:25:42 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.1076) Cc: tls@ietf.org Subject: Re: [TLS] IETF-76 TLS draft agenda 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 07:25:33 -0000 Hi Joe, unfortunately neither Robin nor myself will attend IETF-76. So we can not present draft-seggelmann-tls-dtls-heartbeat-01. However, we are still interested in progressing the ID and most likely I'll attend IETF-77. Best regards Michael On Oct 27, 2009, at 5:00 AM, Joseph Salowey (jsalowey) wrote: > The IETF-76 draft agenda for TLS can be found here: > > http://www.ietf.org/proceedings/09nov/agenda/tls.txt > > Please let me know if you have additions or corrections. > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Pasi.Eronen@nokia.com Tue Oct 27 05:44:46 2009 Return-Path: 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 4CA403A67AB for ; Tue, 27 Oct 2009 05:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 qHn3xc1DOKyp for ; Tue, 27 Oct 2009 05:44:45 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AD23F28C1E1 for ; Tue, 27 Oct 2009 05:44:26 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9RCiOPW021053; Tue, 27 Oct 2009 07:44:40 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:44:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:44:18 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 27 Oct 2009 13:44:16 +0100 From: To: Date: Tue, 27 Oct 2009 13:44:14 +0100 Thread-Topic: [TLS] New draft: draft-solinas-tls-additional-prf-input-00.txt Thread-Index: AcpWa/ux+73eWKOuQUqSCFzmJcxOXQAlef3A Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F5DFDBA@NOK-EUMSG-01.mgdnok.nokia.com> References: <87bpkkd4tv.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F2F0022@NOK-EUMSG-01.mgdnok.nokia.com> <20091026184210.546069A472C@odin.smetech.net> In-Reply-To: <20091026184210.546069A472C@odin.smetech.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2009 12:44:18.0623 (UTC) FILETIME=[33090CF0:01CA5703] X-Nokia-AV: Clean Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 12:44:46 -0000 Russ Housley wrote: > >I'd like to re-iterate my earlier concern about the original > >draft-rescorla-tls-opaque-prf-input draft: this defines a basically > >general-purpose extension mechanism to TLS. > > > >We already have a well-defined extension mechanism for TLS (TLS > >extensions), which would allow people to do exactly the sorts of > >things envisioned in Section 1.1. Its only "drawback" is that it > >requires going through the IETF process to obtain the IANA allocation, > >and thus publicly documenting what you're doing. >=20 > I do not think this is a fair characterization. TLS extensions > cannot provide additional PRF inputs. To my eyes, that is the > fundamental difference here. Well, this very document (a proposal for a TLS extension) is a=20 proof that TLS extensions can indeed change what goes into the PRF! So there's no a priori reason why other TLS extensions cannot do that, too. New TLS cipher suites routinely change what goes into=20 the PRF by defining suitable pre_master_secret formats (e.g. RFC 4279). =20 And we've had a proposal for a TLS extension that changed the TLS PRF=20 to some other PRF.=20 Best regards, Pasi (not wearing any hats) From nelson@bolyard.me Tue Oct 27 20:37:30 2009 Return-Path: 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 9400C28C151 for ; Tue, 27 Oct 2009 20:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 eNYRmC+iHtwE for ; Tue, 27 Oct 2009 20:37:29 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 77A553A676A for ; Tue, 27 Oct 2009 20:37:29 -0700 (PDT) Received: (qmail 26817 invoked from network); 28 Oct 2009 03:37:38 -0000 Received: from unknown (67.188.69.99) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 28 Oct 2009 03:37:38 -0000 Message-ID: <4AE7BC74.9010806@bolyard.me> Date: Tue, 27 Oct 2009 20:37:24 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexei Volkov Subject: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 03:37:30 -0000 A few years ago, I implemented the SNI extension in a client-only TLS library and it was really simple because I only ever sent one host name to the server. Now I'm implementing the server side of SNI and I realize that the RFC appears to allow clients to do much more complex things than my client ever did. So, I have some questions seeking clarification about the definition of SNI. I hope someone here can help me by answering some of these questions. Q1) A client hello's SNI extension is defined such that it may contain multiple names. Perhaps the intent was to allow the same server to be named in multiple different name spaces (DNS and others), but I saw nothing in RFC 4366 that precludes the client from naming multiple different hosts in a single ServerNameList. If a client names multiple host names in a single client hello SNI extension (let's call them A.foo.com, B.foo.com and C.foo.com) how does the client learn which one of those has been chosen by the server? RFC 4366 requires the "extension_data" field of the SNI extension in the server hello to be empty. The server may respond with a "wildcard" certificate ("*.foo.com"), or with a certificate with multiple Subject Alternative Names that include more than one of the names given by the client. In that case, how does the client know which FQDN is the one that the physical server has chosen/identified? I can think of lots of possible answers here, including a) It is an error to include multiple names in the same name space, e.g. multiple DNS names. (but the RFC doesn't say that.) b) If multiple names are included, they must be logically synonymous, all alternative names for the same host. (What if they're not?) Q2) if multiple non-synonymous names are included, is the server free to pick any one that it wants? Q3) Consider the "renegotiation" case, where a client and server negotiate an initial SSL handshake ("in the clear") and then negotiate a second handshake over the encrypted channel established by the first handshake. Are there any special requirements or prohibitions on the use and contents of the client hello's SNI extension in the renegotiation case? Q3a) Is SNI permitted in that case? Q3b) Is it required to match the SNI of the original handshake, if any? Q3c) If it contains multiple non-synonymous host names, is the server allowed to choose a different one than the one chosen in the first handshake? The next questions have to do with the "resumption" or "restart" of a TLS session that has been previously established using an SNI extension that named one or more virtual hosts in a connection to a physical server on an IP address and port. Q4) In that context, is the scope of a TLS session ID that of the physical server, or that of a virtual server? When attempting to restart a TLS session on a new connection, does the TLS session ID in the client hello uniquely identify the virtual host and its session to the physical server, even in the absence of an SNI extension? Or is it possible that each of the virtual servers within the physical host may have used that same session ID, in which case it would be necessary for the client to supply the virtual host's FQDN in an SNI extension to uniquely identify the session? Q5) When an SNI extension was used to establish a TLS session, it is required that an SNI extension bearing the same host name be used in the client hello that attempts to "restart" or "resume" the session on a new connection? (Obviously Q3, Q4 and Q5 overlap.) I eagerly await your answers and comments. /Nelson Bolyard From larry.zhu@microsoft.com Wed Oct 28 03:17:49 2009 Return-Path: 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 E97B83A679C; Wed, 28 Oct 2009 03:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2IKN+Ft8fX88; Wed, 28 Oct 2009 03:17:49 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1A5003A67D8; Wed, 28 Oct 2009 03:17:49 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 03:18:03 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 03:18:03 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 28 Oct 2009 03:18:04 -0700 From: Larry Zhu To: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Thread-Topic: lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV7fuvme20kL+T0ihZxz3sI4KRA== Date: Wed, 28 Oct 2009 10:18:04 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:17:50 -0000 There is a design issue in tls-unique. For vendors who implement TLS in a s= eparate library, the TLS library does not by itself control the transport t= herefore it would not know if there is a new connection, so that the curren= t specification is not implementable for these vendors. It would be much easier to say the following instead: The client's TLS Finished message from the first handshake of the session (= note: TLS session, not connection, so that the channel binding is specific = to each TLS session regardless of whether session resumption is used). And the updated text does reflect what has been deployed for tls-unique. =20 I would like to raise a red flag now. Needless to say that I will start a d= iscussion with the responsible AD and the rest of the editors of this ID to= fix this issue, and do so based on consensus.=20 Pasi, please consider this issue blocking for now. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The I= ESG Sent: Monday, October 05, 2009 9:27 AM To: IETF-Announce Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindin= gs for TLS) to Proposed Standard The IESG has received a request from an individual submitter to consider=20 the following document: - 'Channel Bindings for TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-02. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.tx= t IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D15087&rfc_flag=3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Pasi.Eronen@nokia.com Wed Oct 28 06:27:05 2009 Return-Path: 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 CEEAA28C18C; Wed, 28 Oct 2009 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 lhryLCXE0z5U; Wed, 28 Oct 2009 06:27:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 83EB328C171; Wed, 28 Oct 2009 06:27:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9SDQ5HJ027250; Wed, 28 Oct 2009 15:27:16 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:27:11 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:27:07 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 28 Oct 2009 14:27:07 +0100 From: To: , , , Date: Wed, 28 Oct 2009 14:27:04 +0100 Thread-Topic: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV7fuvme20kL+T0ihZxz3sI4KRJEa9Icg Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2009 13:27:07.0071 (UTC) FILETIME=[585CDCF0:01CA57D2] X-Nokia-AV: Clean Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:27:05 -0000 Larry, Could you elaborate a bit about your first paragraph? =20 Certainly the TLS library knows when there's a new connection, because it receives (on the server) or sends (on the client) an unencrypted=20 ClientHello message? Best regards, Pasi > -----Original Message----- > From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of > ext Larry Zhu > Sent: 28 October, 2009 12:18 > To: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: Re: [sasl] lasgt call comments (st Call: draft-altman-tls- > channel-bindings (Channel Bindings for TLS) to Proposed Standard) >=20 >=20 > There is a design issue in tls-unique. For vendors who implement TLS in > a separate library, the TLS library does not by itself control the > transport therefore it would not know if there is a new connection, so > that the current specification is not implementable for these vendors. >=20 > It would be much easier to say the following instead: >=20 > The client's TLS Finished message from the first handshake of the > session (note: TLS session, not connection, so that the channel binding > is specific to each TLS session regardless of whether session > resumption is used). >=20 > And the updated text does reflect what has been deployed for tls- > unique. >=20 > I would like to raise a red flag now. Needless to say that I will start > a discussion with the responsible AD and the rest of the editors of > this ID to fix this issue, and do so based on consensus. >=20 > Pasi, please consider this issue blocking for now. >=20 > Thanks, >=20 > --Larry >=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel > Bindings for TLS) to Proposed Standard >=20 > The IESG has received a request from an individual submitter to > consider > the following document: >=20 > - 'Channel Bindings for TLS ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings- > 07.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag > =3D15087&rfc_flag=3D0 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl From simon@josefsson.org Wed Oct 28 07:11:18 2009 Return-Path: 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 D8E1E28C1B0; Wed, 28 Oct 2009 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] 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 TZl2EdaCDI2z; Wed, 28 Oct 2009 07:11:17 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6598028C187; Wed, 28 Oct 2009 07:11:16 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SEBRaQ017498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 15:11:29 +0100 From: Simon Josefsson To: Larry Zhu References: <20091005162704.8C1B43A6873@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091028:larry.zhu@microsoft.com::EI86AA0//9OMStfJ:369+ X-Hashcash: 1:22:091028:sasl@ietf.org::xFFGQYY2sXIzmc8Z:BtXJ X-Hashcash: 1:22:091028:channel-binding@ietf.org::7scYWHr9BwUTqkD3:Ajbd X-Hashcash: 1:22:091028:tls@ietf.org::dREygPsbHj7GTjNV:xGjQ Date: Wed, 28 Oct 2009 15:11:28 +0100 In-Reply-To: (Larry Zhu's message of "Wed, 28 Oct 2009 10:18:04 +0000") Message-ID: <87ocnrpq0f.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:11:19 -0000 I agree with Larry that the current definition of tls-unique is impossible to implement in TLS libraries in the way you'd typically want, i.e., a tls_get_tls_unique_cb() function. However, there IS a way that TLS libraries can support the current approach: add a callback interface to provide applications with the TLS Finished message, and let the application handle the complexities regarding connections vs session. That is what I decided to do in GnuTLS, a callback like this: typedef void (*gnutls_finished_callback_func) (gnutls_session_t session, const void *finished, size_t len); void gnutls_session_set_finished_function (gnutls_session_t session, gnutls_finished_callback_func func); Generally, I'm not happy with draft-altman-tls-channel-bindings so if this is an opportunity to consider alternatives I want to remind you of this work: http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt It makes sure to bind the channel binding uniquely to BOTH the current connection and the current session. The draft-altman-tls-channel-bindings-07 document only binds to the current TLS connection. So from this perspective, my work has the same issue, but it is different in other aspects. /Simon Larry Zhu writes: > There is a design issue in tls-unique. For vendors who implement TLS in a separate library, the TLS library does not by itself control the transport therefore it would not know if there is a new connection, so that the current specification is not implementable for these vendors. > > It would be much easier to say the following instead: > > The client's TLS Finished message from the first handshake of the session (note: TLS session, not connection, so that the channel binding is specific to each TLS session regardless of whether session resumption is used). > > And the updated text does reflect what has been deployed for tls-unique. > > I would like to raise a red flag now. Needless to say that I will start a discussion with the responsible AD and the rest of the editors of this ID to fix this issue, and do so based on consensus. > > Pasi, please consider this issue blocking for now. > > Thanks, > > --Larry > > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Channel Bindings for TLS ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15087&rfc_flag=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Wed Oct 28 07:23:59 2009 Return-Path: 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 C266F3A688A; Wed, 28 Oct 2009 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599] 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 VZRpSDlW+eE5; Wed, 28 Oct 2009 07:23:59 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8715B3A6802; Wed, 28 Oct 2009 07:23:58 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SEO9A5017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 15:24:11 +0100 From: Simon Josefsson To: Larry Zhu References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091028:larry.zhu@microsoft.com::qCr4riIOKTCzZhd5:2Nly X-Hashcash: 1:22:091028:sasl@ietf.org::/qW9gdiPsqOxoR6Q:6gs2 X-Hashcash: 1:22:091028:tls@ietf.org::mZpenux+wCdG4ep7:8Ngg X-Hashcash: 1:22:091028:channel-binding@ietf.org::pddBusMwiZxZOSpQ:FPqa Date: Wed, 28 Oct 2009 15:24:09 +0100 In-Reply-To: <87ocnrpq0f.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 28 Oct 2009 15:11:28 +0100") Message-ID: <87hbtjppfa.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:23:59 -0000 Simon Josefsson writes: > http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt > > It makes sure to bind the channel binding uniquely to BOTH the current > connection and the current session. The > draft-altman-tls-channel-bindings-07 document only binds to the current > TLS connection. So from this perspective, my work has the same issue, > but it is different in other aspects. This reminded me of an earlier observation, and it might be relevant to re-iterate it here. Consider this: Day 1: 1. Client establish TLS anon-anon to server. 2. User authenticates using SCRAM with channel binding to the TLS channel 3. User/client disconnects Day 2: 4. Client resumes the TLS anon-anon connection 5. Client rehandshake with X.509 client + server authentication 6. User authenticates using SCRAM with channel binding to the TLS channel 7. User/client disconnects Day 3: 7. Client resumes the TLS session 8. Client rehandshake it as anon-anon 9. User authenticates using SCRAM with channel binding to the TLS channel 10. User/client disconnects With draft-altman-tls-channel-bindings-07, the channel binding data used in all three SCRAM authentications is the same bit sequence. That means there is only an indirect cryptographic binding between the SCRAM user authentication and the X.509 client authentication. /Simon From Nicolas.Williams@sun.com Wed Oct 28 09:11:28 2009 Return-Path: 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 28BD83A6858; Wed, 28 Oct 2009 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.061, 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 eZUegWPx01qm; Wed, 28 Oct 2009 09:11:27 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 5B24D3A6847; Wed, 28 Oct 2009 09:11:27 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9SGBe3t009036; Wed, 28 Oct 2009 16:11:40 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 n9SGBeuK042429; Wed, 28 Oct 2009 10:11:40 -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 n9SG0EOb002442; Wed, 28 Oct 2009 11:00:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SG0DF4002441; Wed, 28 Oct 2009 11:00:13 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 11:00:13 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028160013.GL1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:11:28 -0000 On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote: > There is a design issue in tls-unique. For vendors who implement TLS > in a separate library, the TLS library does not by itself control the > transport therefore it would not know if there is a new connection, so > that the current specification is not implementable for these vendors. > > It would be much easier to say the following instead: > > The client's TLS Finished message from the first handshake of the > session (note: TLS session, not connection, so that the channel > binding is specific to each TLS session regardless of whether session > resumption is used). > > And the updated text does reflect what has been deployed for > tls-unique. > > I would like to raise a red flag now. Needless to say that I will > start a discussion with the responsible AD and the rest of the editors > of this ID to fix this issue, and do so based on consensus. > > Pasi, please consider this issue blocking for now. Larry, It's hard to parse your message because the words "connection" and "transport" have multiple possible meanings in this context. In any case we've discussed this before, and the _current_ text is what we reached consensus on earlier. I believe the current text says what I think you meant to say, in your e-mail. Nico -- From Nicolas.Williams@sun.com Wed Oct 28 09:44:48 2009 Return-Path: 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 4E3663A68AC; Wed, 28 Oct 2009 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.059, 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 DAVGvXcO6lh9; Wed, 28 Oct 2009 09:44:47 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E9B1E28C205; Wed, 28 Oct 2009 09:44:34 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SGin5V013332; Wed, 28 Oct 2009 16:44:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SGinsL050176; Wed, 28 Oct 2009 10:44:49 -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 n9SGXNJL002486; Wed, 28 Oct 2009 11:33:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SGXN8L002485; Wed, 28 Oct 2009 11:33:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 11:33:23 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028163322.GO1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091028160013.GL1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091028160013.GL1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:44:48 -0000 On Wed, Oct 28, 2009 at 11:00:13AM -0500, Nicolas Williams wrote: > On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote: > > There is a design issue in tls-unique. For vendors who implement TLS > > in a separate library, the TLS library does not by itself control the > > transport therefore it would not know if there is a new connection, so > > that the current specification is not implementable for these vendors. > > > > It would be much easier to say the following instead: > > > > The client's TLS Finished message from the first handshake of the > > session (note: TLS session, not connection, so that the channel > > binding is specific to each TLS session regardless of whether session > > resumption is used). I spoke to Jeff and I think I understand your issue, and I agree that we never meant for that interpretation. Proposed new text is below, but first... What the text says now: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). I think we meant to say is that if you're a server, and you see a ClientHello, and you do a handshake and then receive a client Finished message, and then return a handle to the application for the resulting TLS whatever-you-call-it, then _that_ Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). Similarly, if you're a client and send a ClientHello and so on and so forth and then return a handle to the application for the resulting TLS whatever-you-call-it, then the first Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). The reason we used the word "connection" in the description was to avoid the possibility that in a session resumption someone might interpret tls-unique to be the client Finished message of the original connection that established the session resumption state. Changing the text to say "session" instead of "connection" now would risk creating that confusion. The key issue here is how to write the description in such a way that it is obvious to a TLS implementor in spite of the fact that the words "connection", "session" and "transport" have multiple possible meanings in the contexts where TLS is used. Here, then, is my proposed clarification: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the TLS session. (Yes, I changed "connection" to "session", followed by this:) Clarification: If a connection resumes a previous session, then the Finished message to use is that of the new session, not the one from the original session. If a session has multiple handshakes and, therefore, multiple client Finished messages, the first client Finished message of that session is the one to use as the tls-unique channel binding. From an application programming interface (API) perspective, the client's Finished message is saved in the contextual object handle that the client and server applications obtain when they initiate or resume a TLS session; later, when the applications request the tls-unique channel binding, the TLS implementation retrieves the saved first client Finished message from that context handle. Nico -- From jsalowey@cisco.com Wed Oct 28 10:06:02 2009 Return-Path: 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 D71253A6841 for ; Wed, 28 Oct 2009 10:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BsTH5mcfHnXb for ; Wed, 28 Oct 2009 10:06:02 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 056F23A6833 for ; Wed, 28 Oct 2009 10:06:01 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANYW6EqrR7Ht/2dsb2JhbADCOJgxhD8E X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="47261914" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Oct 2009 17:06:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SH6HsB020833; Wed, 28 Oct 2009 17:06:17 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:06:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 10:06:16 -0700 Message-ID: In-Reply-To: <4AE1311E.5080508@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.txt Thread-Index: AcpTmUll1ZXB520xTd6aaL55T31yQgEVIT/g References: <4AE1311E.5080508@pobox.com> From: "Joseph Salowey (jsalowey)" To: "Michael D'Errico" , X-OriginalArrivalTime: 28 Oct 2009 17:06:17.0151 (UTC) FILETIME=[F66BD4F0:01CA57F0] Subject: Re: [TLS] Working group last call for draft-ietf-tls-rfc4347-bis-03.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:06:02 -0000 Hi Mike, Thanks for looking at the document. I think that an extension to tell the client to switch ports or protocols is beyond the scope of the current work item. It would be best covered as a separate new work item if the working group thinks it is useful. Perhaps it is related to the proposal on next protocol negotiation that was sent to the list (it might not be, I haven't had a chance to read it yet). I'll open an issue for your other comments. Thanks, Joe > The link appears to go to the correct version of the draft,=20 > but the header of each page says it is draft -00 dated June 2008. >=20 > Overall the draft seems to be good, but one thing I think is=20 > missing is for the server to be able to somehow tell the=20 > client to switch to a different port for DTLS over UDP (I=20 > don't know about other types of transports). The simplest=20 > scheme I can envision is that the HelloVerifyRequest and=20 > ServerHello messages would be sent from the port the client=20 > initially contacted. The ServerHello would contain a=20 > DTLS_PortChange extension listing the new port number. The=20 > remainder of the handshake and subsequent data transfer would=20 > occur on this new port. >=20 > Comments on the draft: >=20 > In section 3. Overview of DTLS, it says: >=20 > 1. TLS's traffic encryption layer does not allow independent > decryption of individual records. If record N is not received, > then record N+1 cannot be decrypted. >=20 > I don't believe this is always true -- if a block cipher is=20 > used, then since there is an explicit IV given, you can=20 > decrypt the record. > The MAC, however, will not calculate correctly due to the=20 > wrong sequence number, so the missing record will be=20 > detected. Stream (and AEAD?) ciphers would fail to decrypt as stated. >=20 > Near the top of page 9, the abbreviation CSS is used. I=20 > think that should have been CCS, but I would suggest spelling=20 > out ChangeCipher Spec rather than abbreviating. >=20 > At the very end of section 4.2.1 (top of page 17) it mentions=20 > a HelloVerify message (not HelloVerifyRequest). Should that=20 > be a ClientHello message (with cookie)? >=20 > Typos: >=20 > - last line of page 3: "they typically requires" strike the s. > - section 4.1.1 second line, "that clients" remove "that" > - top of page 14 - "forget" should be "forgery" >=20 > Mike >=20 >=20 > Joseph Salowey (jsalowey) wrote: > > This is an announcement for working group last call on DTLS=20 > 1.2 (RFC=20 > > 4347-bis). The document is available here: > >=20 > > http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-03 > >=20 > > Please send any comments to the list by October 26, 2009. It is=20 > > useful to send an indication to the list if you have read=20 > the document=20 > > and think it is ready for publication even if you don't=20 > have specific=20 > > comments. > >=20 > > Thanks, > >=20 > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From jsalowey@cisco.com Wed Oct 28 10:34:50 2009 Return-Path: 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 07E733A697A for ; Wed, 28 Oct 2009 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 11VUn+FA5B2F for ; Wed, 28 Oct 2009 10:34:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AF1B83A69A5 for ; Wed, 28 Oct 2009 10:34:47 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABoe6EqrR7H+/2dsb2JhbADCSJgvhD8E X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="199434617" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Oct 2009 17:34:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SHYm8W003439 for ; Wed, 28 Oct 2009 17:34:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:34:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 10:34:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-tls-rfc4347-bis-03 last call issues Thread-Index: AcpX9PGuqZoSJPPtSLC/QfGt61XSJg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 28 Oct 2009 17:34:48.0093 (UTC) FILETIME=[F238DCD0:01CA57F4] Subject: [TLS] draft-ietf-tls-rfc4347-bis-03 last call issues 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:34:50 -0000 The comments received during the last call of draft-ietf-tls-rfc4347-bis-03 are captured in issue 103: http://trac.tools.ietf.org/wg/tls/trac/ticket/103 Joe From nelson@bolyard.me Wed Oct 28 10:34:54 2009 Return-Path: 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 41AEE3A6A2A for ; Wed, 28 Oct 2009 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LG9HYfz7MaGM for ; Wed, 28 Oct 2009 10:34:53 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 21DD53A697A for ; Wed, 28 Oct 2009 10:34:52 -0700 (PDT) Received: (qmail 22774 invoked from network); 28 Oct 2009 17:35:07 -0000 Received: from unknown (67.188.69.99) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 28 Oct 2009 17:35:07 -0000 Message-ID: <4AE880CA.3060902@bolyard.me> Date: Wed, 28 Oct 2009 10:35:06 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexei.Volkov@Sun.COM Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:34:54 -0000 On 2009-10-27 23:54 PDT, Peter Gutmann wrote: > Nelson B Bolyard writes: > >> I eagerly await your answers and comments. > > OK, I'll bite: > >> Q1) A client hello's SNI extension is defined such that it may contain >> multiple names. > > Intuitively I would say option (a) is the right one, if you're expecting > to connect to a.foo.com then it doesn't seem to make much sense to say > you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and > phishme.com. I'm sure someone can dream up some bizarre corner case > where you could in theory possibly somehow maybe do this, but in the > interests of implementation sanity I'd say you're only allowed one name. I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache only honors the first host name in the client hello SNI extension, and will send an unrecognized_name alert if that first name is unrecognized. I'm quite willing to follow that example and let that become the de facto standard. I just wish the RFC was clear about it, and wonder why the RFC even allows multiple names to be sent. >> Q2) if multiple non-synonymous names are included, is the server free >> to pick any one that it wants? > > This one is resolved by the solution for Q1 above. > >> Q3) Consider the "renegotiation" case, where a client and server >> negotiate an initial SSL handshake ("in the clear") and then negotiate >> a second handshake over the encrypted channel established by the first >> handshake. > > I'd say it's not permitted, it's still the same server and (again) all > you're going to do is create confusion if you allow new SNI's to be > inserted at this point. This answers all the subquestions in one. Well, consider that there are people who don't want to do client authentication in the initial handshake because they don't want to send the client cert over the wire in the clear. Perhaps they also don't want to send the virtual host name in the clear, or receive the cert for the intended virtual host in the clear. So, one could imagine that they do an initial handshake without any SNI, then a subsequent renegotiation with SNI. I'm not advocating that. I'm merely suggesting that forbidding SNI in renegotiation might be seen as unnecessarily restrictive in some applications. > Q4 and 5 get a bit complicated, I'd need to hear a bit more about the > circumstances where this might occur... I received some other email that suggests that my use of the word "scope" rather than "space" may have made the question unclear, so let me try to reword Q4 here. In the context of a physical server acting as multiple virtual server, is the space of session IDs coming from that server a single space that encompasses all the sessions for all the virtual servers served by that physical server? Or does each virtual server have its own separate space? If each virtual server has its own separate session ID space, then when attempting to "resume" or "restart" a TLS session, the client hello MUST bear an SNI extension to inform the physical server which virtual server's session ID space contains the given session ID, and each virtual server potentially has its own separate session store/cache. OTOH, if there is a single session ID space for the entire physical server covering all the virtual servers, then each cached session must record and identify the virtual server with which it is associated. I'm just wondering which way is the right way to implement session cache lookup in an SNI environment. From wtc@google.com Wed Oct 28 12:30:19 2009 Return-Path: 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 8CAEE3A689D for ; Wed, 28 Oct 2009 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 jxjD9zIkFDCI for ; Wed, 28 Oct 2009 12:30:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C431B3A6836 for ; Wed, 28 Oct 2009 12:30:15 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n9SJUUGd001284 for ; Wed, 28 Oct 2009 12:30:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1256758231; bh=uPmBVX8zbC/fumf8LR+Ww1WG5l4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=nLOer3RRgyMUexAuy4F6pSjSXG2n0xIwtd9aWFpvfeWlf1OV8i32gGYUSeMJv1iw4 9wRWlQ/zPG3GEkz8q9a7g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=WvlxBGYo3mzHpG3bB8t6hBh/twleE5og7wE1SBzQSyjv/hxF9AwNBVhNoViLIsVIe 60dqwphUIA/OvM67eBNWA== Received: from pxi2 (pxi2.prod.google.com [10.243.27.2]) by wpaz33.hot.corp.google.com with ESMTP id n9SJURmf028447 for ; Wed, 28 Oct 2009 12:30:28 -0700 Received: by pxi2 with SMTP id 2so790612pxi.11 for ; Wed, 28 Oct 2009 12:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.1.24 with SMTP id 24mr1412771wfa.73.1256758227490; Wed, 28 Oct 2009 12:30:27 -0700 (PDT) In-Reply-To: <4AE880CA.3060902@bolyard.me> References: <4AE880CA.3060902@bolyard.me> Date: Wed, 28 Oct 2009 12:30:27 -0700 Message-ID: From: Wan-Teh Chang To: Nelson B Bolyard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Alexei.Volkov@sun.com, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:30:19 -0000 On Wed, Oct 28, 2009 at 10:35 AM, Nelson B Bolyard wrot= e: > > In the context of a physical server acting as multiple virtual server, > is the space of session IDs coming from that server a single space that > encompasses all the sessions for all the virtual servers served by that > physical server? =A0Or does each virtual server have its own separate spa= ce? > > If each virtual server has its own separate session ID space, then when > attempting to "resume" or "restart" a TLS session, the client hello MUST > bear an SNI extension to inform the physical server which virtual server'= s > session ID space contains the given session ID, and each virtual server > potentially has its own separate session store/cache. When attempting to resume a TLS session, the client hello must bear an SNI extension for another reason: it's not guaranteed that the server will accept the request to resume the session. This issue is discussed in Section 2.3 of the TLS extensions RFC 3546. (The RFC uses SHOULD instead of MUST.) > OTOH, if there is a single session ID space for the entire physical serve= r > covering all the virtual servers, then each cached session must record an= d > identify the virtual server with which it is associated. If a client certificate is used in the session, it seems that the session should only be associated with the virtual server that authenticated the client certificate, as opposed to the entire physical server covering all the virtual servers. I guess there are multiple ways to accomplish that. Wan-Teh From Martin.Rex@sap.com Wed Oct 28 13:49:18 2009 Return-Path: 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 910E73A6A6A; Wed, 28 Oct 2009 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 qHyGQPzgBfkw; Wed, 28 Oct 2009 13:49:17 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DF1143A686C; Wed, 28 Oct 2009 13:49:15 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n9SKnSDG021053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 21:49:28 +0100 (MET) From: Martin Rex Message-Id: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 28 Oct 2009 21:49:28 +0100 (MET) In-Reply-To: <20091028163322.GO1105@Sun.COM> from "Nicolas Williams" at Oct 28, 9 11:33:23 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: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] [sasl] lasgt call comments (st Call: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:49:18 -0000 Nicolas Williams wrote: > > Here, then, is my proposed clarification: > > Description: The client's TLS Finished message (note: the Finished > struct) from the first handshake of the TLS session. > > (Yes, I changed "connection" to "session", followed by this:) > > Clarification: If a connection resumes a previous session, then the > Finished message to use is that of the new session, not the one from > the original session. If a session has multiple handshakes and, > therefore, multiple client Finished messages, the first client > Finished message of that session is the one to use as the tls-unique > channel binding. This description/terminology about resume/previous/new/original session is confusing and wrong. If a TLS session is resumed, then the result is always the SAME session, which is indicated by the use of the SAME session id (and internally, by the use of the same underlying master secret). A cached TLS session can be resumed quite often and simultaneously is parallel (which leads to multiple parallel/forked sessions). The session keys are newly re-derived for each connection and each session resume, and they should be unique because of the client random and server random that go into the session key derivation of every new connection (=resumed session). A resumed TLS session will also NOT exchange (and therefore not verify) any certificates. A new TLS session is created when one of - the client does not propose TLS session resume at all - the server does not agree to TLS session resumption, and creates and returns a new/different session id and performs a full handshake - the client performs a renegotiate for an established session (usually upon request from the server) and the server goes through a full ssl handshake. Since the finished messages of the tls handshake cover the client random and server random of the SSL handshake, the finished messages are going to be unique for each connection, even for two resumes of the same session. > From an application programming interface (API) > perspective, the client's Finished message is saved in the contextual > object handle that the client and server applications obtain when > they initiate or resume a TLS session; later, when the applications > request the tls-unique channel binding, the TLS implementation > retrieves the saved first client Finished message from that context > handle. Asking the TLS protocol stack to memorize the original finished message sounds awkward to me. The thing that the ssl session cache is already memorizing for a session is the master secret, so maybe deriving something from that would be better suited for the purpose than a requirement to store the original finished message. -Martin From larry.zhu@microsoft.com Wed Oct 28 13:59:41 2009 Return-Path: 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 0D95B3A6A81; Wed, 28 Oct 2009 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KgpZ4K5sm2WX; Wed, 28 Oct 2009 13:59:40 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 06DE83A6A6F; Wed, 28 Oct 2009 13:59:39 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 13:59:55 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 13:59:54 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 28 Oct 2009 13:59:53 -0700 From: Larry Zhu To: Nicolas Williams Thread-Topic: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV+4iBeoFgQlJYUez5TZwqZCo85EbZYWg Date: Wed, 28 Oct 2009 20:59:53 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091028160013.GL1105@Sun.COM> <20091028163322.GO1105@Sun.COM> In-Reply-To: <20091028163322.GO1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:59:41 -0000 How about The client's TLS Finished message (note: the Finished=20 struct) in the clear text form from the first handshake of=20 the TLS session as identified by the=20 session ID in the server=20 hello message, as defined in 7.4.1.3 of RFC5246,=20 of the last handshake in the current active TLS session. =20 Can we label this as "tls-session-unique"? The existing deployment seems to= have a different interpretation but we do not have a real usage case for t= hat. It does not hurt to create another label just to avoid potential inter= operability issues. This seems to be the most intuitive definition and we do not have any ambig= uity here. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as Williams Sent: Wednesday, October 28, 2009 9:33 AM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-ch= annel-bindings (Channel Bindings for TLS) to Proposed Standard) On Wed, Oct 28, 2009 at 11:00:13AM -0500, Nicolas Williams wrote: > On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote: > > There is a design issue in tls-unique. For vendors who implement TLS > > in a separate library, the TLS library does not by itself control the > > transport therefore it would not know if there is a new connection, so > > that the current specification is not implementable for these vendors. > >=20 > > It would be much easier to say the following instead: > >=20 > > The client's TLS Finished message from the first handshake of the > > session (note: TLS session, not connection, so that the channel > > binding is specific to each TLS session regardless of whether session > > resumption is used). I spoke to Jeff and I think I understand your issue, and I agree that we never meant for that interpretation. Proposed new text is below, but first... What the text says now: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). I think we meant to say is that if you're a server, and you see a ClientHello, and you do a handshake and then receive a client Finished message, and then return a handle to the application for the resulting TLS whatever-you-call-it, then _that_ Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). Similarly, if you're a client and send a ClientHello and so on and so forth and then return a handle to the application for the resulting TLS whatever-you-call-it, then the first Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). The reason we used the word "connection" in the description was to avoid the possibility that in a session resumption someone might interpret tls-unique to be the client Finished message of the original connection that established the session resumption state. Changing the text to say "session" instead of "connection" now would risk creating that confusion. The key issue here is how to write the description in such a way that it is obvious to a TLS implementor in spite of the fact that the words "connection", "session" and "transport" have multiple possible meanings in the contexts where TLS is used. Here, then, is my proposed clarification: Description: The client's TLS Finished message (note: the Finished=20 struct) from the first handshake of the TLS session. (Yes, I changed "connection" to "session", followed by this:) Clarification: If a connection resumes a previous session, then the Finished message to use is that of the new session, not the one from the original session. If a session has multiple handshakes and, therefore, multiple client Finished messages, the first client Finished message of that session is the one to use as the tls-unique channel binding. From an application programming interface (API) perspective, the client's Finished message is saved in the contextual object handle that the client and server applications obtain when they initiate or resume a TLS session; later, when the applications request the tls-unique channel binding, the TLS implementation retrieves the saved first client Finished message from that context handle. Nico --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Oct 28 14:05:36 2009 Return-Path: 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 C38F828C104; Wed, 28 Oct 2009 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.028, 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 SzRPAwTuo+Ml; Wed, 28 Oct 2009 14:05:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C0A223A6989; Wed, 28 Oct 2009 14:05:35 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SL5pHS023180; Wed, 28 Oct 2009 21:05:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SL5oIa039884; Wed, 28 Oct 2009 15:05:51 -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 n9SKsOxx002768; Wed, 28 Oct 2009 15:54:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SKsO3P002767; Wed, 28 Oct 2009 15:54:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 15:54:24 -0500 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091028205423.GG1105@Sun.COM> References: <20091028163322.GO1105@Sun.COM> <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org Subject: Re: [TLS] [sasl] lasgt call comments (st Call: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:05:36 -0000 On Wed, Oct 28, 2009 at 09:49:28PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > Here, then, is my proposed clarification: > > > > Description: The client's TLS Finished message (note: the Finished > > struct) from the first handshake of the TLS session. > > > > (Yes, I changed "connection" to "session", followed by this:) > > > > Clarification: If a connection resumes a previous session, then the > > Finished message to use is that of the new session, not the one from > > the original session. If a session has multiple handshakes and, > > therefore, multiple client Finished messages, the first client > > Finished message of that session is the one to use as the tls-unique > > channel binding. > > This description/terminology about resume/previous/new/original session > is confusing and wrong. > > > If a TLS session is resumed, then the result is always the SAME session, > which is indicated by the use of the SAME session id (and internally, > by the use of the same underlying master secret). Yes, I know. That's why we had written "connection" instead of session! But now Larry finds that confusing as well. > A cached TLS session can be resumed quite often and simultaneously is > parallel (which leads to multiple parallel/forked sessions). > > The session keys are newly re-derived for each connection and each > session resume, and they should be unique because of the client > random and server random that go into the session key derivation > of every new connection (=resumed session). > > A resumed TLS session will also NOT exchange (and therefore not verify) > any certificates. Indeed. But it does exchange Finished messages. That's crucial here. > Since the finished messages of the tls handshake cover the > client random and server random of the SSL handshake, the finished > messages are going to be unique for each connection, even for > two resumes of the same session. Exactly. That's what we want. > > From an application programming interface (API) > > perspective, the client's Finished message is saved in the contextual > > object handle that the client and server applications obtain when > > they initiate or resume a TLS session; later, when the applications > > request the tls-unique channel binding, the TLS implementation > > retrieves the saved first client Finished message from that context > > handle. > > Asking the TLS protocol stack to memorize the original finished message > sounds awkward to me. The thing that the ssl session cache is already > memorizing for a session is the master secret, so maybe deriving something > from that would be better suited for the purpose than a requirement to > store the original finished message. Argh, I've managed to confuse you too. I mean EXACTLY this: it's NOT the client Finished message from the _session_ that is being resumed (when one is), but the one for the connection. Martin, I appreciate your help, but we really need to hear from Larry, because I'm all confused, and as a result I'm confusing you too. Larry, can you please clarify? Nico -- From larry.zhu@microsoft.com Wed Oct 28 14:18:24 2009 Return-Path: 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 83D2028C14E; Wed, 28 Oct 2009 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xW-1jQJluLVc; Wed, 28 Oct 2009 14:18:23 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 630DD28C155; Wed, 28 Oct 2009 14:18:23 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 14:18:50 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 13:59:55 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 28 Oct 2009 13:59:52 -0700 From: Larry Zhu To: "Pasi.Eronen@nokia.com" , "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Thread-Topic: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV9Jq+JazopF2qkSChPC47bDhk5EbWFXw Date: Wed, 28 Oct 2009 20:59:53 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:18:24 -0000 Hi Pasi,=20 Thanks for allowing me to expand. A quick summary is that the tls-unique de= finition hinges on an ambiguous notation of "connection", and that is unnec= essary if not harmful.=20 To show why we should look at RFC5246 first. Please allow a disclaimer firs= t too. The following information is provided in order to demonstrate we can= make this better or over specified thus leave with no ambiguity therefore = improve interoperability. On page 39 of RFC 5246, we have the following text that describes the sessi= on id in the client hello message: The session identifier MAY be from an earlier connection, this connection, or from another currently active connection. This suggests that a connection can be associated with multiple sessions (a= s identified by "session IDs"). But then on page 79, we have the following = text Every connection is associated with one session. This seems to suggest a connection can only have one session (as identified= by a session ID). On page 81, we have the following text: Sessions are used to avoid the expensive negotiation of new security pa= rameters for each connection. Which seems to suggest that a session is identified by a session id. Do we = have a real inconsistency here?=20 With that it gets worse if we read the text on page 36: The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. Let's note the words "re-establish the connection" used here. It seems to s= uggest that in a TLS session resumption, we are merely re-establishing a pr= evious connection. There are evidences that suggest different interpretatio= ns exist as the recent responses from Joseph clearly demonstrated. Now the reader is left to wonder what really identifies a connection? Does = an unencrypted hello really demarcate a new connection as you suggested? If= we follow the path you suggested, it is desirable? If we interpret that a connection is one in the transport layer, the TLS li= brary does not know and should not care. In that case, it would have the pr= oblem I alluded earlier. Furthermore the current definition would not work with DTLS though if we th= row out the notion of "connection", say for example use the TLS session or = the last handshake, we can reuse the work for DTLS. I will discuss with the rest of the editor team and we should come up with = a recommendation for how to address this issue. Thanks, --Larry -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, October 28, 2009 6:27 AM To: Larry Zhu; channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: RE: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-= bindings (Channel Bindings for TLS) to Proposed Standard) Larry, Could you elaborate a bit about your first paragraph? =20 Certainly the TLS library knows when there's a new connection, because it receives (on the server) or sends (on the client) an unencrypted=20 ClientHello message? Best regards, Pasi > -----Original Message----- > From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of > ext Larry Zhu > Sent: 28 October, 2009 12:18 > To: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: Re: [sasl] lasgt call comments (st Call: draft-altman-tls- > channel-bindings (Channel Bindings for TLS) to Proposed Standard) >=20 >=20 > There is a design issue in tls-unique. For vendors who implement TLS in > a separate library, the TLS library does not by itself control the > transport therefore it would not know if there is a new connection, so > that the current specification is not implementable for these vendors. >=20 > It would be much easier to say the following instead: >=20 > The client's TLS Finished message from the first handshake of the > session (note: TLS session, not connection, so that the channel binding > is specific to each TLS session regardless of whether session > resumption is used). >=20 > And the updated text does reflect what has been deployed for tls- > unique. >=20 > I would like to raise a red flag now. Needless to say that I will start > a discussion with the responsible AD and the rest of the editors of > this ID to fix this issue, and do so based on consensus. >=20 > Pasi, please consider this issue blocking for now. >=20 > Thanks, >=20 > --Larry >=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel > Bindings for TLS) to Proposed Standard >=20 > The IESG has received a request from an individual submitter to > consider > the following document: >=20 > - 'Channel Bindings for TLS ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings- > 07.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag > =3D15087&rfc_flag=3D0 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl From Nicolas.Williams@sun.com Wed Oct 28 14:32:28 2009 Return-Path: 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 E0D0D3A68C3; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Z+Al+uglr3KS; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 121973A67F4; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SLWhmO004701; Wed, 28 Oct 2009 21:32:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SLWheo056711; Wed, 28 Oct 2009 15:32:43 -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 n9SLLHlU002786; Wed, 28 Oct 2009 16:21:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SLLHC8002785; Wed, 28 Oct 2009 16:21:17 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 16:21:17 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028212116.GI1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091028160013.GL1105@Sun.COM> <20091028163322.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:32:29 -0000 On Wed, Oct 28, 2009 at 08:59:53PM +0000, Larry Zhu wrote: > How about > > The client's TLS Finished message (note: the Finished > struct) in the clear text form from the first handshake of > the TLS session as identified by the > session ID in the server > hello message, as defined in 7.4.1.3 of RFC5246, > of the last handshake in the current active TLS session. > > > Can we label this as "tls-session-unique"? The existing deployment > seems to have a different interpretation but we do not have a real > usage case for that. It does not hurt to create another label just to > avoid potential interoperability issues. > > This seems to be the most intuitive definition and we do not have any > ambiguity here. Larry and I just spoke on the phone. The real issue is the word "connection". Apparently RFC5246 uses it in two senses, one of them being the-transport-layer-above-IP (i.e., TCP for TLS and UDP for DTLS, typically), and that is confusing. I explained to Larry that using "session" instead, as in his proposed text above is nearly impossible to implement, because it means updating session resumption state caches -- a very intrusive change to existing TLS implementations. What Larry really wants is to find a way to refer to what Microsoft's SSPI-based implementation of TLS calls a "security context". Advice on what would be the best TLS-specific term for "security context" is welcome. Nico -- From mike-list@pobox.com Wed Oct 28 16:17:57 2009 Return-Path: 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 7FEDA28C0D0 for ; Wed, 28 Oct 2009 16:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uJ8QFZiYFUJh for ; Wed, 28 Oct 2009 16:17:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 23E913A677C for ; Wed, 28 Oct 2009 16:17:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 224A48922B for ; Wed, 28 Oct 2009 19:18:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=oEeEOVlp2eS0 Ay8udhJtNesj0Qo=; b=SkvOlYIyQwPjT7FGIcNDCH5kYGLeJqOcZuOYLVCVh7Vs nlzW0rrjhE/AC8zyoS1rNCVWleJHlpT7j++h81jfEh0do8jUWFEq8BXk2w1xhP9k xzeXYHwCY6YhcCwUXGrykG+4IzzjwriGDip+2+ytHZgjw0SMJpTmlxmXWpkgCd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iIuRjl Ahjwbm+wXVc7TrKihA2gN6NcNdJ35TgoTFhgzwxHK2gzZk5BkgRKcGPDcj5/M5k/ JIrYFhWaVNatnJmyKg2fiTS9p8X2Ik20sAalWPdOYx9WoJfHDjtUvuFEjhSu5OoW ixZq7bpgPFXfQw2dc7yI2wnZseVvxPOSh4LFg= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1C3F58922A for ; Wed, 28 Oct 2009 19:18:11 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 72D1189218 for ; Wed, 28 Oct 2009 19:17:59 -0400 (EDT) Message-ID: <4AE8D177.3060805@pobox.com> Date: Wed, 28 Oct 2009 16:19:19 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AE7BC74.9010806@bolyard.me> In-Reply-To: <4AE7BC74.9010806@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 28CF9376-C418-11DE-9F5C-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 23:17:57 -0000 In my TLS implementation, I have created an object called a ServerIdentity which is more general than a domain name. A TLS server can be set up with any number of server identites, each of which can have any number of domain names and certificate chains, and you can also specify a few server options on a per-identity basis. When the Server Name Indication extension is received, the server goes through the list of domain names in order and searches for the ServerIdentity object containing the domain name. The first match is chosen and the handshake continues using the most appropriate certificate chain and also the options set for that identity. If none of the SNI names match, the server checks to see if a default ServerIdentity has been configured. If it has, the default identity is used, but an UnrecognizedName alert is sent to the client (level = warning). If no default identity has been configured, then a fatal UnrecognizedName alert is sent and the connection fails. My test server has two identities set up: Mike's Toolbox Network www.mikestoolbox.net + default RSA/SHA-1 signed RSA certificate chain RSA/SHA-1 signed DSA certificate chain (only works with TLS 1.2) RSA/SHA-256 signed RSA certificate chain RequestClientCertificate LoadDefaultRootCertificates Use1024BitDHParameters CacheSessions IssueSessionTickets Mike's Toolbox Charity www.mikestoolbox.org RSA/SHA-1 signed RSA certificate chain RSA/SHA-256 signed RSA certificate chain Use1536BitDHParameters CacheSessions IssueSessionTickets When you connect to the test server, the information returned includes the server identity that was negotiated. Mike Nelson B Bolyard wrote: > A few years ago, I implemented the SNI extension in a client-only TLS > library and it was really simple because I only ever sent one host name > to the server. Now I'm implementing the server side of SNI and I realize > that the RFC appears to allow clients to do much more complex things than > my client ever did. So, I have some questions seeking clarification about > the definition of SNI. I hope someone here can help me by answering some > of these questions. > > Q1) A client hello's SNI extension is defined such that it may contain > multiple names. Perhaps the intent was to allow the same server to be > named in multiple different name spaces (DNS and others), but I saw nothing > in RFC 4366 that precludes the client from naming multiple different hosts > in a single ServerNameList. If a client names multiple host names in a > single client hello SNI extension (let's call them A.foo.com, B.foo.com and > C.foo.com) how does the client learn which one of those has been chosen by > the server? RFC 4366 requires the "extension_data" field of the SNI > extension in the server hello to be empty. The server may respond with a > "wildcard" certificate ("*.foo.com"), or with a certificate with multiple > Subject Alternative Names that include more than one of the names given by > the client. In that case, how does the client know which FQDN is the one > that the physical server has chosen/identified? > > I can think of lots of possible answers here, including > > a) It is an error to include multiple names in the same name space, e.g. > multiple DNS names. (but the RFC doesn't say that.) > > b) If multiple names are included, they must be logically synonymous, all > alternative names for the same host. (What if they're not?) > > Q2) if multiple non-synonymous names are included, is the server free to > pick any one that it wants? > > Q3) Consider the "renegotiation" case, where a client and server negotiate > an initial SSL handshake ("in the clear") and then negotiate a second > handshake over the encrypted channel established by the first handshake. > Are there any special requirements or prohibitions on the use and contents > of the client hello's SNI extension in the renegotiation case? > > Q3a) Is SNI permitted in that case? > Q3b) Is it required to match the SNI of the original handshake, if any? > Q3c) If it contains multiple non-synonymous host names, is the server > allowed to choose a different one than the one chosen in the first > handshake? > > The next questions have to do with the "resumption" or "restart" of a TLS > session that has been previously established using an SNI extension that > named one or more virtual hosts in a connection to a physical server on > an IP address and port. > > Q4) In that context, is the scope of a TLS session ID that of the physical > server, or that of a virtual server? When attempting to restart a TLS > session on a new connection, does the TLS session ID in the client hello > uniquely identify the virtual host and its session to the physical server, > even in the absence of an SNI extension? Or is it possible that each of > the virtual servers within the physical host may have used that same > session ID, in which case it would be necessary for the client to supply the > virtual host's FQDN in an SNI extension to uniquely identify the session? > > Q5) When an SNI extension was used to establish a TLS session, it is > required that an SNI extension bearing the same host name be used in the > client hello that attempts to "restart" or "resume" the session on a new > connection? > > (Obviously Q3, Q4 and Q5 overlap.) > > > I eagerly await your answers and comments. > > /Nelson Bolyard > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nelson@bolyard.me Wed Oct 28 16:26:07 2009 Return-Path: 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 67F9F3A68C7 for ; Wed, 28 Oct 2009 16:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PaRuRZ6e3bjC for ; Wed, 28 Oct 2009 16:26:06 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 8454E3A67FC for ; Wed, 28 Oct 2009 16:26:06 -0700 (PDT) Received: (qmail 28374 invoked from network); 28 Oct 2009 23:26:15 -0000 Received: from unknown (67.188.69.99) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 28 Oct 2009 23:26:15 -0000 Message-ID: <4AE8D30D.6020305@bolyard.me> Date: Wed, 28 Oct 2009 16:26:05 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <4AE880CA.3060902@bolyard.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexei.Volkov@sun.com Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 23:26:07 -0000 On 2009-10-28 12:30 PDT, Wan-Teh Chang wrote: > On Wed, Oct 28, 2009 at 10:35 AM, Nelson B Bolyard wrote: >> In the context of a physical server acting as multiple virtual server, >> is the space of session IDs coming from that server a single space that >> encompasses all the sessions for all the virtual servers served by that >> physical server? Or does each virtual server have its own separate space? >> >> If each virtual server has its own separate session ID space, then when >> attempting to "resume" or "restart" a TLS session, the client hello MUST >> bear an SNI extension to inform the physical server which virtual server's >> session ID space contains the given session ID, and each virtual server >> potentially has its own separate session store/cache. > > When attempting to resume a TLS session, the client hello must > bear an SNI extension for another reason: it's not guaranteed that > the server will accept the request to resume the session. This issue > is discussed in Section 2.3 of the TLS extensions RFC 3546. (The > RFC uses SHOULD instead of MUST.) > >> OTOH, if there is a single session ID space for the entire physical server >> covering all the virtual servers, then each cached session must record and >> identify the virtual server with which it is associated. There's another issue that arises with both the SNI extension and a single session ID space for the entire physical server. Which takes precedence? Consider this scenario: Physical host has two virtual hosts, A and B. First handshake: client sends SNI with host name A, empty session ID. server does full handshake, session ID 1. Second handshake (renegotiation): client sends SNI with host name B and session ID 1, Session ID 1 implicitly identifies host A. The server could A) Honor the session ID and ignore the SNI. B) Compare the host name in the SNI with the host name for session ID 1, observe the mismatch, and do a new FULL handshake for host B. C) Compare the host name in the SNI with the host name for session ID 1, observe the mismatch, and return a fatal error alert. RFC 5246 seems to suggest choice A. It says: 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. But I tend to lean towards choice B myself. What do other SNI server implementations do in this case? From mickgray@au1.ibm.com Wed Oct 28 17:11:01 2009 Return-Path: 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 EACB03A68C7 for ; Wed, 28 Oct 2009 17:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lQeLsHCaET5q for ; Wed, 28 Oct 2009 17:11:01 -0700 (PDT) Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id CE0683A68E4 for ; Wed, 28 Oct 2009 17:11:00 -0700 (PDT) Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9T08clh007334 for ; Thu, 29 Oct 2009 11:08:38 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9T08LiA1687772 for ; Thu, 29 Oct 2009 11:08:22 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9T0BDlA027776 for ; Thu, 29 Oct 2009 11:11:13 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9T0BCmb027769; Thu, 29 Oct 2009 11:11:12 +1100 In-Reply-To: <4AE8D30D.6020305@bolyard.me> To: Nelson B Bolyard X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Thu, 29 Oct 2009 10:04:02 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 29/10/2009 11:17:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: Alexei.Volkov@sun.com, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 00:11:02 -0000 wrote: > Consider this scenario: > Physical host has two virtual hosts, A and B. > First handshake: > client sends SNI with host name A, empty session ID. > server does full handshake, session ID 1. > Second handshake (renegotiation): > client sends SNI with host name B and session ID 1, > > Session ID 1 implicitly identifies host A. > > The server could > A) Honor the session ID and ignore the SNI. > B) Compare the host name in the SNI with the host name for session ID 1, > observe the mismatch, and do a new FULL handshake for host B. > C) Compare the host name in the SNI with the host name for session ID 1, > observe the mismatch, and return a fatal error alert. > > RFC 5246 seems to suggest choice A. It says: > > 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. > > But I tend to lean towards choice B myself. > > What do other SNI server implementations do in this case? A for IBM native SSL. The Client SNI data is only processed if the session can NOT be resumed. Also as an answer to the previous question; we only consider that the Client has sent a single name in Client SNI request. Also on previous note 'because they don't want to send the client cert over the wire in the clear" For what reason would you require a client cert or a host name or a host certificate to be not treated as public information? Of course it could be a good way to cover your tracks if you were up to no good :-) Mick Gray IBM > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From wtc@google.com Wed Oct 28 17:51:55 2009 Return-Path: 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 9828628C0F8 for ; Wed, 28 Oct 2009 17:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 z96oVBSsgG9N for ; Wed, 28 Oct 2009 17:51:54 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 823D428C0F5 for ; Wed, 28 Oct 2009 17:51:54 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id n9T0q9oj030622 for ; Wed, 28 Oct 2009 17:52:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1256777530; bh=4RRO8H4XU2uB8Wzjc7TrcCSumPU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Cq/7bUCF+AEZkv4or3yvcnnyv5Z/Ia5IsjQ3BXRUrOmE/Oh6JE81VJP6XYPVEN1Kf mXxAh74k8P4cjQPobzTsw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HXSFlV1Kyf9miJ12CW6TQgmbR6BcykcA0GDy0+jDOHjtDUwPDInbkOabJQtzl3/A2 Fp+MNR9fd5jsRn6+f+BQQ== Received: from pwj21 (pwj21.prod.google.com [10.241.219.85]) by wpaz37.hot.corp.google.com with ESMTP id n9T0pZpN026281 for ; Wed, 28 Oct 2009 17:52:07 -0700 Received: by pwj21 with SMTP id 21so1189589pwj.19 for ; Wed, 28 Oct 2009 17:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.8.34 with SMTP id 34mr1522846wfh.103.1256777524919; Wed, 28 Oct 2009 17:52:04 -0700 (PDT) In-Reply-To: <4AE8D30D.6020305@bolyard.me> References: <4AE880CA.3060902@bolyard.me> <4AE8D30D.6020305@bolyard.me> Date: Wed, 28 Oct 2009 17:52:04 -0700 Message-ID: From: Wan-Teh Chang To: Nelson B Bolyard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Alexei.Volkov@sun.com, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 00:51:55 -0000 On Wed, Oct 28, 2009 at 4:26 PM, Nelson B Bolyard wrote= : > > Consider this scenario: > Physical host has two virtual hosts, A and B. > First handshake: > =A0client sends SNI with host name A, empty session ID. > =A0server does full handshake, session ID 1. > Second handshake (renegotiation): > =A0client sends SNI with host name B and session ID 1, I think "renegotiation" should be "resumption". In this case, the client should not request a resumption handshake with session ID 1, because the server won't send a certificate in a resumption handshake, so the client cannot verify the server has a certificate for host name B. The only exception is that the certificate for host name A has a subject alternative name for host name B. Wan-Teh From pgut001@wintermute01.cs.auckland.ac.nz Wed Oct 28 22:58:06 2009 Return-Path: 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 B82153A67AE for ; Wed, 28 Oct 2009 22:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TXd+uWaQOl8H for ; Wed, 28 Oct 2009 22:58:06 -0700 (PDT) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id BE15C3A66B4 for ; Wed, 28 Oct 2009 22:58:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A847D9F240; Thu, 29 Oct 2009 18:58:11 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyyQcc-adzbL; Thu, 29 Oct 2009 18:58:11 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E655C9F178; Thu, 29 Oct 2009 18:58:10 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N3O1S-0001OS-IY; Thu, 29 Oct 2009 18:58:10 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N3O1S-00053d-Kt; Thu, 29 Oct 2009 18:58:10 +1300 From: Peter Gutmann To: nelson@bolyard.me, tls@ietf.org In-Reply-To: <4AE880CA.3060902@bolyard.me> Message-Id: Sender: pgut001 Date: Thu, 29 Oct 2009 18:58:10 +1300 Cc: Alexei.Volkov@Sun.COM Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 05:58:06 -0000 Nelson B Bolyard writes: >In the context of a physical server acting as multiple virtual server, is the >space of session IDs coming from that server a single space that encompasses >all the sessions for all the virtual servers served by that physical server? >Or does each virtual server have its own separate space? > >If each virtual server has its own separate session ID space, then when >attempting to "resume" or "restart" a TLS session, the client hello MUST bear >an SNI extension to inform the physical server which virtual server's session >ID space contains the given session ID, and each virtual server potentially >has its own separate session store/cache. > >OTOH, if there is a single session ID space for the entire physical server >covering all the virtual servers, then each cached session must record and >identify the virtual server with which it is associated. Ah, I see what you mean now. Well in general I don't think it's going to be an issue, the session ID is a 32-byte blob so it's up to the server what it puts in there, it can include a virtual server ID, cache ID, whatever it wants in any format it requires. In other words if the server wants to encode configuration- or server architecture-specific details in the session ID then the form and type is up to the server, you don't need an explicit SNI for this, particularly since the free-form blob accomodates much more than just the virtual server : cache ID pair that the SNI + session ID handles. Peter. From mike-list@pobox.com Thu Oct 29 12:43:57 2009 Return-Path: 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 2BA323A6A0D for ; Thu, 29 Oct 2009 12:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 fs6dZ1+DwfSY for ; Thu, 29 Oct 2009 12:43:56 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 5F2723A68FF for ; Thu, 29 Oct 2009 12:43:55 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 03A9E8A9E1 for ; Thu, 29 Oct 2009 15:44:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=Taymgw17NjheI+nRdbSS2ndW2 2Q=; b=kJlUThw6B8A/0TrZPGPP+0HkRNRbu/c7f6ZMBzKvUDm6dOR8eH5iRfAkz e9eDcE68uD4JdJ+3MrodiJ/C6V5PWuZrUwDN2dtxp90coqilQceE6tRvmbGp/Xac j2k1RPMEQibJ/ipyuBRJpFhdgmp+E+A5/1ks6pVmRfPFP9cOk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=Xi4RNK4DHxf9XOT0Ycg JrmVEcH2Glz8k2br/lcnaH/xgnbU+Io9JtJFWMD1I+kE6KyKovLJ2mJmE36BODyw X6Kq5lbHIGLs0viCsfgvEOC/Yye48OKVFeLISSjlUovmUXshk8JywkXCbr9OcX4E 5Vu4MtrU0t1X28wDNVCFhSGY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 00D5B8A9E0 for ; Thu, 29 Oct 2009 15:44:10 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 79D458A9DF for ; Thu, 29 Oct 2009 15:44:09 -0400 (EDT) Message-ID: <4AE9F0DE.7060903@pobox.com> Date: Thu, 29 Oct 2009 12:45:34 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6DECA448-C4C3-11DE-9472-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] Server Signature Algorithms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:43:57 -0000 There are now at least 3 instances where a TLS client needs to know the server's list of supported signature algorithms: 1. to compute the signature for the CertificateVerify message 2. to compute the hash of the handshake messages in (1) without having to hold onto all of the messages 3. to compute hashes for the proposed cached information extension Rather than duplicate the list for each of these and any future needs, it makes sense to send it once in a server hello extension. The simplest option would be to use the existing signature algorithms extension and make it symmetrical. But if there is a deployed client out there that aborts a connection if it receives a signature algorithm extension, then a secondary option would be to create a new server- signature-algorithms extension which is identical in structure to the existing extension. I would add that when the server sends its list of algorithms in the extension, then it MUST NOT send a different list in the certificate request message; in fact it SHOULD send an empty list. TLS 1.3 can decide whether to eliminate the list from CertificateRequest. Mike From Martin.Rex@sap.com Thu Oct 29 15:45:57 2009 Return-Path: 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 25E7A3A691C for ; Thu, 29 Oct 2009 15:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.737 X-Spam-Level: X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, 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 jrFAdDfuR3og for ; Thu, 29 Oct 2009 15:45:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7AC423A689E for ; Thu, 29 Oct 2009 15:45:54 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n9TMk7Kp012598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Oct 2009 23:46:08 +0100 (MET) From: Martin Rex Message-Id: <200910292246.n9TMk6sZ014367@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Thu, 29 Oct 2009 23:46:06 +0100 (MET) In-Reply-To: <4AE7BC74.9010806@bolyard.me> from "Nelson B Bolyard" at Oct 27, 9 08:37:24 pm 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: Alexei.Volkov@Sun.COM, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 22:45:57 -0000 Nelson B Bolyard wrote: > > Q1) A client hello's SNI extension is defined such that it may contain > multiple names. Perhaps the intent was to allow the same server to be > named in multiple different name spaces (DNS and others), but I saw nothing > in RFC 4366 that precludes the client from naming multiple different hosts > in a single ServerNameList. It seems that it is a defect of RFC4366 to not indicate that a ServerNameList must contain at most one entry per NameType. > > a) It is an error to include multiple names in the same name space, e.g. > multiple DNS names. (but the RFC doesn't say that.) > > b) If multiple names are included, they must be logically synonymous, all > alternative names for the same host. (What if they're not?) If I would implement the server side, I would entirely ignore everything besides the first entry in the List of each NameType my implementation recognizes (i.e. Hostname). > > Q2) if multiple non-synonymous names are included, is the server free to > pick any one that it wants? There is no such thing as a synonymous DNS name (the hostname Nametype) -- either it is exactly the same name (case-insensitive, of course), or it is a different name. There is exactly _one_ name that goes into the opening/connect of the particular network connection through which the ClientHello with the SNI extension is sent, and that name ought to be put into the SNI by a sensible TLS client implementation, if anything at all. Btw. RFC-4366 doesn't say what to do about IP-Addresses. Since rfc-2818.txt indicates that Server certificates may contain SANs of the type iPAddress, sending IP-Addresses also via SNI sounds like the way to go when e.g. the Browser tries to open a URL with only an IPaddress instead of a hostname.. The server is free to do whatever it wants, including ignoring the SNI entirely (which is what most servers are doing today anyway). The more interesting question is what is the client (and in particular one that sends such a stupid request) going to do about all of the possible server behaviour? A client that sends more than one ServerName of the same type is quite likely broken (or debugging or attacking the server). > > Q3) Consider the "renegotiation" case, where a client and server negotiate > an initial SSL handshake ("in the clear") and then negotiate a second > handshake over the encrypted channel established by the first handshake. > Are there any special requirements or prohibitions on the use and contents > of the client hello's SNI extension in the renegotiation case? A client that performs a TLS renegotiation or TLS session resumption with a different SNI information as in the original ClientHello is probably broken (or debugging or attacking the server). In principle, the client should assert exactly the same TLS extensions on a TLS session resume or TLS session renegotiation than what it asserted on the original Client Hello. If the client wants to assert other TLS extensions, it should NOT try to resume a previous SSL session (i.e. it should sent an empty TLS session id) > > Q3a) Is SNI permitted in that case? This is definitely not a question of permission. The issue is consistent and sensible behaviour of a TLS client. > > Q3b) Is it required to match the SNI of the original handshake, if any? The spec doesn't make explicit requirements, it is a requirement implied by common sense. Clients that don't do it are quite likely broken. > > Q4) In that context, is the scope of a TLS session ID that of the physical > server, or that of a virtual server? When attempting to restart a TLS > session on a new connection, does the TLS session ID in the client hello > uniquely identify the virtual host and its session to the physical server, > even in the absence of an SNI extension? Or is it possible that each of > the virtual servers within the physical host may have used that same > session ID, in which case it would be necessary for the client to supply the > virtual host's FQDN in an SNI extension to uniquely identify the session? There are two different angles to look at this problem: server and client. A TLS server implementation that supports multiple different credentials on the same communication endpoint ought to implement its behaviour in a consistent and predictable fashion. If the server supports credential selection through SNI, it should keep session caches seperate per SNI-- and also per cihpersuites offered by the client. There may be even more attributes or TLS extensions which the server session cache should differentiate. It entirely depends on whether the server supports more than a single SSL credential on a communication endpoint, and what differences in characteristics the supported credentials have. If the can easily determine that the TLS session resume will result in significantly different session characteristics than a full TLS handshake based on the received ClientHello then it should perform a full handshake. There are much more interesting questions: when a TLS session in the cache was originally established with protocol version 0x03,0x01 what about a client resume proposal with a protocol version 0x03.0x00 or 0x03,0x02 in the client_version of the ClientHello? A TLS client that has cached a TLS session should only propose to resume it, when it connects to exactly the same Server and the same Port (and for Web-Browsers, that means the name&port as it appears in the URL and is independent of the ipaddr&port on the transport layer because of client-side TLS proxies). A TLS client should *NEVER* make assumptions about independent servers (i.e. independent ServerNames) sharing a TLS session cache. Sensible TLS clients should NOT assume that TLS servers on different ports of the same host share the TLS session cache (or credentials or any other TLS characteristics, for that matter). We had a problem with some vendors TLS implementation that made flawed assumptions about services on different ports of the same machine (hostname). We had one particular configuration where there was a service with a RSA-credential and SSLv3-only implementation listening on one port and a different service with a DSA-credential and TLS-v1.0-capable. When that vendors TLS implementation was sent from the DSA-cred-TLS-v1.0-capable service with an URL to the RSA-cred-SSLv3-only service on a different port of the same host it exhibited two problems: - it incorrectly proposed TLS session resumption in the ClientHello - it failed the full SSL handhskae with a fatal error because it wasn't able to deal with the switch DSA->RSA ciphersuites and TLSv1.0->SSLv3 in a full handshake resulting from a failed TLS session resume proposal. In order to make the URL(redirect) work, you had to clear the SSL state first, flushing the TLS session cache. Consistent behaviour is really the key point here. When and how often a TLS session resume will fail and result in a full TLS handshake can depend very much on the load on the server (we use a default cache lifetime of 15 minutes for the SSL sessions on the server). A different Server credential may result in a different ciphersuite and in a different set of trust anchors for client cert verification, so the server side cache should probably be tied to the server credential, if the server supports more than one credential, and selection should be based on SNI in case that the server supports virtual hosting and credentials selection through SNI. > > Q5) When an SNI extension was used to establish a TLS session, it is > required that an SNI extension bearing the same host name be used in the > client hello that attempts to "restart" or "resume" the session on a new > connection? Again, this is common sense. A client that uses different TLS extensions here is either broken, doing fancy debugging, or attacking the server. A server that supports more than one credential on a single communication endpoint should really use entirely seperate session caches per credential. If you have a server running with 30 virtual hosts and the same number of independen SSL server credentials, and you change only one of these credentials (like replace the existing server cert with a renewed one, i.e. one with a longer validity), then a good server design will allow you to update that state without server downtime, and flushing exactly the TLS session cache related to the updated server credential while leaving all other server credentials and cached sessions untouched and valid. -Martin From Martin.Rex@sap.com Thu Oct 29 16:26:46 2009 Return-Path: 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 5F0F33A6914 for ; Thu, 29 Oct 2009 16:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 fyskNWehXDaG for ; Thu, 29 Oct 2009 16:26:45 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 493343A6781 for ; Thu, 29 Oct 2009 16:26:45 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9TNQwWI013512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 00:26:58 +0100 (MET) From: Martin Rex Message-Id: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 30 Oct 2009 00:26:57 +0100 (MET) In-Reply-To: <4AE8D30D.6020305@bolyard.me> from "Nelson B Bolyard" at Oct 28, 9 04:26:05 pm 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: Alexei.Volkov@sun.com, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 23:26:46 -0000 Nelson B Bolyard wrote: > > There's another issue that arises with both the SNI extension and a single > session ID space for the entire physical server. Which takes precedence? > > Consider this scenario: > Physical host has two virtual hosts, A and B. > First handshake: > client sends SNI with host name A, empty session ID. > server does full handshake, session ID 1. > Second handshake (renegotiation): > client sends SNI with host name B and session ID 1, That client is obviously broken. > > Session ID 1 implicitly identifies host A. > > The server could > A) Honor the session ID and ignore the SNI. > B) Compare the host name in the SNI with the host name for session ID 1, > observe the mismatch, and do a new FULL handshake for host B. > C) Compare the host name in the SNI with the host name for session ID 1, > observe the mismatch, and return a fatal error alert. If the server supports virtual hosting through SNI, it should look up the session ID of the client only in the session cache associated with the hostname A. If a TLS session resume proposal with and SNI for B arrives, there will be no cached session with that session ID in the TLS session cache tied to credential for A, so it must result in a full TLS handshake. A server that has different credentials for A and B (and would use them based on SNI is definitely broken if it agrees to a proposed resume of a session originally established with A in a ClientHello that carries an SNI for B, because the server knows exactly that the server certificate that the client has for this session is NOT the same certificate that the server would send in a full handshake for B. And similiar uncertainty may apply to availability of a client certificate of even an already cached client certificate. -Martin From mike-list@pobox.com Thu Oct 29 20:15:35 2009 Return-Path: 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 487D73A6849 for ; Thu, 29 Oct 2009 20:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 qd0V7djwBoTo for ; Thu, 29 Oct 2009 20:15:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 77FF83A679C for ; Thu, 29 Oct 2009 20:15:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D34A48BD63 for ; Thu, 29 Oct 2009 23:15:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GchSUd/ozNMc QS+e+34hLSt+aIE=; b=K+bwia+y7k7at7ttNJxTXAxcY6QDil2uRGfXiSs+Jmzz 8xUltk61BgeeHVeLVOemcGES0NJhINQOAUVN+UwWpRKom8NRWX5pn/975chZwfmf wHxcOaRs2/fuGulJJQ5tHcczD+kmZn8mvzq/PAZKTgT4Tc2sqJek7c06lX2MdZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=pHJBN+ hTDzlHUMyDqtj/vn1+ozZ7POHyUD7GrEp9MQqlO9Pk/tWOjnqj12lE6atazKG6cW x+BJo0xQnXeOm6ThLDxb+eIkwNbLZ19kRYiJJy7ZPoXHWfirTfLfS5+6CnwSN69m X2OWNcP4Jtm6RfLk1rlO7rXhK2JaPjYLQcnr4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CFFF08BD62 for ; Thu, 29 Oct 2009 23:15:50 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 79FF98BD61 for ; Thu, 29 Oct 2009 23:15:50 -0400 (EDT) Message-ID: <4AEA5ABD.5040302@pobox.com> Date: Thu, 29 Oct 2009 20:17:17 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AE9F0DE.7060903@pobox.com> In-Reply-To: <4AE9F0DE.7060903@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 86B1917A-C502-11DE-BE9C-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Server Signature Algorithms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 03:15:35 -0000 If the existing signature algorithms extension is made symmetric, then the server still will need to put the same list of algorithms in the certificate request since it will not know whether the client knows about the change. Mike I wrote: > There are now at least 3 instances where a TLS client needs to know the > server's list of supported signature algorithms: > > 1. to compute the signature for the CertificateVerify message > 2. to compute the hash of the handshake messages in (1) without > having to hold onto all of the messages > 3. to compute hashes for the proposed cached information extension > > Rather than duplicate the list for each of these and any future needs, > it makes sense to send it once in a server hello extension. > > The simplest option would be to use the existing signature algorithms > extension and make it symmetrical. But if there is a deployed client > out there that aborts a connection if it receives a signature algorithm > extension, then a secondary option would be to create a new server- > signature-algorithms extension which is identical in structure to the > existing extension. > > I would add that when the server sends its list of algorithms in the > extension, then it MUST NOT send a different list in the certificate > request message; in fact it SHOULD send an empty list. TLS 1.3 can > decide whether to eliminate the list from CertificateRequest. > > Mike From nelson@bolyard.me Thu Oct 29 21:36:34 2009 Return-Path: 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 91B123A69C5 for ; Thu, 29 Oct 2009 21:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] 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 QlXfLwn0+Y5k for ; Thu, 29 Oct 2009 21:36:33 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id BC3A13A6970 for ; Thu, 29 Oct 2009 21:36:33 -0700 (PDT) Received: (qmail 28307 invoked from network); 30 Oct 2009 04:36:44 -0000 Received: from unknown (67.188.69.99) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 30 Oct 2009 04:36:44 -0000 Message-ID: <4AEA6D5B.8060704@bolyard.me> Date: Thu, 29 Oct 2009 21:36:43 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexei.Volkov@sun.com Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 04:36:34 -0000 On 2009-10-28 17:04 PDT, Michael Gray wrote: > wrote: > >> Consider this scenario: >> Physical host has two virtual hosts, A and B. >> First handshake: >> client sends SNI with host name A, empty session ID. >> server does full handshake, session ID 1. >> Second handshake (renegotiation): >> client sends SNI with host name B and session ID 1, >> >> Session ID 1 implicitly identifies host A. >> >> The server could >> A) Honor the session ID and ignore the SNI. >> B) Compare the host name in the SNI with the host name for session ID 1, >> observe the mismatch, and do a new FULL handshake for host B. >> C) Compare the host name in the SNI with the host name for session ID 1, >> observe the mismatch, and return a fatal error alert. >> >> RFC 5246 seems to suggest choice A. It says: >> >> 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. >> >> But I tend to lean towards choice B myself. >> >> What do other SNI server implementations do in this case? > > A for IBM native SSL. The Client SNI data is only processed if the session > can NOT be resumed. > > Also as an answer to the previous question; we only consider that the > Client has sent a single name in Client SNI request. Thanks, Mick, for those concise answers. Sadly, I don't sense that we have a consensus from among the responses yet, except on the point that the SNI client hello should only contain one name of each type. I think that interoperability demands that we standardize these answers. I predict that we'll end up with these below(which I think match yours) but I fear that existing implementations differ from these a fair bit. - Only one name per type is allowed and used in the client hello SNI. - The session ID space covers all the sessions for the entire physical host including all the virtual hosts, so by itself, the session ID contains all the information necessary to determine which virtual host uses the session with that ID. It is not necessary to consult the SNI host name to know which virtual host's session cache to examine to find the session ID. - The SNI extension is ignored if the session can be resumed based on the session ID, and no matching/checking is done to ensure that the SNI host name matches the name in the resumed session, when the session is resumed. > Also on previous note 'because they don't want to send the client > cert over the wire in the clear" > > For what reason would you require a client cert or a host name or a host > certificate to be not treated as public information? I don't know. I work on NSS, an open source TLS library that is used in lots of applications and is discussed in an open mailing list and newsgroup (mozilla.dev.tech.crypto). One of the application developers who uses NSS has this issue, but I don't know why. I'd guess it's the usual extreme security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :) > Mick Gray > IBM From nelson@bolyard.me Thu Oct 29 21:52:25 2009 Return-Path: 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 9DFC83A69D4 for ; Thu, 29 Oct 2009 21:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599] 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 up+yEvV0sMIm for ; Thu, 29 Oct 2009 21:52:24 -0700 (PDT) Received: from p3plsmtpa01-06.prod.phx3.secureserver.net (p3plsmtpa01-06.prod.phx3.secureserver.net [72.167.82.86]) by core3.amsl.com (Postfix) with SMTP id C05BF3A68B8 for ; Thu, 29 Oct 2009 21:52:24 -0700 (PDT) Received: (qmail 23816 invoked from network); 30 Oct 2009 04:52:39 -0000 Received: from unknown (67.188.69.99) by p3plsmtpa01-06.prod.phx3.secureserver.net (72.167.82.86) with ESMTP; 30 Oct 2009 04:52:39 -0000 Message-ID: <4AEA7117.7050309@bolyard.me> Date: Thu, 29 Oct 2009 21:52:39 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp> In-Reply-To: <200910292326.n9TNQvVb016843@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexei.Volkov@sun.com Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 04:52:25 -0000 On 2009-10-29 16:26 PDT, Martin Rex wrote: > Nelson B Bolyard wrote: >> There's another issue that arises with both the SNI extension and a single >> session ID space for the entire physical server. Which takes precedence? >> >> Consider this scenario: >> Physical host has two virtual hosts, A and B. >> First handshake: >> client sends SNI with host name A, empty session ID. >> server does full handshake, session ID 1. >> Second handshake (renegotiation): >> client sends SNI with host name B and session ID 1, > > That client is obviously broken. Perhaps, but the question is what does the server do about it? >> Session ID 1 implicitly identifies host A. >> >> The server could >> A) Honor the session ID and ignore the SNI. >> B) Compare the host name in the SNI with the host name for session ID 1, >> observe the mismatch, and do a new FULL handshake for host B. >> C) Compare the host name in the SNI with the host name for session ID 1, >> observe the mismatch, and return a fatal error alert. > > If the server supports virtual hosting through SNI, that's a given for this exercise > it should look up the session ID of the client only in the session cache > associated with the hostname A. And it should choose hostname A because why? Remember that in the above example, the SNI bears host name B. > If a TLS session resume proposal with [an] SNI for B arrives, > there will be no cached session with that session ID in the > TLS session cache tied to credential for A, so it must result > in a full TLS handshake. So, you're proposing that the server should look in the SNI first to see which host name is there, and use that info to decide which virtual host's server session cache to examine for the numbered session? In other words, each virtual host has its own separate session cache with fully overlapping spaces of session ID numbers, disambiguated by the SNI host name, yes? In this model, an SNI would be absolutely required to resume a session that had been established with an SNI, yes? > A server that has different credentials for A and B (and would > use them based on SNI The whole point of SNI is to have different credentials for different virtual hosts. If you don't have different credentials for different virtual hosts, (e.g. if you have a single certificate for all your virtual hosts) then you don't need SNI. > is definitely broken if it agrees to a proposed resume of a session > originally established with A in a ClientHello that carries an SNI for B, > because the server knows exactly that the server certificate that the > client has for this session is NOT the same certificate that the server > would send in a full handshake for B. This objective could be accomplished with a single server session cache that covered the entire physical server and all its virtual servers, IF the server compared the host name in the SNI with the host name associated with the session in the cache. But I see that your proposal definitely gives precedence to the SNI. This is quite different than Mick's answer. From Pasi.Eronen@nokia.com Fri Oct 30 01:01:49 2009 Return-Path: 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 952553A69D9 for ; Fri, 30 Oct 2009 01:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 rx858bSuhLnS for ; Fri, 30 Oct 2009 01:01:48 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C94423A67B1 for ; Fri, 30 Oct 2009 01:01:48 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9U81TUg017104 for ; Fri, 30 Oct 2009 03:02:05 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:01:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:01:53 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 30 Oct 2009 09:01:52 +0100 From: To: Date: Fri, 30 Oct 2009 09:01:52 +0100 Thread-Topic: Re: I-D ACTION:draft-ietf-tls-rfc4366-bis-06.txt Thread-Index: AcpZNz1MHf3gk5dkSR+gfaTHIGgEWg== Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F6F456B@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 08:01:53.0607 (UTC) FILETIME=[3E420D70:01CA5937] X-Nokia-AV: Clean Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc4366-bis-06.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 08:01:49 -0000 FYI: version -06 includes the text we converged on about server_name: "Since it is possible for a client to present a different server_name in the application protocol, application server implementations that rely upon these names being the same MUST check to make sure the client did not present a different name in the application protocol." And couple of other changes: - In Section 3, it now says "However, for backward compatibility, all future NameTypes MUST begin with a 16-bit length field." (to address issue #102). - Section 4 adds text about record_overflow alert vs. DTLS. - Section 1 restores the text we used to have in RFC 4366 about session resumption. I think these are all fine, and I've placed this on the agenda of the November 19 IESG telechat. Best regards, Pasi=20 From Martin.Rex@sap.com Fri Oct 30 08:04:20 2009 Return-Path: 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 EE0E13A692D for ; Fri, 30 Oct 2009 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 D-EjQA5M7XDj for ; Fri, 30 Oct 2009 08:04:20 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B620A3A68C1 for ; Fri, 30 Oct 2009 08:04:19 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UF4Ww3014332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 16:04:32 +0100 (MET) From: Martin Rex Message-Id: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 30 Oct 2009 16:04:31 +0100 (MET) In-Reply-To: <4AEA7117.7050309@bolyard.me> from "Nelson B Bolyard" at Oct 29, 9 09:52:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: Alexei.Volkov@sun.com, tls@ietf.org Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 15:04:21 -0000 Nelson B Bolyard wrote: > > On 2009-10-29 16:26 PDT, Martin Rex wrote: > > Nelson B Bolyard wrote: > >> There's another issue that arises with both the SNI extension and a single > >> session ID space for the entire physical server. Which takes precedence? If the SNI made a difference in the server credential when the session was originally created, then the SNI MUST make the same difference for resume. The a requirement for consistency and reproducable behaviour. If the SNI did not make a difference when the cached session was originally created (e.g. the server doesn't support SNI), then it does not need to make a difference on resume. > >> > >> Consider this scenario: > >> Physical host has two virtual hosts, A and B. > >> First handshake: > >> client sends SNI with host name A, empty session ID. > >> server does full handshake, session ID 1. > >> Second handshake (renegotiation): > >> client sends SNI with host name B and session ID 1, > > > > That client is obviously broken. > > Perhaps, but the question is what does the server do about it? Compensate for the broken client and perform a full SSL handshake. A broken client is no excuse for inconsistent or non-predictable server behaviour. Since most real server limit the size of their session cache, you will, depending on the load of the server, not be able to predict at what point the server will have purged the cached session from his cache and will have to perform a full TLS handshake. If that full handshake will result in a TLS session with substantially different characteristics, or even with a completely different server credential, then the server behaviour will effectively become inconsistent and non-predictable if the server agrees to resume sessions that substantially differ from other session characteristics specified in the ClientHello. A server implementation that will behave inconsistent and non-predictable is always a bad idea. It does not matter that the spec fails to discourage or prohibit such a behaviour. It remains a pretty a bad idea and a sign of a broken server even when the spec does something stupid like recommending such inconsistent and non-predictable behaviour. > > >> Session ID 1 implicitly identifies host A. > >> > >> The server could > >> A) Honor the session ID and ignore the SNI. > >> B) Compare the host name in the SNI with the host name for session ID 1, > >> observe the mismatch, and do a new FULL handshake for host B. > >> C) Compare the host name in the SNI with the host name for session ID 1, > >> observe the mismatch, and return a fatal error alert. > > > > If the server supports virtual hosting through SNI, > > that's a given for this exercise > > > it should look up the session ID of the client only in the session cache > > associated with the hostname A. > > And it should choose hostname A because why? Remember that in the above > example, the SNI bears host name B. Sorry for my mistake. A session resume request with SNI B should be looked up in the session cache associated with SNI B, of course. (if the server supports SNI). > > > If a TLS session resume proposal with [an] SNI for B arrives, > > there will be no cached session with that session ID in the > > TLS session cache tied to credential for A, so it must result > > in a full TLS handshake. > > So, you're proposing that the server should look in the SNI first to see > which host name is there, and use that info to decide which virtual host's > server session cache to examine for the numbered session? Correct. > In other words, > each virtual host has its own separate session cache with fully overlapping > spaces of session ID numbers, disambiguated by the SNI host name, yes? > In this model, an SNI would be absolutely required to resume a session that > had been established with an SNI, yes? Correct. > > > A server that has different credentials for A and B (and would > > use them based on SNI > > The whole point of SNI is to have different credentials for different > virtual hosts. If you don't have different credentials for different > virtual hosts, (e.g. if you have a single certificate for all your > virtual hosts) then you don't need SNI. If a server supports SNI, but shares a single credential for several (or all) virtual hosts, then there would be no consistency or non-predictability problem if the server shared the TLS session caches in the same fashion. In my architecture, the SSL session cache of the server is tied to the server credential. If the architecture permits updating the server credentials while the server is running under full load, then you really want to be able to flush exactly and efficiently the cached TLS sessions related to that specific previous credential and leave the rest of the cached TLS sessions assiciated with other, still unchanged credentials, untouched. -Martin From mike-list@pobox.com Fri Oct 30 09:19:22 2009 Return-Path: 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 96D6E3A682B for ; Fri, 30 Oct 2009 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] 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 cRE4bo-bbJhG for ; Fri, 30 Oct 2009 09:19:21 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 6BD8F3A682A for ; Fri, 30 Oct 2009 09:19:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9C2C16D1A7 for ; Fri, 30 Oct 2009 12:19:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=W8rzr5j6HrUa 60DQh5wEmr2nIrE=; b=XlUioTFtlLnQjWXBLxGWn5CkCmfpC+aZrgelHdSjZ1yC yWDUx24tYplFHDX3knC4s0BjLgS1DBViS1WGJglZiBet5SLogdo1Ea3sx3toiUIf 9hXLQ63uISeRITSI6JvdbyJyMK+9XsKXYEuCFhbotVv298wwiwa/JOQPuzjaCBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Pm+hKM 3zT1cRSq7e1MRojARo2j0zFxexneQpmP14SXrkL0NzSOX46QSANJ6DTtX9s1hk5Q 1+YQa7opPkvaVHeXcxfBccJW0YXFp4m836qQduoXXLAtR3LdofGKzDOoZaYW2dOG r0dh5X/SRNHVE/sztjc3ltFtvDt0BHFTu2qlM= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 993816D1A6 for ; Fri, 30 Oct 2009 12:19:34 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 21B396D1A5 for ; Fri, 30 Oct 2009 12:19:33 -0400 (EDT) Message-ID: <4AEB126F.2090105@pobox.com> Date: Fri, 30 Oct 2009 09:21:03 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AEA6D5B.8060704@bolyard.me> In-Reply-To: <4AEA6D5B.8060704@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 030E2608-C570-11DE-AED6-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS Server Name Indication extension) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:19:22 -0000 Here's a possible reason for a client to include multiple domain names in the SNI. Suppose a user enters "foo.edu" into their browser. The browser may decide to send the two names "foo.edu" and also "www.foo.edu" to the server in an attempt to connect on the first try, rather than get rejected on the first connection and have the overhead of retrying. Even if you disagree that that is a possible scenario, if you want to restrict what you can do with a protocol there should be a good reason to do it. Either it must present a security issue, or it must cause undue burden on implementers for no benefit. I don't see how it is a security issue for the server to look up more than one name, and there is no burden in adding a simple loop to look up those names sequentially. In fact, you already need the loop to skip any name types you don't recognize, so the issue is whether you put a break statement in your loop or not. Mike Nelson B Bolyard wrote: > On 2009-10-28 17:04 PDT, Michael Gray wrote: >> wrote: >> >>> Consider this scenario: >>> Physical host has two virtual hosts, A and B. >>> First handshake: >>> client sends SNI with host name A, empty session ID. >>> server does full handshake, session ID 1. >>> Second handshake (renegotiation): >>> client sends SNI with host name B and session ID 1, >>> >>> Session ID 1 implicitly identifies host A. >>> >>> The server could >>> A) Honor the session ID and ignore the SNI. >>> B) Compare the host name in the SNI with the host name for session ID 1, >>> observe the mismatch, and do a new FULL handshake for host B. >>> C) Compare the host name in the SNI with the host name for session ID 1, >>> observe the mismatch, and return a fatal error alert. >>> >>> RFC 5246 seems to suggest choice A. It says: >>> >>> 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. >>> >>> But I tend to lean towards choice B myself. >>> >>> What do other SNI server implementations do in this case? >> A for IBM native SSL. The Client SNI data is only processed if the session >> can NOT be resumed. >> >> Also as an answer to the previous question; we only consider that the >> Client has sent a single name in Client SNI request. > > Thanks, Mick, for those concise answers. Sadly, I don't sense that we > have a consensus from among the responses yet, except on the point that > the SNI client hello should only contain one name of each type. > > I think that interoperability demands that we standardize these answers. > > I predict that we'll end up with these below(which I think match yours) > but I fear that existing implementations differ from these a fair bit. > > - Only one name per type is allowed and used in the client hello SNI. > > - The session ID space covers all the sessions for the entire physical host > including all the virtual hosts, so by itself, the session ID contains all > the information necessary to determine which virtual host uses the session > with that ID. It is not necessary to consult the SNI host name to know > which virtual host's session cache to examine to find the session ID. > > - The SNI extension is ignored if the session can be resumed based on the > session ID, and no matching/checking is done to ensure that the SNI host > name matches the name in the resumed session, when the session is resumed. > >> Also on previous note 'because they don't want to send the client >> cert over the wire in the clear" >> >> For what reason would you require a client cert or a host name or a host >> certificate to be not treated as public information? > > I don't know. I work on NSS, an open source TLS library that is used in > lots of applications and is discussed in an open mailing list and newsgroup > (mozilla.dev.tech.crypto). One of the application developers who uses NSS > has this issue, but I don't know why. I'd guess it's the usual extreme > security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :) > >> Mick Gray >> IBM From mike-list@pobox.com Fri Oct 30 10:09:03 2009 Return-Path: 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 884743A6AA7 for ; Fri, 30 Oct 2009 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 aXjQQhWF5324 for ; Fri, 30 Oct 2009 10:09:02 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 3D01C3A6A5C for ; Fri, 30 Oct 2009 10:09:02 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EBE176D677 for ; Fri, 30 Oct 2009 13:09:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=o4fdzTKc8tt0 CkoGwfoz6+bx8Ew=; b=TGRRK/ZEI9kyq8dNC8orgbyZlEZXAdH/OXE+iPQyDwtm 29OdZQ8Fmt+6PnhIron80/ypQaq2RKP7hec5YIPTLY73RXJCip60O7B6CX6TPLav rZyq+smieHpUYxKpAfIZZW4swsXsOPXUXTBO3FzAUSdgakGr3clVmXX7cYdu9XA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Dzl4ul KdpFvuNgFzU13sSSZh+bveKVqohVX8rfk3nZ3QMZcRuX9H4V4RMOUNxqQpDydmcc uXtpQRxiRloMrNnRO0ZKBfEaBmth/jtQ5kQxhVr/hi4YTCNXyLnozrXsHOFye0wH Y57IXUfLlSGpGZ2pdYYQuQ1/VATjjNUMmbVyQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E80F76D676 for ; Fri, 30 Oct 2009 13:09:18 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 86F5A6D670 for ; Fri, 30 Oct 2009 13:09:13 -0400 (EDT) Message-ID: <4AEB1E13.4010002@pobox.com> Date: Fri, 30 Oct 2009 10:10:43 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AE880CA.3060902@bolyard.me> In-Reply-To: <4AE880CA.3060902@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F5DA22AA-C576-11DE-9136-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS Server Name Indication extension) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:09:03 -0000 The only thing you can count on when resuming a session is the session ID. If you have more than one session cache, then you need to be able to determine solely from the session ID which session cache contains the session. I do this by structuring the 32 bytes of the session ID into a 6-byte cache ID, a 10-byte counter, and 16 bytes of random noise. The cache ID makes it easy to determine which cache to look in when trying to locate a session; the counter guarantees uniqueness of session IDs (the upper 5 bytes are initialized with the creation time); and the random component makes it unlikely for an attacker to guess a valid session ID randomly. My implementation allows virtual hosts to have their own session cache or to share their cache with any number of other hosts. Since session IDs are unique, the benefit to sharing is to share configuration parameters. You can specify a limit to the total number of cached sessions and the expiration time on a per-cache basis. Mike Nelson B Bolyard wrote: > On 2009-10-27 23:54 PDT, Peter Gutmann wrote: >> Nelson B Bolyard writes: >> >>> I eagerly await your answers and comments. >> OK, I'll bite: >> >>> Q1) A client hello's SNI extension is defined such that it may contain >>> multiple names. >> Intuitively I would say option (a) is the right one, if you're expecting >> to connect to a.foo.com then it doesn't seem to make much sense to say >> you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and >> phishme.com. I'm sure someone can dream up some bizarre corner case >> where you could in theory possibly somehow maybe do this, but in the >> interests of implementation sanity I'd say you're only allowed one name. > > I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache > only honors the first host name in the client hello SNI extension, and > will send an unrecognized_name alert if that first name is unrecognized. > > I'm quite willing to follow that example and let that become the de facto > standard. I just wish the RFC was clear about it, and wonder why the RFC > even allows multiple names to be sent. > >>> Q2) if multiple non-synonymous names are included, is the server free >>> to pick any one that it wants? >> This one is resolved by the solution for Q1 above. >> >>> Q3) Consider the "renegotiation" case, where a client and server >>> negotiate an initial SSL handshake ("in the clear") and then negotiate >>> a second handshake over the encrypted channel established by the first >>> handshake. >> I'd say it's not permitted, it's still the same server and (again) all >> you're going to do is create confusion if you allow new SNI's to be >> inserted at this point. This answers all the subquestions in one. > > Well, consider that there are people who don't want to do client > authentication in the initial handshake because they don't want to send the > client cert over the wire in the clear. Perhaps they also don't want to > send the virtual host name in the clear, or receive the cert for the > intended virtual host in the clear. So, one could imagine that they do > an initial handshake without any SNI, then a subsequent renegotiation > with SNI. > > I'm not advocating that. I'm merely suggesting that forbidding SNI in > renegotiation might be seen as unnecessarily restrictive in some applications. > >> Q4 and 5 get a bit complicated, I'd need to hear a bit more about the >> circumstances where this might occur... > > I received some other email that suggests that my use of the word "scope" > rather than "space" may have made the question unclear, so let me try to > reword Q4 here. > > In the context of a physical server acting as multiple virtual server, > is the space of session IDs coming from that server a single space that > encompasses all the sessions for all the virtual servers served by that > physical server? Or does each virtual server have its own separate space? > > If each virtual server has its own separate session ID space, then when > attempting to "resume" or "restart" a TLS session, the client hello MUST > bear an SNI extension to inform the physical server which virtual server's > session ID space contains the given session ID, and each virtual server > potentially has its own separate session store/cache. > > OTOH, if there is a single session ID space for the entire physical server > covering all the virtual servers, then each cached session must record and > identify the virtual server with which it is associated. > > I'm just wondering which way is the right way to implement session cache > lookup in an SNI environment. From Martin.Rex@sap.com Fri Oct 30 11:17:42 2009 Return-Path: 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 8812E3A68AA for ; Fri, 30 Oct 2009 11:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 ZsnHxUCrCzpq for ; Fri, 30 Oct 2009 11:17:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 7D0DF3A6767 for ; Fri, 30 Oct 2009 11:17:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n9UIHvsJ012845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 19:17:57 +0100 (MET) From: Martin Rex Message-Id: <200910301817.n9UIHuZX020355@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 30 Oct 2009 19:17:56 +0100 (MET) In-Reply-To: <4AEB126F.2090105@pobox.com> from "Michael D'Errico" at Oct 30, 9 09:21:03 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] Multiple domain names in SNI (was Questions about TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:17:42 -0000 Michael D'Errico wrote: > > Here's a possible reason for a client to include multiple domain > names in the SNI. Suppose a user enters "foo.edu" into their > browser. The browser may decide to send the two names "foo.edu" > and also "www.foo.edu" to the server in an attempt to connect on > the first try, rather than get rejected on the first connection > and have the overhead of retrying. I'm sorry, I don't understand you scenario. Current implementations of TCP can have only two communication peers, not three and the TLS handshake works also only with two participants, server and client. The client MUST know which of the hostnames was used to open a particular network connection, so there is NO situation where more than one name should go into SNI here. -Martin From mike-list@pobox.com Fri Oct 30 11:29:24 2009 Return-Path: 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 66F883A6841 for ; Fri, 30 Oct 2009 11:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 36lPyLC3O20M for ; Fri, 30 Oct 2009 11:29:23 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 2E6033A6808 for ; Fri, 30 Oct 2009 11:29:23 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E57A28CABE for ; Fri, 30 Oct 2009 14:29:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=tgj7jPvNOka2 KRlTaz3mV+FacRs=; b=NMbg+IcyTJSM/MqB4s611G7djAtj/YyI1TP9b20Hc6bJ qSUEwNAocZiH1TyvAavARXRH1kwTDuWnvnXdybjfZ1r8Tn3zxbDUWdp8ftco7VSr PMy5aGXGkuF5I1hZatMUmpwzs/Po466vLqW+GzsgCoeCtJolnQo5SpVMDWzduhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=KwGp3+ MQ1fDqO9ZOiD820B42nJ/G3a7TXdQvbb97iZgQkT9tPFdfHWdPOtP35HRF2LgFGl WGhM2P0XnmTPA71wAIkOFSruh3xILPpWqYyNOM0q+FZHwJGa2csN+SLMeTaLgNXB L/DNtA2gEP6D44NWtU66kPEtoGHEMo2vLARxs= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E1EB88CABD for ; Fri, 30 Oct 2009 14:29:39 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9807E8CABC for ; Fri, 30 Oct 2009 14:29:35 -0400 (EDT) Message-ID: <4AEB30E9.8080603@pobox.com> Date: Fri, 30 Oct 2009 11:31:05 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <4AE880CA.3060902@bolyard.me> In-Reply-To: <4AE880CA.3060902@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2F5D96AA-C582-11DE-87CF-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Renegotiation with SNI after initial connection without SNI (was Questions about TLS Server Name Indication extension) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:29:24 -0000 The desire seems to be to have a way to first negotiate a secure channel to a machine, then to perform the intended handshake over this secure channel to keep the real handshake private. This could be done by adding a new NameType to the SNI extension. This new NameType would let the server know that it is performing a handshake merely to create a private channel over a public medium like the Internet. Immediately following the negotiation of this secure connection, the client would be required to perform the intended handshake. Note that the session ID specified by the client in the 2nd handshake would be empty. The "name" associated with this name type would most likely be empty (two zero bytes indicating zero length) since it means "the host I'm connected to". Both handshakes could return non-empty session IDs. Upon resuming the first session, the client would be at the point where it needed to renegotiate the session using a valid SNI and empty session ID. Resuming the second session would get them all the way to the virtual host. There are obvious security issues -- a client would need to make sure that the host it connected to was friendly so when it performs the real handshake, the information doesn't end up in the wrong hands. Or perhaps the security offered is similar to the use of TLS for SMTP where clients don't necessarily care who the server is, just that their message is encrypted when sent over the Internet; they rely on the DNS to make sure they're connected to a real MX for the recipient. Mike >>> Q3) Consider the "renegotiation" case, where a client and server >>> negotiate an initial SSL handshake ("in the clear") and then negotiate >>> a second handshake over the encrypted channel established by the first >>> handshake. >> I'd say it's not permitted, it's still the same server and (again) all >> you're going to do is create confusion if you allow new SNI's to be >> inserted at this point. This answers all the subquestions in one. > > Well, consider that there are people who don't want to do client > authentication in the initial handshake because they don't want to send the > client cert over the wire in the clear. Perhaps they also don't want to > send the virtual host name in the clear, or receive the cert for the > intended virtual host in the clear. So, one could imagine that they do > an initial handshake without any SNI, then a subsequent renegotiation > with SNI. From mike-list@pobox.com Fri Oct 30 11:38:11 2009 Return-Path: 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 776543A68DD for ; Fri, 30 Oct 2009 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 MmZmnIvJgGF9 for ; Fri, 30 Oct 2009 11:38:10 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 714643A6767 for ; Fri, 30 Oct 2009 11:38:09 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7D00A8CB91 for ; Fri, 30 Oct 2009 14:38:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=bGa+UiQ7fr0G pHHPBj9pnAH30/M=; b=aqm/I1VTetID7XHQPV2UtNovs8GqMpTH+pvo8Xf7Ao1x CtkDqfw/6wn20uCrX/zxK2Bm6R/HPoL6cLkjMEu+hvw93cAQ5oXI8mPqP5ftjzHS 5qnFh98y4rM9LkqLN6lnaduJhbVGS/awLP8L9N8oVeGcp1LAABsuPBdUBbld6Vc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=gsdHan bl8bLMGBQTndSFiKnwfuuAcGiEYnIcsklAsye4uSkOJfUpPPvXYRsC6G9kBnCj7D KzmjQ8GDmlBQsp6x2mP73yxHNlViXql8uP9L4l41QOYdZas35gEgOyVbTC52/a66 rSzT+/eB/CHH5wSBSyqAEcrl83HPeAj+MdgnY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 756588CB90 for ; Fri, 30 Oct 2009 14:38:26 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0E9848CB8F for ; Fri, 30 Oct 2009 14:38:25 -0400 (EDT) Message-ID: <4AEB32FC.8030100@pobox.com> Date: Fri, 30 Oct 2009 11:39:56 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910301817.n9UIHuZX020355@fs4113.wdf.sap.corp> In-Reply-To: <200910301817.n9UIHuZX020355@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 69381002-C583-11DE-8B18-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:38:11 -0000 They could share IP addresses. But the point is that you and I don't know for certain that there is no possible requirement for a client to send multiple hostnames, so imposing a limitation of only one hostname could preclude some future application from being able to use TLS (without modifications or private agreement). If it was hard to implement checking for a match in a list, I'd agree with you, but literally it is a simple while loop that calls your lookup function for each name in the SNI extension. Mike Martin Rex wrote: > Michael D'Errico wrote: >> Here's a possible reason for a client to include multiple domain >> names in the SNI. Suppose a user enters "foo.edu" into their >> browser. The browser may decide to send the two names "foo.edu" >> and also "www.foo.edu" to the server in an attempt to connect on >> the first try, rather than get rejected on the first connection >> and have the overhead of retrying. > > I'm sorry, I don't understand you scenario. > > Current implementations of TCP can have only two communication peers, > not three and the TLS handshake works also only with two participants, > server and client. > > The client MUST know which of the hostnames was used to open a particular > network connection, so there is NO situation where more than one name > should go into SNI here. > > -Martin From Martin.Rex@sap.com Fri Oct 30 11:52:29 2009 Return-Path: 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 13A563A6823 for ; Fri, 30 Oct 2009 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 FeKNWBlj9v1P for ; Fri, 30 Oct 2009 11:52:28 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E2A8F3A6767 for ; Fri, 30 Oct 2009 11:52:27 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UIqhDu008344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 19:52:43 +0100 (MET) From: Martin Rex Message-Id: <200910301852.n9UIqgev022554@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 30 Oct 2009 19:52:42 +0100 (MET) In-Reply-To: <4AEB1E13.4010002@pobox.com> from "Michael D'Errico" at Oct 30, 9 10:10:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Multiple Session Caches and SNI (was Questions about TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:52:29 -0000 Michael D'Errico wrote: > > The only thing you can count on when resuming a session is the session > ID. If you have more than one session cache, then you need to be able > to determine solely from the session ID which session cache contains > the session. I do this by structuring the 32 bytes of the session ID > into a 6-byte cache ID, a 10-byte counter, and 16 bytes of random noise. > > The cache ID makes it easy to determine which cache to look in when > trying to locate a session; the counter guarantees uniqueness of session > IDs (the upper 5 bytes are initialized with the creation time); and the > random component makes it unlikely for an attacker to guess a valid > session ID randomly. > > My implementation allows virtual hosts to have their own session cache > or to share their cache with any number of other hosts. Since session > IDs are unique, the benefit to sharing is to share configuration > parameters. You can specify a limit to the total number of cached > sessions and the expiration time on a per-cache basis. It's perfectly sensible that TLS server composes the TLS session IDs in a fashion that facilitates cache management and session lookup (including guaranteed uniqueness when creating new session IDs, obviating cache collision checks). Keep in mind, that the security of the sessions do not come from uniqueness and non-predictability of the session ID, however. SSL session IDs travel in the clear in the client hello and their purpose in life is to be re-used "replayed" frequently. :) In addition to cache management aspects, the TLS server should keep robustness in mind. e.g. robustness against TLS clients with a broken client-side TLS session cache management that will recklessly propose a TLS session resume for a session (ID) originally established with Mars to just about every earthling they're asked to connect to later on. And before a TLS server checks for existence of a TLS session, whose session ID is proposed in a ClientHello, it should determine wheter it would be willing to establish a new session through a full handshake based on the other information in the ClientHello and under what conditions it would do so. If the TLS server finds a TLS session with the proposed session ID in his cache, it should then use the results from the previous determination of the ClientHello parameters whether it is OK to attempt to resume the cached session, or whether it is advised to perform a full SSL handshake, because of a significant mismatch of the newly determine session characteristics from those of the cachend session identified by the client-proposed Session ID. This is a simple and straightforward robustness principle leading to consistent behaviour, that will save implementors and consumers of the technology a lot of time and headaches. -Martin From Martin.Rex@sap.com Fri Oct 30 12:14:19 2009 Return-Path: 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 108AB28B23E for ; Fri, 30 Oct 2009 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 rFU9xuHOBDei for ; Fri, 30 Oct 2009 12:14:18 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 021003A6AB1 for ; Fri, 30 Oct 2009 12:14:17 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UJEXL8002770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 20:14:34 +0100 (MET) From: Martin Rex Message-Id: <200910301914.n9UJEXD9023612@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 30 Oct 2009 20:14:33 +0100 (MET) In-Reply-To: <4AEB32FC.8030100@pobox.com> from "Michael D'Errico" at Oct 30, 9 11:39:56 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:14:19 -0000 Michael D'Errico wrote: > > They could share IP addresses. You mean that you client performs DNS-lookup for both names, determines that they point to the same IP-Address and then decides to address a single request for both? How many HTTP Host: Header fields is your client going to send, and is the semantics for the server defined what to do with multiple Host: header fields. We also didn't cover this in the revised text that urges an application to cross-check SNI vs. Host: Header fields. JUST DON'T DO IT. > > But the point is that you and I don't know for certain that there is > no possible requirement for a client to send multiple hostnames, so > imposing a limitation of only one hostname could preclude some future > application from being able to use TLS (without modifications or > private agreement). We should not try to fix a problem before we even know that there is a problem (with limiting ServerNameList to unique members of each NameType). > > If it was hard to implement checking for a match in a list, I'd agree > with you, but literally it is a simple while loop that calls your > lookup function for each name in the SNI extension. Past experience regularly demonstrates that this is going to result in broken implementations. Take the list of client ciphersuites in the ClientHello message for example. It was hard to believe for me that there would be broken SSL/TLS Servers out there that used the ordering/preference of the ciphersuites in the ClientHello instead of the preference of the server to pick a common ciphersuites. At a minimum, the precendence of the servers preferences over the clients should be configurable with the servers preferenca/configuration being the default. A hardcoded "clients list takes precedence" or a default for this indicates that the implementor didn't think about the security implications and may have been to easily misguided by obviously suboptimal wording in the specification. Every spec contains errors and suboptimal or misleading wording. It's _MUCH_ easier to realize the problems when trying to implement a spec. So when implementing specs, it is very important to use common sense when reading it and strive for consistent and predictable behaviour. -Martin From nelson@bolyard.me Fri Oct 30 12:24:02 2009 Return-Path: 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 80F383A68D5 for ; Fri, 30 Oct 2009 12:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599] 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 AiHswK0WPmRF for ; Fri, 30 Oct 2009 12:24:01 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 8A83F3A6990 for ; Fri, 30 Oct 2009 12:24:01 -0700 (PDT) Received: (qmail 7582 invoked from network); 30 Oct 2009 19:24:18 -0000 Received: from unknown (67.188.69.99) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 30 Oct 2009 19:24:18 -0000 Message-ID: <4AEB3D5B.1070406@bolyard.me> Date: Fri, 30 Oct 2009 12:24:11 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: tls@ietf.org References: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp> In-Reply-To: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:24:02 -0000 On 2009-10-30 08:04 PDT, Martin Rex wrote: > Nelson B Bolyard wrote: >> On 2009-10-29 16:26 PDT, Martin Rex wrote: >>> Nelson B Bolyard wrote: >>>> There's another issue that arises with both the SNI extension and a single >>>> session ID space for the entire physical server. Which takes precedence? > > If the SNI made a difference in the server credential when the session > was originally created, then the SNI MUST make the same difference > for resume. The a requirement for consistency and reproducable behaviour. > > If the SNI did not make a difference when the cached session was > originally created (e.g. the server doesn't support SNI), then it > does not need to make a difference on resume. RFC 5246 says: 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. You're saying that SNI is not like "Most current TLS extensions" in that when an older session is resumed, the server DOES process this extension, and its behavior is NOT different during session resumption than during session initiation. I think that's a legitimate and self-consistent proposal, one of several that I could envision, which is why I raised this subject. But as we've seen in this thread, others (e.g. IBM) clearly have implemented a very different model. For the sake of interoperability, I think we need to define a single standard definition to which we all adhere. > >>>> Consider this scenario: >>>> Physical host has two virtual hosts, A and B. >>>> First handshake: >>>> client sends SNI with host name A, empty session ID. >>>> server does full handshake, session ID 1. >>>> Second handshake (renegotiation): >>>> client sends SNI with host name B and session ID 1, >>> That client is obviously broken. >> Perhaps, but the question is what does the server do about it? > > Compensate for the broken client and perform a full SSL handshake. IBM's answer was: ignore the SNI and resume session ID 1 with host A, which seems to be what RFC 5246 says TLS should do for _most_ TLS hello extensions. But I agree that we _could_ *define* SNI to not be like _most_ TLS hello extensions, if we choose. > A broken client is no excuse for inconsistent or non-predictable > server behaviour. I agree that, ONCE we all agree that your definition is the right one, then we agree that the above behavior is that of a broken client. OTOH, if we end up agreeing that IBM's answer is the right one, then I don't think we necessarily agree that a client behaving as described above is necessarily broken. Regards, /Nelson From mike-list@pobox.com Fri Oct 30 12:24:30 2009 Return-Path: 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 0520C3A6842 for ; Fri, 30 Oct 2009 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 E16OdjEZZtsz for ; Fri, 30 Oct 2009 12:24:29 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D7F1D3A67A3 for ; Fri, 30 Oct 2009 12:24:28 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id ACA176D412 for ; Fri, 30 Oct 2009 15:24:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=4cZilZth/RZ8 xh1HfVC9O4ungQs=; b=VX+dzoQzhVwZ0sQiRj8w5Ffbr3KcAVHj+WUgpCQKU5PY e9b4cLtKLr6MFcTIKv0bmg57gUxNBazURNnG2krSub9dxmfXuYkJQEQF3n6SxkH7 JaHls0t9+ZVH3T9OwfxyJ7AtiJwGu/pUaN5hvVZDbuSJ9qsNl2N+To9Y2XiV+po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=H7+Flp 1JjECeZ7FEhB8mEWv0L8Q5GsJSS8BP8ZqQK9gqfxyEVJSG0Vk7abVOFO3Gv/U9Pl oHY7In7qA9kWaIaDjRCRO2l89Aj3q7zfgp5C0NfJB/Q71dMyQfQf9qBlz0DFk4B5 ddkzmwWqk26m/700/nnIpHUOAazWnHEzcszwQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A95276D411 for ; Fri, 30 Oct 2009 15:24:45 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 350006D410 for ; Fri, 30 Oct 2009 15:24:45 -0400 (EDT) Message-ID: <4AEB3DD7.9080501@pobox.com> Date: Fri, 30 Oct 2009 12:26:15 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910301852.n9UIqgev022554@fs4113.wdf.sap.corp> In-Reply-To: <200910301852.n9UIqgev022554@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E1C4645C-C589-11DE-9E98-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Multiple Session Caches and SNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:24:30 -0000 > In addition to cache management aspects, the TLS server should keep > robustness in mind. e.g. robustness against TLS clients with > a broken client-side TLS session cache management that will > recklessly propose a TLS session resume for a session (ID) originally > established with Mars to just about every earthling they're asked > to connect to later on. Section 7.2.2 of RFC 5246 concerning Error Alerts handles this. If a connection terminates with a fatal alert, the session associated with that connection MUST NOT be resumed. So perhaps a server will try to resume the session once, but it will delete it from its cache when the handshake fails. Other servers that don't recognize the session ID will perform full handshakes. > And before a TLS server checks for existence of a TLS session, > whose session ID is proposed in a ClientHello, it should determine > wheter it would be willing to establish a new session through > a full handshake based on the other information in the ClientHello > and under what conditions it would do so. I do it the other way around -- after retrieving the session, checks are made to make sure the cipher suite and compression algorithm are listed in the ClientHello. This is mandatory according to section 7.4.1.2. The only other check I currently have is for the age of the session to make sure it is fresh enough. > If the TLS server finds a TLS session with the proposed session ID > in his cache, it should then use the results from the previous > determination of the ClientHello parameters whether it is OK to > attempt to resume the cached session, or whether it is advised > to perform a full SSL handshake, because of a significant mismatch > of the newly determine session characteristics from those > of the cachend session identified by the client-proposed Session ID. RFC 4366 states: - 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. Mike > This is a simple and straightforward robustness principle leading > to consistent behaviour, that will save implementors and consumers > of the technology a lot of time and headaches. > > > -Martin From mickgray@au1.ibm.com Fri Oct 30 12:32:24 2009 Return-Path: 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 85C8C3A686B for ; Fri, 30 Oct 2009 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9DlN4OCAX9a5 for ; Fri, 30 Oct 2009 12:32:22 -0700 (PDT) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by core3.amsl.com (Postfix) with ESMTP id 887ED3A67A3 for ; Fri, 30 Oct 2009 12:32:22 -0700 (PDT) Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id n9UJWcY4027779 for ; Sat, 31 Oct 2009 06:32:38 +1100 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9UJWbmQ1495272 for ; Sat, 31 Oct 2009 06:32:37 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9UJWbTS003466 for ; Sat, 31 Oct 2009 06:32:37 +1100 Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av02.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9UJWbea003463; Sat, 31 Oct 2009 06:32:37 +1100 In-Reply-To: <4AEB126F.2090105@pobox.com> To: "Michael D'Errico" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Michael Gray Date: Sat, 31 Oct 2009 05:32:23 +1000 X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 31/10/2009 06:39:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS Server Name Indication extension) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:32:24 -0000 "Michael D'Errico" wrote: > Here's a possible reason for a client to include multiple domain > names in the SNI. Suppose a user enters "foo.edu" into their > browser. The browser may decide to send the two names "foo.edu" > and also "www.foo.edu" to the server in an attempt to connect on > the first try, rather than get rejected on the first connection > and have the overhead of retrying. That is an interesting use case scenario. Have you actually observed a browser doing this? I have not so far. What sort of risk is there for the Client if the browser starts doing this sort of thing? On the other hand I recommend to our consuming products to have the flexibility at the Server side i.e. the Server is configured with multiple Server Names that point to a common certificate which supports multiple DNS names. For example say a Server is hosting 123.com, abc.com and xyz.com, then the TLS Server can be configured with: abc.com > abc.com_certificate www.abc.com > abc.com_certificate 123.com > 123.com_certificate www.123.com > 123.com_certificate ... You can imagine a number of variations on the above when you see some Server Certificates with a large number of SAN DNS names. The TLS Server then selects the correct certificate based on the TLS Client SNI request. The Application Server itself then asks the TLS Server what certificate was used to establish the connection so that the Application Server can select the correct data base etc etc. > Even if you disagree that that is a possible scenario, if you want > to restrict what you can do with a protocol there should be a good > reason to do it. Either it must present a security issue, or it > must cause undue burden on implementers for no benefit. I don't > see how it is a security issue for the server to look up more than > one name, and there is no burden in adding a simple loop to look > up those names sequentially. In fact, you already need the loop > to skip any name types you don't recognize, so the issue is whether > you put a break statement in your loop or not. > If there is consensus on this and no security risk then we would implement it as an option as I do not see that the RFC prevents this. Mick Gray IBM > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mike-list@pobox.com Fri Oct 30 12:50:01 2009 Return-Path: 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 3464B3A68AE for ; Fri, 30 Oct 2009 12:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 JwXHhH4y3NRl for ; Fri, 30 Oct 2009 12:50:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D56E53A68B7 for ; Fri, 30 Oct 2009 12:49:58 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3A3EC6D685 for ; Fri, 30 Oct 2009 15:50:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=2nLJacFXPzbC jzbze0kywFG17Ik=; b=tL3alV5AkSuy/E6u+8PR7rYIDqJ3orSroaFfADbXJ9Eh W2Fe8Aq9VRCaPumor+63vFpckdmmhT7mVAYer5F8KV1BMvKtWvOcMSWEQNi2NxbY DvC7UFWRwyQ/xuXhEa0RKredeKABuSO/yE6GyD/dGYRIY9EnRJS9z6bwYHjIsc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=PlihUW mYkg3pyy6vUB/h3rJecDx8neZyNFax4OvAv+9t0SD86Q7qxJhBXKPlNiWBDhHzMF meP83z/aoY13Z4cZYipq2qD3akih8qpzXUdvXQ5mixzumsiTEhjXx9E0r5tZkvBj ew4WPC4Lfz6J7NMhfKjt9HXSHX6D8yXlJwf1w= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 371086D684 for ; Fri, 30 Oct 2009 15:50:15 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9FC0A6D682 for ; Fri, 30 Oct 2009 15:50:14 -0400 (EDT) Message-ID: <4AEB43D1.5070800@pobox.com> Date: Fri, 30 Oct 2009 12:51:45 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910301914.n9UJEXD9023612@fs4113.wdf.sap.corp> In-Reply-To: <200910301914.n9UJEXD9023612@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 71704AFA-C58D-11DE-8925-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Multiple domain names in SNI (was Questions about TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:50:01 -0000 >> They could share IP addresses. > > You mean that you client performs DNS-lookup for both names, > determines that they point to the same IP-Address and then > decides to address a single request for both? > > How many HTTP Host: Header fields is your client going to send, > and is the semantics for the server defined what to do with > multiple Host: header fields. We also didn't cover this in > the revised text that urges an application to cross-check > SNI vs. Host: Header fields. > > JUST DON'T DO IT. I was merely trying to come up with a possible scenario in which you could hypothetically send two hostnames in the SNI extension, not that I actually do that. The important point is the following: >> But the point is that you and I don't know for certain that there is >> no possible requirement for a client to send multiple hostnames, so >> imposing a limitation of only one hostname could preclude some future >> application from being able to use TLS (without modifications or >> private agreement). > > We should not try to fix a problem before we even know that there is a > problem (with limiting ServerNameList to unique members of each NameType). People ARE trying to "fix" the extension by imposing a restriction that is not currently present in the spec. I maintain that there is no savings of effort implementing the spec as is, versus imposing a one-name-per-name-type restriction. You still need to iterate through the list (since you may not recognize the first name type), and look up the names of types you do recognize. To implement one-name-per-name-type, you need to add a "break" statement to stop processing the list once a lookup failure occurs. So the code to implement one-name-per-name type is actually MORE WORK than doing it the way the spec is written today. Oh, and you now have a bug since you broke out of the loop before finding all the other name types in the list. >> If it was hard to implement checking for a match in a list, I'd agree >> with you, but literally it is a simple while loop that calls your >> lookup function for each name in the SNI extension. > > Past experience regularly demonstrates that this is going to result > in broken implementations. > > Take the list of client ciphersuites in the ClientHello message for > example. It was hard to believe for me that there would be broken > SSL/TLS Servers out there that used the ordering/preference of > the ciphersuites in the ClientHello instead of the preference > of the server to pick a common ciphersuites. At a minimum, > the precendence of the servers preferences over the clients > should be configurable with the servers preferenca/configuration > being the default. The client ultimately overrules the server since it only has to offer those cipher suites it is willing to negotiate. The server can choose whichever it likes, but only from the list it receives. A client can send a single cipher suite if it desires only that one. > A hardcoded "clients list takes precedence" or a default for this > indicates that the implementor didn't think about the security > implications and may have been to easily misguided by obviously > suboptimal wording in the specification. I don't see any issue other than performance. A server will simply refuse to negotiate any cipher suite that doesn't match its security needs. If it negotiates RSA_WITH_RC4_MD5 and that doesn't provide enough security, then whoever configured the list of allowable cipher suites can only blame themselves, not the client. > Every spec contains errors and suboptimal or misleading wording. > It's _MUCH_ easier to realize the problems when trying to implement > a spec. So when implementing specs, it is very important to > use common sense when reading it and strive for consistent > and predictable behaviour. I've implemented lots of specs, so I agree with you that clarity is important. It is just as easy to say, "Note: there may be any number of names of a particular name type" as it is to say, "There MUST NOT be more than one name of a particular name type." If the more restrictive version led to considerably simpler coding, I'd readily agree with changing it, but as I've pointed out above, there is no simplification of the code. Mike From mike-list@pobox.com Fri Oct 30 13:23:55 2009 Return-Path: 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 521413A6867 for ; Fri, 30 Oct 2009 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] 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 2gYAwv1N3qaz for ; Fri, 30 Oct 2009 13:23:54 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 38BA43A67BD for ; Fri, 30 Oct 2009 13:23:52 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D8DAC8B56A for ; Fri, 30 Oct 2009 16:24:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GVG8wtCNx83J 7xy/qGwXaibN294=; b=vTphFiN1RmQ3OO+8ANwGbQJOlHV/5pyTkdNVtXVawnfa B088d1tZue4xMH+biKjJfLuKqbrVdSKWwW8LT1sZ3Z70a9LSYuuu5cGWCELEc6wA v6C2NWwe33OZ3VdNXsl1FHrzuUaAX2PVm6gRO4/Ql6bhYWpjnpgJNBluqfwmAQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=nM6vk/ MXBFWHa0y2X1wxMmA7x9q3rcFjUe0idgF2cjKEXw+zFSjI1CxgcW3MEFeOYMFgCj D+2DuMhsCjGc2p8X6yAGUrkdvxzOvdv+HcHWgQdbcqItTy8SFeZM5YtsSl7Wb79I zWmtiqQ3cAYsCnM5KcLqNUHxGp9QaAHYcY5hM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D4EC68B569 for ; Fri, 30 Oct 2009 16:24:09 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 518A28B568 for ; Fri, 30 Oct 2009 16:24:08 -0400 (EDT) Message-ID: <4AEB4BC4.7030007@pobox.com> Date: Fri, 30 Oct 2009 13:25:40 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910301504.n9UF4Vi1009766@fs4113.wdf.sap.corp> <4AEB3D5B.1070406@bolyard.me> In-Reply-To: <4AEB3D5B.1070406@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2E2CD4DE-C592-11DE-AE2D-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Requiring SNI for resumption (was Questions about TLS Server Name Indication extension) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:23:55 -0000 I think that it would be a good change to require a client to include the same SNI extension when resuming a session. The complexity of my code to find a session among multiple session caches is far greater than it would have been if I could have relied on the hostname from SNI. RFC 4366 currently disallows using SNI to resume: - 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. I'd be in favor of changing RFC 4366 to mandate providing the same SNI when resuming a session, if nothing will break because of it. Mike Nelson B Bolyard wrote: > On 2009-10-30 08:04 PDT, Martin Rex wrote: >> Nelson B Bolyard wrote: >>> On 2009-10-29 16:26 PDT, Martin Rex wrote: >>>> Nelson B Bolyard wrote: >>>>> There's another issue that arises with both the SNI extension and a single >>>>> session ID space for the entire physical server. Which takes precedence? >> If the SNI made a difference in the server credential when the session >> was originally created, then the SNI MUST make the same difference >> for resume. The a requirement for consistency and reproducable behaviour. >> >> If the SNI did not make a difference when the cached session was >> originally created (e.g. the server doesn't support SNI), then it >> does not need to make a difference on resume. > > RFC 5246 says: > > 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. > > You're saying that SNI is not like "Most current TLS extensions" in that > when an older session is resumed, the server DOES process this extension, > and its behavior is NOT different during session resumption than during > session initiation. > > I think that's a legitimate and self-consistent proposal, one of several > that I could envision, which is why I raised this subject. But as we've > seen in this thread, others (e.g. IBM) clearly have implemented a very > different model. > > For the sake of interoperability, I think we need to define a single > standard definition to which we all adhere. > >>>>> Consider this scenario: >>>>> Physical host has two virtual hosts, A and B. >>>>> First handshake: >>>>> client sends SNI with host name A, empty session ID. >>>>> server does full handshake, session ID 1. >>>>> Second handshake (renegotiation): >>>>> client sends SNI with host name B and session ID 1, >>>> That client is obviously broken. >>> Perhaps, but the question is what does the server do about it? >> Compensate for the broken client and perform a full SSL handshake. > > IBM's answer was: ignore the SNI and resume session ID 1 with host A, > which seems to be what RFC 5246 says TLS should do for _most_ TLS hello > extensions. But I agree that we _could_ *define* SNI to not be like > _most_ TLS hello extensions, if we choose. > >> A broken client is no excuse for inconsistent or non-predictable >> server behaviour. > > I agree that, ONCE we all agree that your definition is the right one, > then we agree that the above behavior is that of a broken client. > OTOH, if we end up agreeing that IBM's answer is the right one, then > I don't think we necessarily agree that a client behaving as described above > is necessarily broken. > > Regards, > /Nelson > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Martin.Rex@sap.com Fri Oct 30 13:31:04 2009 Return-Path: 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 7D7233A67BD for ; Fri, 30 Oct 2009 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 wkKEHUD31dda for ; Fri, 30 Oct 2009 13:31:02 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C9BB23A6867 for ; Fri, 30 Oct 2009 13:31:01 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n9UKVHVA025735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 21:31:17 +0100 (MET) From: Martin Rex Message-Id: <200910302031.n9UKVG2k027818@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Fri, 30 Oct 2009 21:31:16 +0100 (MET) In-Reply-To: <4AEB3DD7.9080501@pobox.com> from "Michael D'Errico" at Oct 30, 9 12:26:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Multiple Session Caches and SNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:31:04 -0000 Michael D'Errico wrote: > > > In addition to cache management aspects, the TLS server should keep > > robustness in mind. e.g. robustness against TLS clients with > > a broken client-side TLS session cache management that will > > recklessly propose a TLS session resume for a session (ID) originally > > established with Mars to just about every earthling they're asked > > to connect to later on. > > Section 7.2.2 of RFC 5246 concerning Error Alerts handles this. If > a connection terminates with a fatal alert, the session associated > with that connection MUST NOT be resumed. So perhaps a server will > try to resume the session once, but it will delete it from its cache > when the handshake fails. Other servers that don't recognize the > session ID will perform full handshakes. That appears to strict to me. I would make the server delete a session from his cache when an attempted resume results in a failure. I can not currently think of an error (i.e. fatal alert) after a mutual successful finished message verification that should cause the server to flush the affected ssl session from his session cache. > > > And before a TLS server checks for existence of a TLS session, > > whose session ID is proposed in a ClientHello, it should determine > > wheter it would be willing to establish a new session through > > a full handshake based on the other information in the ClientHello > > and under what conditions it would do so. > > I do it the other way around -- after retrieving the session, checks > are made to make sure the cipher suite and compression algorithm are > listed in the ClientHello. This is mandatory according to section > 7.4.1.2. The only other check I currently have is for the age of the > session to make sure it is fresh enough. An actual implementation will probably involve certains decisions based more on personal taste than factual requirements. The most important issue is consitent and predictable/deterministic behaviour of the server, even when broken clients are involved. > > > If the TLS server finds a TLS session with the proposed session ID > > in his cache, it should then use the results from the previous > > determination of the ClientHello parameters whether it is OK to > > attempt to resume the cached session, or whether it is advised > > to perform a full SSL handshake, because of a significant mismatch > > of the newly determine session characteristics from those > > of the cachend session identified by the client-proposed Session ID. > > RFC 4366 states: > > - 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. Correct, but you should not read it backwards. If the server agrees to resume (for whatever reason), the other accompanying information in the ClientHello should NOT be used to modify that cached session. Does rfc-4366 say anywhere that the server _must_not_ involve the parameters and extensions present in a ClientHello in his decision to resume or not resume a cached SSL session when the client includes a session id in the ClientHello handshake message? -Martin From Nicolas.Williams@sun.com Fri Oct 30 15:48:02 2009 Return-Path: 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 F411B3A68B1; Fri, 30 Oct 2009 15:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, 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 tfIUfHhXy2Bj; Fri, 30 Oct 2009 15:48:01 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 0973B3A6843; Fri, 30 Oct 2009 15:48:00 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9UMmFPs019151; Fri, 30 Oct 2009 22:48:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9UMmFvG011443; Fri, 30 Oct 2009 16:48:15 -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 n9UMamJo004135; Fri, 30 Oct 2009 17:36:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9UMam8c004134; Fri, 30 Oct 2009 17:36:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Oct 2009 17:36:48 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091030223647.GO1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 22:48:02 -0000 I spoke at length with Larry. His concern is that the word "conenction" might be taken to mean "TCP connection" or "connection for the transport below TLS". Clearly it is not reasonable to expect to extract the TLS channel binding from the "connection for the transport below TLS"! Larry's proposal to say "session" was only to make that confusion go away, but that proposal is very difficult to implement (as I described separately already). Larry has indicated to me (and I expect will indicate on the list in reply to this email) that he will be happy if we simply clarify that "TLS connection" refers to the TLS state, NOT to the transport below. Unfortunately RFC5246 does not seem to have a term by which to refer the "TLS connection" unambiguously: "connection" is defined in the glossary (page 80) to mean that which Larry doesn't want (underlying transport), but then, in section 6.1 RFC5246 quite clearly uses the word "connection" to refer to "TLS connection", not to the underlying transport. Thus this is a simple matter of wordsmithing. Another problem that Larry has is that in his implementation what I call a "TLS connection" is called a "security context", and if the application re-handshakes (e.g., to authenticate a user) then the result is a second security context -- we need to be extra clear that it's the client Finished message from the _first_ "security context" that we're after. My proposal, then, is this: OLD: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). NEW: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the application's TLS connection. NOTES: a) If a session is resumed, the client's TLS Finished message from the session resumption handshake is to be used; b) If a client does multiple TLS handshakes in sequence, each protected by the previous one, then the client's TLS Finished message from the first/outermost TLS connection is to be used; c) By "TLS connection" we refer to the TLS connection state, not to any notion of connection of any underlying transport protocols (such as TCP, UDP, SCTP, etcetera). I'm not sure that we can make it any clearer. Larry, please review. Martin, please review. Nico -- From mike-list@pobox.com Fri Oct 30 17:38:32 2009 Return-Path: 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 BB4B53A6935 for ; Fri, 30 Oct 2009 17:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 GekFJI-VIVKZ for ; Fri, 30 Oct 2009 17:38:31 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 9F9BD3A672E for ; Fri, 30 Oct 2009 17:38:30 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9CA256D0B6 for ; Fri, 30 Oct 2009 20:38:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=bcIE1LdGB66v jRQcMiuAtyci5uA=; b=Oc2qm1V+1kfHV+rCVHMYB2zU9Y2SREENsnaiplugcaxj dSNdCjuZTivJgcFk5ATMs2MrpL1pTogzeb+Ayombk+u77XQM5y6DUDq+3oeqcNNJ PfLm7xHuPHJHU+2FyaXpbIku6vuR+DOYe0ZESVGPpig+1DggOukQDbDlDEwq1Vo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Om64Li qOk8d2gcn7LDipHvrHwVPhsSLx2XCcLa5+G6pQwCiEdfBBZm0JAcX3NIAzVowFSd 1h8Swqnh5jEBqozmTlNBIMQHoRtumIlZV8JDlIqY4+0e+DCkocGR7UNLwywWIBrQ 6ouVm2E7+EEHjdwmpOowXTRjojuzfklRBp6YE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 98E1A6D0B5 for ; Fri, 30 Oct 2009 20:38:47 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 2B05B6D0B4 for ; Fri, 30 Oct 2009 20:38:47 -0400 (EDT) Message-ID: <4AEB8773.5040204@pobox.com> Date: Fri, 30 Oct 2009 17:40:19 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910302031.n9UKVG2k027818@fs4113.wdf.sap.corp> In-Reply-To: <200910302031.n9UKVG2k027818@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C06F9642-C5B5-11DE-ABB2-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Multiple Session Caches and SNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 00:38:32 -0000 >> Section 7.2.2 of RFC 5246 concerning Error Alerts handles this. If >> a connection terminates with a fatal alert, the session associated >> with that connection MUST NOT be resumed. So perhaps a server will >> try to resume the session once, but it will delete it from its cache >> when the handshake fails. Other servers that don't recognize the >> session ID will perform full handshakes. > > That appears to strict to me. I would make the server delete > a session from his cache when an attempted resume results in a failure. > I can not currently think of an error (i.e. fatal alert) after a > mutual successful finished message verification that should cause > the server to flush the affected ssl session from his session cache. The main one is a BAD_RECORD_MAC alert if decryption fails, padding is wrong, the MACs don't match. The record version could be wrong; the record could be greater than 2^14 bytes. None of these things should happen under normal circumstances, so you have to assume an attack is underway. >>> If the TLS server finds a TLS session with the proposed session ID >>> in his cache, it should then use the results from the previous >>> determination of the ClientHello parameters whether it is OK to >>> attempt to resume the cached session, or whether it is advised >>> to perform a full SSL handshake, because of a significant mismatch >>> of the newly determine session characteristics from those >>> of the cachend session identified by the client-proposed Session ID. >> RFC 4366 states: >> >> - 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. > > Correct, but you should not read it backwards. > > If the server agrees to resume (for whatever reason), the other > accompanying information in the ClientHello should NOT be used to > modify that cached session. > > Does rfc-4366 say anywhere that the server _must_not_ involve the > parameters and extensions present in a ClientHello in his decision > to resume or not resume a cached SSL session when the client > includes a session id in the ClientHello handshake message? Aside from what I quoted, I don't believe so. The server can decide not to resume a session for whatever reason it wants. In fact there is no requirement to support session caching at all. What the text means is that IF the server agrees to resume the session, the resumed session will have the same features as the original according to the extensions in the original handshake, regardless of the extensions in the ClientHello for the resumed session. Mike From mike-list@pobox.com Fri Oct 30 19:11:09 2009 Return-Path: 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 33FC33A67FC for ; Fri, 30 Oct 2009 19:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 WYC3m+FtD9kU for ; Fri, 30 Oct 2009 19:11:08 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 0ED943A6781 for ; Fri, 30 Oct 2009 19:11:06 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 208B28CE46 for ; Fri, 30 Oct 2009 22:11:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=DAxeoGLIGLqn 5kXW1/QrPUBk/6k=; b=JWZW/nLspNFJ0OIS/kXFdE72IBFq+A4tASQmz/UJr634 9GjrHiH33a92wz8iTmt7d7rZeETFaRv4QHRnigrfeVMdh30Y+WSZL9E3OOYwDQLm BHLOzqRH8CEGaq70yb7R1TJF2Adh/IuzVJTt1X8mlibDA0vxnnn9h5CgyMupjp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=UZZELD 3hx7fanKt8eBzZEHlC/bhCUS+HCKnuAl8kDAG8iAofLTd7mY6ljxvE8EEPHFolDb 8F6RVegbisuSUoXRBRu1P5Zk/TOw0fqKU0/DfTnrumOp+ypQ9v68mqi7uQxSsYAX OcjEJnnqaLlEHAkrVaSF/zE/A5IPp8nTFF430= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1B6828CE45 for ; Fri, 30 Oct 2009 22:11:24 -0400 (EDT) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 537E18CE44 for ; Fri, 30 Oct 2009 22:11:22 -0400 (EDT) Message-ID: <4AEB9D27.5090203@pobox.com> Date: Fri, 30 Oct 2009 19:12:55 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: tls@ietf.org References: <200910292246.n9TMk6sZ014367@fs4113.wdf.sap.corp> In-Reply-To: <200910292246.n9TMk6sZ014367@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: B059DA80-C5C2-11DE-ABBD-A67CBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com Subject: Re: [TLS] Questions about TLS Server Name Indication extension 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 02:11:09 -0000 > Btw. RFC-4366 doesn't say what to do about IP-Addresses. Since > rfc-2818.txt indicates that Server certificates may contain > SANs of the type iPAddress, sending IP-Addresses also via SNI > sounds like the way to go when e.g. the Browser tries to open > a URL with only an IPaddress instead of a hostname.. RFC 4366 says on page 10: Literal IPv4 and IPv6 addresses are not permitted in "HostName". A new name type would need to be created for IP addresses. > There are much more interesting questions: when a TLS session in the > cache was originally established with protocol version 0x03,0x01 > what about a client resume proposal with a protocol version 0x03.0x00 > or 0x03,0x02 in the client_version of the ClientHello? I looked at my code and found that when a cached session is retrieved, the ClientHello.version of the new handshake is compared to the negotiated version of the original session. If they are not equal, then a full handshake is performed. But that brings up a subtle point. What if the client originally connected offering a higher version than I support? When it tries to resume a session, should it use the version it originally sent in the ClientHello, or the lower version that was negotiated? I would think that the client should be allowed to specify the same version number it originally connected with. I searched through RFC 5246 but could not find a discussion of this. Did I miss it? What do others think should happen? > A TLS client should *NEVER* make assumptions about independent > servers (i.e. independent ServerNames) sharing a TLS session cache. > Sensible TLS clients should NOT assume that TLS servers on different > ports of the same host share the TLS session cache (or credentials > or any other TLS characteristics, for that matter). A somewhat related problem I encountered is that Google's search engine assumes that the content at http port 80 is the same as the content at https port 443. I was having trouble getting my site indexed because the text/plain page from my TLS test server was being treated as my home page by Google's bot, i.e. with no links. I don't know if other search engines exhibit this behavior. Mike From n.mavrogiannopoulos@gmail.com Sat Oct 31 01:07:15 2009 Return-Path: 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 CC6773A635F for ; Sat, 31 Oct 2009 01:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 KWPdqZn5o2SJ for ; Sat, 31 Oct 2009 01:07:15 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CAA193A6824 for ; Sat, 31 Oct 2009 01:07:14 -0700 (PDT) Received: by bwz23 with SMTP id 23so4408927bwz.29 for ; Sat, 31 Oct 2009 01:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=6/1Lg7/2F+lGmfuflCqM/Tf6qhaLAQt3c6kwRLbuGgE=; b=Y5cRXE+mv33BsYug60Z65M0lit2iIHymAtB2ypPo6C7l6ddaIIBWIQSAtIPzsoWZx1 ifdksLGjW+EOh7JUe0EJ+3vXSvcD/eS4ginqllbotKh5aMXWgXuB8wnGb1wuudPQ9mCY nv/rq0tw1xcOyC8HRrtV0Z1Ga6NjW/w+pmIJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=bHDgFtCXSYcHfEpXhZGCHbX4HZga2ktuk4NRSdn3EkgDtJhYjYmEOKzCArfo446AJb 0T1/21aI8ltX5KtllzmgUTy4oY8qIALL13Y6hobIuAdWZ/MjR0mY9raF856/k4yedtOk f8XjxVg6RtsUpKE7kvuPPIycWOprFhfBcxgRQ= Received: by 10.204.0.69 with SMTP id 5mr1861417bka.173.1256976450370; Sat, 31 Oct 2009 01:07:30 -0700 (PDT) Received: from ?10.100.1.196? (adsl6-155.ath.forthnet.gr [77.49.197.155]) by mx.google.com with ESMTPS id y15sm1728934fkd.28.2009.10.31.01.07.28 (version=SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 01:07:29 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4AEBF03E.1040003@gnutls.org> Date: Sat, 31 Oct 2009 10:07:26 +0200 From: Nikos Mavrogiannopoulos User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael D'Errico References: <4AE9F0DE.7060903@pobox.com> In-Reply-To: <4AE9F0DE.7060903@pobox.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Server Signature Algorithms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 08:07:15 -0000 Michael D'Errico wrote: > There are now at least 3 instances where a TLS client needs to know the > server's list of supported signature algorithms: > > 1. to compute the signature for the CertificateVerify message > 2. to compute the hash of the handshake messages in (1) without > having to hold onto all of the messages > 3. to compute hashes for the proposed cached information extension > > Rather than duplicate the list for each of these and any future needs, > it makes sense to send it once in a server hello extension. > > The simplest option would be to use the existing signature algorithms > extension and make it symmetrical. But if there is a deployed client > out there that aborts a connection if it receives a signature algorithm > extension, then a secondary option would be to create a new server- > signature-algorithms extension which is identical in structure to the > existing extension. I also agree, this is an elegant solution to solve the fact that the client needs to store all handshake messages in memory. regards, Nikos