From Nicolas.Williams@sun.com Wed Apr 1 16:08:17 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D264A3A67EA for ; Wed, 1 Apr 2009 16:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.754 X-Spam-Level: X-Spam-Status: No, score=-5.754 tagged_above=-999 required=5 tests=[AWL=0.292, 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 CuqfRTlZ2wzo for ; Wed, 1 Apr 2009 16:08:16 -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 741463A67D4 for ; Wed, 1 Apr 2009 16:08:11 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31N9CaB013269 for ; Wed, 1 Apr 2009 23:09:12 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 n31N9B0D016087 for ; Wed, 1 Apr 2009 17:09:11 -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 n31MqOkJ001680; Wed, 1 Apr 2009 17:52:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n31MqK7n001679; Wed, 1 Apr 2009 17:52:20 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 1 Apr 2009 17:52:20 -0500 From: Nicolas Williams To: Dave Cridland Message-ID: <20090401225220.GA1500@Sun.COM> References: <5690.1237934257.266964@peirce.dave.cridland.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5690.1237934257.266964@peirce.dave.cridland.net> User-Agent: Mutt/1.5.7i Cc: Mark Novak , channel-binding@ietf.org, Stefan Santesson , Larry Zhu , ietf-sasl@imc.org, Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:08:17 -0000 On Tue, Mar 24, 2009 at 10:37:37PM +0000, Dave Cridland wrote: > Having carefully examined the tls-server-end-point channel binding, > I've a bit of a concern. We should probably be having this discussion on the channel-binding@ietf.org list (cc'ed). Also cc'ed are folks who participated in the registration of tls-server-end-point. > One of the sticking points of the tls-unique channel binding is how > easy it is to get at the data - OpenSSL provides an API, however it's > often not exposed to language bindings such as Python, etc, and other > TLS implementations may not provide it at all. File bugs against them! If you have a list of such bindings I'll volunteer to help file and track these bugs. > I can't find any way of getting at the on-wire representation of the > server's certificate, and I can't immediately find a way of > discovering which hash algorithm to use, either, in the vast majority > of bindings. > > So rather than expect all TLS implementations and bindings to change, > I'd like to propose an alternate binding, for use where the server's > certificate is an X.509v3 one. > > Specifically, I'd like to use a fixed hash algorithm over the > DER-encoded form of the certificate - I'll call this > "tls-x509-end-point" Questions: 1) Do many/most/all TLS implementations output the DER-encoded form of the server cert? Which ones do/don't? 2) Is the cert used on the wire generally NOT DER-encoded? If so, how hard would it be to change this? (e.g., re-encode the cert and restart apps?) Notes: - By hard-coding a hash function we'd lose hash agility. Hash agility is one of the features of the registered tls-server-end-point channel binding type. OTOH, as you note, for SCRAM this is solved by the existing SCRAM hash agility approach (add a new mech). - We can't really negotiate which type of channel binding to use. It's relatively easy to choose between unique and server-end-point, but to choose between two types of server-end-point bindings is much harder (unless it's a choice made at specification time, in this case for SASL/SCRAM). Neither modifying tls-server-end-point nor introducing a different variant of it seem particularly appealing. The former may well be out of the barn's doors, which would leave us only with the latter choice (or fix the TLS frameworks :) > The DER form of the certificate is readily available through most > bindings, in many cases in a single call, and gives exactly > equivalent hash-input as the on-wire format, which is very likely > [but not mandated, as far as I can find] to be DER anyway. > > Fixing a hash algorithm simply makes this even easier - the current > channel binding uses SHA-256 as a "minimum hash", I'd prefer to use > SHA-1, as we're certain to have it for SCRAM. True. > Finally, I'd propose that SCRAM mandates support for the > 'tls-x509-end-point' channel binding for the applicable cases as a > reasonable fallback when support for the more flexible and > future-proof tls-server-end-point binding is not available. > > Now I'll wait to get shot down in flames. :-) No flames. I think we could do a channel binding type just for SCRAM (we did one just for TELNET, after all). But I think I'd want "DER" in the name, that and the hash function name too. Comments? > Dave. > -- > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Nico -- From simon@josefsson.org Thu Apr 2 01:26:34 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C5D3A68A7 for ; Thu, 2 Apr 2009 01:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 O82gYfk-iSHK for ; Thu, 2 Apr 2009 01:26: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 953993A6872 for ; Thu, 2 Apr 2009 01:26:32 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LpIGe-00042U-84; Thu, 02 Apr 2009 10:27:20 +0200 From: Simon Josefsson To: Nicolas Williams References: <5690.1237934257.266964@peirce.dave.cridland.net> <20090401225220.GA1500@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090402:ietf-sasl@imc.org::eTJ1T256XNHSrQUA:2HAR X-Hashcash: 1:22:090402:stefans@microsoft.com::H7J3RubcGK0IhSaa:H18 X-Hashcash: 1:22:090402:lzhu@windows.microsoft.com::3o1i4ht2Tj48+D49:33n4 X-Hashcash: 1:22:090402:channel-binding@ietf.org::1aosdI0tDFj8A6yo:4Qxf X-Hashcash: 1:22:090402:nicolas.williams@sun.com::K0dfax7O4ExmC9FW:510D X-Hashcash: 1:22:090402:hartmans-ietf@mit.edu::WFPg2QGFWLn50kbP:EX37 X-Hashcash: 1:22:090402:mark.novak@microsoft.com::iXqNGcKJoQx9xppR:GTrX X-Hashcash: 1:22:090402:dave@cridland.net::hr/q+nc/nYxr/BmC:WLk4 X-Hashcash: 1:22:090402:paulle@windows.microsoft.com::D9+T5KBa2jYtpUw3:V8w0 X-Hashcash: 1:22:090402:kdamour@microsoft.com::12iVMA0My1xh9Gf9:ch1C X-Hashcash: 1:22:090402:jaltman@secure-endpoints.com::+Pr6TrIz7JQECDJ6:sqnU Date: Thu, 02 Apr 2009 10:27:18 +0200 In-Reply-To: <20090401225220.GA1500@Sun.COM> (Nicolas Williams's message of "Wed, 1 Apr 2009 17:52:20 -0500") Message-ID: <87ljqjsbo9.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Larry Zhu , channel-binding@ietf.org, Stefan Santesson , Mark Novak , ietf-sasl@imc.org, Dave Cridland , Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 08:26:34 -0000 Nicolas Williams writes: >> Finally, I'd propose that SCRAM mandates support for the >> 'tls-x509-end-point' channel binding for the applicable cases as a >> reasonable fallback when support for the more flexible and >> future-proof tls-server-end-point binding is not available. >> >> Now I'll wait to get shot down in flames. :-) > > No flames. I think we could do a channel binding type just for SCRAM > (we did one just for TELNET, after all). But I think I'd want "DER" in > the name, that and the hash function name too. I don't think that will work -- TLS isn't just X.509. TLS supports OpenPGP server certs. Generally, TLS can support other forms of server authentication too. I don't want to see SCRAM require use of X.509 server certificates if we can avoid it. It seems simple to avoid that here: just request the necessary features from TLS stacks. If we don't do that now, we likely won't do it next time we need a channel binding for some application protocol, and then TLS interfaces will never have this feature. Nico volunteered to help with this for OpenSSL, and I can volunteer to do it for GnuTLS. We knew from the start that channel bindings would require changes to TLS stacks. The major native C libraries have already been adapted, I believe, so what remains are any language bindings. That seems like Just A Simple Matter Of Programming. The alternative is to make channel binding type negotiable, something I recall discussing at lengths earlier. Nothing came out of that, so RFC 5056 does not support any negotiation. I'm not sure how well it would work to add that feature for SCRAM? But it could be explored. /Simon From dave@cridland.net Thu Apr 2 04:31:29 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568CE3A694F for ; Thu, 2 Apr 2009 04:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 qg13w++kLMf2 for ; Thu, 2 Apr 2009 04:31:28 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id EBC693A6876 for ; Thu, 2 Apr 2009 04:31:27 -0700 (PDT) Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Thu, 2 Apr 2009 12:32:23 +0100 References: <5690.1237934257.266964@peirce.dave.cridland.net> <20090401225220.GA1500@Sun.COM> In-Reply-To: <20090401225220.GA1500@Sun.COM> MIME-Version: 1.0 Message-Id: <4871.1238671941.558047@puncture> Date: Thu, 02 Apr 2009 12:32:21 +0100 From: Dave Cridland To: Nicolas Williams Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Thu, 02 Apr 2009 04:47:13 -0700 Cc: Mark Novak , channel-binding@ietf.org, Stefan Santesson , Larry Zhu , ietf-sasl@imc.org, Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 11:31:29 -0000 On Wed Apr 1 23:52:20 2009, Nicolas Williams wrote: > 1) Do many/most/all TLS implementations output the DER-encoded form > of > the server cert? Which ones do/don't? > > Somewhere between many and most. I suspect all the low-level TLS stacks (OpenSSL etc) will do. It's the bindings and suchlike I'm more concerned with. In the bindings, however, it's pretty trivial to find a function which either hands back the DER form, or else hands back PEM (base64 of DER), which developers can also use. > 2) Is the cert used on the wire generally NOT DER-encoded? If so, > how > hard would it be to change this? (e.g., re-encode the cert and > restart apps?) > > I have absolutely no idea. If I could rely on the cert being DER on the wire, we could reduce this to implementation notes, aside from the hash issue. I have no idea how to extract that hash algorithm, currently, but I could probably figure that out eventually. If it turns out that tls-server-endpoint *can* be readily implemented at least for the common case of X.509 certificates, then I'd be very much happier with this outcome. > - By hard-coding a hash function we'd lose hash agility. Hash > agility > is one of the features of the registered tls-server-end-point > channel > binding type. OTOH, as you note, for SCRAM this is solved by the > existing SCRAM hash agility approach (add a new mech). > > Yes - it's not ideal, but I'm hoping that by the time hash agility becomes an issue, then we'll have support for the more generic form of the channel binding. > - We can't really negotiate which type of channel binding to use. > It's > relatively easy to choose between unique and server-end-point, > but to > choose between two types of server-end-point bindings is much > harder > (unless it's a choice made at specification time, in this case > for > SASL/SCRAM). > > But clients must stipulate which they have used. > Neither modifying tls-server-end-point nor introducing a > different > variant of it seem particularly appealing. The former may well > be > out of the barn's doors, which would leave us only with the > latter > choice (or fix the TLS frameworks :) I think tls-server-end-point is a fine binding. My problem is that it'll be years before it's available on many platforms, and I think we can provide more immediately implementable security than that. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From Pasi.Eronen@nokia.com Fri Apr 3 05:33:27 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F0D28C27D for ; Fri, 3 Apr 2009 05:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 3mnlifiAo+ws for ; Fri, 3 Apr 2009 05:33:27 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 57D3A28C272 for ; Fri, 3 Apr 2009 05:33:00 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n33CXfLq013384; Fri, 3 Apr 2009 15:33:56 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 15:33:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 15:33:48 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 3 Apr 2009 14:33:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Fri, 3 Apr 2009 14:33:47 +0200 From: To: , Date: Fri, 3 Apr 2009 14:33:47 +0200 Thread-Topic: TLS endpoint channel bindings in SCRAM Thread-Index: AcmzIVyLFrIwMFOjQXm6luyyF7ZehABNXNrQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F21CDF28@NOK-EUMSG-01.mgdnok.nokia.com> References: <5690.1237934257.266964@peirce.dave.cridland.net> <20090401225220.GA1500@Sun.COM> In-Reply-To: <20090401225220.GA1500@Sun.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: 03 Apr 2009 12:33:48.0305 (UTC) FILETIME=[6FD3E810:01C9B458] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 03 Apr 2009 08:02:32 -0700 Cc: Mark.Novak@microsoft.com, channel-binding@ietf.org, stefans@microsoft.com, lzhu@windows.microsoft.com, ietf-sasl@imc.org, paulle@windows.microsoft.com, kdamour@microsoft.com, jaltman@secure-endpoints.com, hartmans-ietf@mit.edu Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 12:33:28 -0000 Nicolas Williams wrote: > Questions: >=20 > 1) Do many/most/all TLS implementations output the DER-encoded form of > the server cert? Which ones do/don't? >=20 > 2) Is the cert used on the wire generally NOT DER-encoded? If so, how > hard would it be to change this? (e.g., re-encode the cert and > restart apps?) Although the TLS spec doesn't explicitly say this, the on-the-wire certificate is DER encoded. There's no field specifying what the encoding is, so if you attempt sending PER or XER, it simply won't work. Some implementations might accept some limited subset of BER (to work around CA bugs), but even in those cases, nobody's going to re-encode it to DER (most likely the CA calculated the signature over BER encoded version -- violating all possible standards -- and the API would return the octets sent on the wire). So I don't see any problem in using the tls-server-end-point channel binding... (and it seems it would work for OpenPGP, too) Best regards, Pasi= From Nicolas.Williams@sun.com Fri Apr 3 08:03:50 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF313A683F for ; Fri, 3 Apr 2009 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.248, 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 CiGrb5fSeAWO for ; Fri, 3 Apr 2009 08:03:49 -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 953183A68DF for ; Fri, 3 Apr 2009 08:03:45 -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 n33F4mjg025783 for ; Fri, 3 Apr 2009 15:04:48 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 n33F4lZX060615 for ; Fri, 3 Apr 2009 09:04:47 -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 n33Elwmt002627; Fri, 3 Apr 2009 09:47:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33Elqwb002626; Fri, 3 Apr 2009 09:47:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 09:47:52 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20090403144752.GT1500@Sun.COM> References: <5690.1237934257.266964@peirce.dave.cridland.net> <20090401225220.GA1500@Sun.COM> <808FD6E27AD4884E94820BC333B2DB7727F21CDF28@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F21CDF28@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.7i Cc: lzhu@windows.microsoft.com, channel-binding@ietf.org, stefans@microsoft.com, Mark.Novak@microsoft.com, ietf-sasl@imc.org, dave@cridland.net, paulle@windows.microsoft.com, kdamour@microsoft.com, jaltman@secure-endpoints.com, hartmans-ietf@mit.edu Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:03:50 -0000 On Fri, Apr 03, 2009 at 02:33:47PM +0200, Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: > > > Questions: > > > > 1) Do many/most/all TLS implementations output the DER-encoded form of > > the server cert? Which ones do/don't? > > > > 2) Is the cert used on the wire generally NOT DER-encoded? If so, how > > hard would it be to change this? (e.g., re-encode the cert and > > restart apps?) > > Although the TLS spec doesn't explicitly say this, the on-the-wire > certificate is DER encoded. There's no field specifying what the > encoding is, so if you attempt sending PER or XER, it simply won't > work. Right, I doubt anyone re-encodes certs in PER or XER :) It's BER that one should worry about. > Some implementations might accept some limited subset of BER (to > work around CA bugs), but even in those cases, nobody's going to > re-encode it to DER (most likely the CA calculated the signature over > BER encoded version -- violating all possible standards -- and the > API would return the octets sent on the wire). OK, thanks. > So I don't see any problem in using the tls-server-end-point channel > binding... Excellent. Thanks! > (and it seems it would work for OpenPGP, too) It could be made to, but tls-server-end-point refers to the first cert in the 'certificate_list' field of the server's Certificate message -- there's no such field in the OpenPGP case. It'd be a trivial updat to tls-server-end-point to allow the use of a server's OpenPGP cert though. Nico -- From Nicolas.Williams@sun.com Fri Apr 3 08:41:45 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815DC3A6D54 for ; Fri, 3 Apr 2009 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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 eCQ4y8sk3lye for ; Fri, 3 Apr 2009 08:41:44 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 5898D3A67FB for ; Fri, 3 Apr 2009 08:41:23 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n33FgQvb001757 for ; Fri, 3 Apr 2009 15:42:26 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 n33FgPg7027407 for ; Fri, 3 Apr 2009 09:42:25 -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 n33FPao5002676; Fri, 3 Apr 2009 10:25:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33FPaLG002675; Fri, 3 Apr 2009 10:25:36 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 10:25:36 -0500 From: Nicolas Williams To: Dave Cridland Message-ID: <20090403152535.GY1500@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Cc: Mark Novak , channel-binding@ietf.org, Stefan Santesson , Larry Zhu , ietf-sasl@imc.org, Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:41:45 -0000 Dave Cridland wrote: > > - By hard-coding a hash function we'd lose hash agility. Hash > >agility is one of the features of the registered tls-server-end-point > >channel binding type. OTOH, as you note, for SCRAM this is solved by > >the existing SCRAM hash agility approach (add a new mech). > > > Yes - it's not ideal, but I'm hoping that by the time hash agility > becomes an issue, then we'll have support for the more generic form > of the channel binding. The lack of negotiability of which channel binding type to use makes this not a good answer (but see below). > > - We can't really negotiate which type of channel binding to use. > >It's relatively easy to choose between unique and server-end-point, > >but to choose between two types of server-end-point bindings is much > >harder (unless it's a choice made at specification time, in this case > >for SASL/SCRAM). > > > But clients must stipulate which they have used. That doesn't mean it's negotiable. GSS-API semantics do not allow the acceptor to find out what channel binding type the client used. We could put the channel binding type in the GS2 header -- that would solve that problem. But still, the server now has to support multiple channel binding types and now we need a way to advertise that to the client -- otherwise the client and server could disagree and fail to authenticate. > > Neither modifying tls-server-end-point nor introducing a > >different variant of it seem particularly appealing. The former may > >well be out of the barn's doors, which would leave us only with the > >latter choice (or fix the TLS frameworks :) > > I think tls-server-end-point is a fine binding. > > My problem is that it'll be years before it's available on many > platforms, and I think we can provide more immediately implementable > security than that. Pasi's comment indicates that your premise for this thread is wrong. I don't know though. Can you comment on Pasi's comments? Are there any commonly used TLS implementations that encode the server cert differently on the wire than in their APIs for getting at the server cert? I seriously doubt that on the _client_ side, but also, I doubt it on the server side. Why would anyone want to write code to re-encode certs on the fly when that can be done once at configuration time, or never at all if the CA just does the right thing and issues a DER certificate. Also, even if there were implementations that re-encode non-DER certs into DER for that API, surely, surely one could re-encode the cert at configuration time so that it's in DER to begin with as far as the TLS implementation goes -- then there's no need to re-encode as re-encoding would be the identity function. Nico -- From dave@cridland.net Fri Apr 3 09:30:59 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063463A680D for ; Fri, 3 Apr 2009 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 gQwAG-7U9WCP for ; Fri, 3 Apr 2009 09:30:58 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id B0CAF3A679F for ; Fri, 3 Apr 2009 09:30:57 -0700 (PDT) Received: from puncture (turner.dave.cridland.net [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Fri, 3 Apr 2009 17:31:54 +0100 References: <20090403152535.GY1500@Sun.COM> In-Reply-To: <20090403152535.GY1500@Sun.COM> MIME-Version: 1.0 Message-Id: <15429.1238776301.804018@puncture> Date: Fri, 03 Apr 2009 17:31:41 +0100 From: Dave Cridland To: Nicolas Williams Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Cc: Mark Novak , channel-binding@ietf.org, Stefan Santesson , Larry Zhu , ietf-sasl@imc.org, Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:30:59 -0000 On Fri Apr 3 16:25:36 2009, Nicolas Williams wrote: > Pasi's comment indicates that your premise for this thread is wrong. I certainly hope so. Nothing would please me more than being wrong here. > I > don't know though. Can you comment on Pasi's comments? Are there > any > commonly used TLS implementations that encode the server cert > differently on the wire than in their APIs for getting at the server > cert? I have no idea at all, I'm sorry to say. It makes sense to me that X.509 certs, at least, would always be encoded in DER, since that's the form in which they're signed. That then reduces the problem of the existing channel binding to being figuring out which hash to use, and I strongly suspect that just using SHA-256 is sufficient for now. (it's unfortunate this is different to the hash algorithm we seem to have settled on for SCRAM, but it's far from a blocker, merely a mild inconvenience). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From Nicolas.Williams@sun.com Fri Apr 3 09:59:59 2009 Return-Path: X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3B33A6954 for ; Fri, 3 Apr 2009 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.247, 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 J1NlMxE8oMFq for ; Fri, 3 Apr 2009 09:59:59 -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 B58E13A694E for ; Fri, 3 Apr 2009 09:59:58 -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 n33H11NS002477 for ; Fri, 3 Apr 2009 17:01:01 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 n33H10Wu030768 for ; Fri, 3 Apr 2009 11:01:01 -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 n33GiBoj002950; Fri, 3 Apr 2009 11:44:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n33GiBRf002949; Fri, 3 Apr 2009 11:44:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 3 Apr 2009 11:44:11 -0500 From: Nicolas Williams To: Dave Cridland Message-ID: <20090403164411.GB1500@Sun.COM> References: <20090403152535.GY1500@Sun.COM> <15429.1238776301.804018@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15429.1238776301.804018@puncture> User-Agent: Mutt/1.5.7i Cc: Mark Novak , channel-binding@ietf.org, Stefan Santesson , Larry Zhu , ietf-sasl@imc.org, Paul Leach , Kevin Damour , Jeffrey Altman , Sam Hartman Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 16:59:59 -0000 On Fri, Apr 03, 2009 at 05:31:41PM +0100, Dave Cridland wrote: > On Fri Apr 3 16:25:36 2009, Nicolas Williams wrote: > > I > >don't know though. Can you comment on Pasi's comments? Are there > >any > >commonly used TLS implementations that encode the server cert > >differently on the wire than in their APIs for getting at the server > >cert? > > I have no idea at all, I'm sorry to say. It makes sense to me that > X.509 certs, at least, would always be encoded in DER, since that's > the form in which they're signed. Between this and my other comment I'm willing to close this as a non-issue. > That then reduces the problem of the existing channel binding to > being figuring out which hash to use, and I strongly suspect that > just using SHA-256 is sufficient for now. (it's unfortunate this is > different to the hash algorithm we seem to have settled on for SCRAM, > but it's far from a blocker, merely a mild inconvenience). Right, we chose SHA-256 for tls-server-end-point because it should future proof us for long enough that people will be able to implement a cert->hash API as described in tls-server-end-point. I think that's fine. We couldn't use SHA-1 because we're not using HMAC here, so there's no mitigation against SHA-1 breaks. SHA-256 implementations, including open source ones in various licenses, exist. So I'm going to consider this a non-issue also. Nico --