From tlr@w3.org Sun Mar 1 07:47:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CDB3A6B15 for ; Sun, 1 Mar 2009 07:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QSR1DLozTrV1 for ; Sun, 1 Mar 2009 07:47:13 -0800 (PST) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 6A2B53A6A4C for ; Sun, 1 Mar 2009 07:47:13 -0800 (PST) Received: from iCoaster.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8A9734EEBA; Sun, 1 Mar 2009 10:47:37 -0500 (EST) Received: from localhost ([127.0.0.1]) by iCoaster.does-not-exist.org with esmtp (Exim 4.66) (envelope-from ) id KFU3VD-000BTL-4N; Sun, 01 Mar 2009 09:47:37 -0600 Message-Id: <3462D904-6F07-4659-993C-54AB3B6DE9DC@w3.org> From: Thomas Roessler To: saag@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-85--82781022 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Mar 2009 09:47:36 -0600 References: <52EDBA7C-232C-47FF-B906-184206F8E312@nokia.com> X-Mailer: Apple Mail (2.930.3) Cc: Frederick Hirsch Subject: [saag] Fwd: FPWD Transition Announcement - XML Security Specifications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 15:47:14 -0000 --Apple-Mail-85--82781022 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI, W3C has published initial working drafts for a number of documents related to XML Signature and Encryption: 1. Incremental revisions of XML Signature and Encryption. These revisions focus on adding markup and algorithm support for EC DSA (at the same time addressing some known issues with RFC 4050). We would appreciate early comment from the IETF community. 2. Markup for derived keys. This document, too, is one that could use review from the IETF community. 3. A requirements and design document for a possible version 2 of XML Signature. This document focuses on attempting to devise a simpler transform model for XML Signature, in order to remove some of the complexity of the current specification. The full list of drafts released is in the message quoted below. If you have any questions, please feel free to contact Frederick or me. Thanks, -- Thomas Roessler, W3C Begin forwarded message: > From: Frederick Hirsch > Date: 26 February 2009 12:09:26 GMT-06:00 > To: chairs@w3.org, XMLSec WG Public List > Cc: Frederick Hirsch > Subject: FPWD Transition Announcement - XML Security Specifications > Archived-At: > > > This is a First Public Working Draft transition announcement from > the XML Security WG. > > The following seven specifications have been published as First > Public Working Drafts and the WG requests feedback on these > documents. Comment may be sent to the list public-xmlsec-comments@w3.org > . If possible please indicate the document in the subject line. > > (1) XML Signature Syntax and Processing Version 1.1 > http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ > > (2) XML Encryption Syntax and Processing Version 1.1 > http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/ > > (3) XML Signature Transform Simplification: Requirements and Design > http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ > > (4) XML Security Use Cases and Requirements > http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/ > > (5) XML Security Derived Keys > http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/ > > (6) XML Signature Properties > http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/ > > (7) XML Security Algorithm Cross-Reference > http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/ > > These were included in the following transition request: > http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html > > The Working Group has also published an updated working draft of > Best Practices: > > (8) XML Signature Best Practices W3C Working Draft 26 February 2009 > http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/ > > The Working Group would appreciate review of these documents, with > special attention to the algorithms listed in XML Signature 1.1 and > XML Encryption 1.1, the proposed 2.0 changes in the Transform > Simplification document and Use Cases and Requirements. Again, > comment may be sent to the list public-xmlsec-comments@w3.org . > > Thank you > > regards, Frederick > > Frederick Hirsch, Nokia > Chair XML Security WG > > > --Apple-Mail-85--82781022 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable FYI, W3C has published initial = working drafts for a number of documents related to XML Signature and = Encryption:

1. Incremental revisions of XML Signature = and Encryption.  These revisions focus on adding markup and = algorithm support for EC DSA (at the same time addressing some known = issues with RFC 4050).  We would appreciate early comment from the = IETF community.

2. Markup for derived keys. =  This document, too, is one that could use review from the IETF = community.

3. A requirements and design = document for a possible version 2 of XML Signature.  This document = focuses on attempting to devise a simpler transform model for XML = Signature, in order to remove some of the complexity of the current = specification.

The full list of drafts released = is in the message quoted below.

If you have any = questions, please feel free to contact Frederick or = me.

Thanks,
--
Thomas Roessler, W3C  <tlr@w3.org>





=

Begin forwarded message:

From: = Frederick Hirsch <frederick.hirsch@nokia.com&= gt;
Date: 26 February 2009 12:09:26 = GMT-06:00
To: chairs@w3.org, XMLSec WG Public List = <public-xmlsec@w3.org>
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com&= gt;
Subject: FPWD Transition Announcement -  XML Security = Specifications

=

  
(1) XML Signature = Syntax and Processing Version 1.1

(2) XML Encryption Syntax and Processing Version = 1.1
 http://www.w3= .org/TR/2009/WD-xmlenc-core1-20090226/

=
(3) XML = Signature Transform Simplification: Requirements and = Design
http://ww= w.w3.org/TR/2009/WD-xmldsig-simplify-20090226/

(4) XML = Security Use Cases and Requirements
http://www.w3.= org/TR/2009/WD-xmlsec-reqs-20090226/

(5) XML Security = Derived Keys
http://= www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/
(7) XML Security Algorithm Cross-Reference

<= div>These were included in the following transition = request:

The Working Group has also published an = updated working draft of Best Practices:

(8) = XML Signature Best Practices W3C Working Draft 26 February 2009
http= ://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/

The Working Group would = appreciate review of these documents, with special attention to the = algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the = proposed 2.0 changes in the Transform Simplification document and Use = Cases and Requirements. Again, comment may be sent to the list public-xmlsec-comments@w3.or= g .

Thank you

=
regards, Frederick

Frederick Hirsch, = Nokia
Chair XML Security WG


=


= --Apple-Mail-85--82781022-- From Nicolas.Williams@sun.com Mon Mar 2 08:09:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E563A6452 for ; Mon, 2 Mar 2009 08:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, 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 8KG-aEG403dJ for ; Mon, 2 Mar 2009 08:09:13 -0800 (PST) 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 D670B3A6938 for ; Mon, 2 Mar 2009 08:09:12 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22G9cJ1006627 for ; Mon, 2 Mar 2009 16:09:39 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 n22G9c9j032141 for ; Mon, 2 Mar 2009 09:09:38 -0700 (MST) 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 n22G0bsA012897; Mon, 2 Mar 2009 10:00:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22G0aat012896; Mon, 2 Mar 2009 10:00:36 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 10:00:36 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20090302160035.GF9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@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: der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:09:14 -0000 On Thu, Feb 26, 2009 at 03:20:06PM -0500, Sam Hartman wrote: > Nico, while I'm in favor of channel binding and believe your approach > has a lot of value, please be careful to apply it only where applicable. I'm mildly offended by your comment. This is not channel binding as an end -- it'd be silly to treat channel binding as end in itself, and if you imply that that's what I'm doing then I categorically reject that. This is channel binding as a means to an end, not as the end. The end is mutual authentication without a PKI but with [optional] federation. > Phil is talking about the web browser PKI. Channel binding to > existing authentication solves some problems in that space, but > definitely not all. For example it is not useful for securing > enrollment or certain classes of URI-only handoff. My proposal does not solve enrolment, and though enrolment is the same problem as the base problem, enrolment is also rare, therefore a simpler problem. There are two kinds of enrolment: those where the user is willing to use a pre-existing business relationship, and those where the user is not. For the former one could use SMS, much the way Google handles gmail account creation, and, with somewhat less privacy, any ISP-mediated federation will do as well -- heck, one could have coffee-house mediated federation. For the latter the existing weak PKI will just have to do, but arguably if you're signing up for a hotmail or gmail account without a pre-existing relationship then you get what you pay for, and anyways, eventually you'll notice if you've enrolled through an MITM (because the MITM won't always be able to be in the middle!). > So, I think the web will continue to need a PKI.:-) Yes, but if we solve the mutual authentication case then for the cases where we don't need mutual authentication we can probably live with a weak PKI. Nico -- From Nicolas.Williams@sun.com Mon Mar 2 08:20:12 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3CD3A6902 for ; Mon, 2 Mar 2009 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.019, 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 MSBzvxWNk4se for ; Mon, 2 Mar 2009 08:20:11 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D387C3A690F for ; Mon, 2 Mar 2009 08:20:11 -0800 (PST) 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 n22GKbNZ021052 for ; Mon, 2 Mar 2009 16:20:37 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 n22GKaWi041748 for ; Mon, 2 Mar 2009 09:20:37 -0700 (MST) 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 n22GBZ6s012905; Mon, 2 Mar 2009 10:11:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22GBZd7012904; Mon, 2 Mar 2009 10:11:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 10:11:35 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20090302161134.GG9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090227022359.8D45150822@romeo.rtfm.com> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:20:12 -0000 On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote: > I don't want to get into an extensive argument about this on SAAG, > but I don't think this direction is particularly promising, for > reasons I've indicated before: namely that you're handwaving > the difficult part of the problem, UI, which we have no real > idea how to solve. Sure, if we solved that, there are any > number of things we could do, but absent that, the other things > are fairly useless. I'm not entirely handwaving the UI part. There are two major UI problems: a) the desire for full-screen apps, and, more generally, apps that have full access to human interface I/O, b) the desire of web application developers to have full control over credentials prompts. (a) is practically insurmountable -- SAS helps, but I doubt users will be happy to use SAS every time they are prompted for credentials. My knee-jerk reaction would be to reject full-screen apps. In my scheme (b) is solved by letting apps prompt for identities, but not any passwords -- and training users not to enter passwords into non-secure dialogs (see SAS comment) -- and by having authentication mechanisms where the relying party does not get to impersonate the client just because the client authenticated itself (this, in turn, creates another problem in that lots of web services need delegation). In particular I think the solution to (b) needs to go hand-in-hand with any solution to the mutual authentication problem. > I think you're rather overselling here: this only works well for > account-based systems. There are plenty of cases where I need to > connect to someone where I only know their name but I don't yet have > an account (e.g., https://www.amazon.com). The mechanism that you > provide doesn't work at all in this case. Rather, you need some > third-party verifiable mechanism. I suppose one could argue that certs > aren't a good such mechanism, but they're the one that TLS supports > and I suspect any replacement would smell a lot like certs. I just addressed enrolment (I took "but I don't _yet_ have an account" to refer to enrolment) in a reply to Sam. For cases that are not enrolment and where you never need user authentication, but do need server authentication, I can only think of PKI, and today's weak PKI will just have to do. Nico -- From ekr@networkresonance.com Mon Mar 2 08:58:19 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC24E3A6A71 for ; Mon, 2 Mar 2009 08:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 VaCelh8tRS74 for ; Mon, 2 Mar 2009 08:58:19 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 16AF43A6879 for ; Mon, 2 Mar 2009 08:58:19 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DA43650822; Mon, 2 Mar 2009 09:21:35 -0800 (PST) Date: Mon, 02 Mar 2009 09:21:35 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20090302161134.GG9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090302172135.DA43650822@romeo.rtfm.com> Cc: saag@ietf.org, der Mouse Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:58:20 -0000 At Mon, 2 Mar 2009 10:11:35 -0600, Nicolas Williams wrote: > > On Thu, Feb 26, 2009 at 06:23:59PM -0800, Eric Rescorla wrote: > > I don't want to get into an extensive argument about this on SAAG, > > but I don't think this direction is particularly promising, for > > reasons I've indicated before: namely that you're handwaving > > the difficult part of the problem, UI, which we have no real > > idea how to solve. Sure, if we solved that, there are any > > number of things we could do, but absent that, the other things > > are fairly useless. > > I'm not entirely handwaving the UI part. There are two major UI > problems: a) the desire for full-screen apps, and, more generally, apps > that have full access to human interface I/O, b) the desire of web > application developers to have full control over credentials prompts. > > (a) is practically insurmountable -- SAS helps, but I doubt users will > be happy to use SAS every time they are prompted for credentials. My > knee-jerk reaction would be to reject full-screen apps. > > In my scheme (b) is solved by letting apps prompt for identities, > but not any passwords -- and training users not to enter passwords into > non-secure dialogs (see SAS comment) -- and by having authentication > mechanisms where the relying party does not get to impersonate the > client just because the client authenticated itself (this, in turn, > creates another problem in that lots of web services need delegation). > > In particular I think the solution to (b) needs to go hand-in-hand with > any solution to the mutual authentication problem. I would characterize this as handwaving. As long as the user's credential provided to their client is a human readable password (and I think that's pretty clearly an invariant in a large number of cases), then you have to worry about the user being conned into typing their password into a dialog box controlled by the attacker. Seeing as the available evidence suggests that there is almost no UI chrome that can stop them from doing so, even when the attacker only controls the ordinary browser interface. Sure, you can imagine training users not to do that, but since there's no evidence that you can in fact do so, that seems fairly speculative. -Ekr P.S. I don't see how SAS is at all relevant here. SAS depends on the existence of a trusted channel to carry the SAS, and that's precisely what we don't have. From jhutz@cmu.edu Mon Mar 2 09:08:29 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC42F3A692A for ; Mon, 2 Mar 2009 09:08:29 -0800 (PST) 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 QiUEswZsMRkk for ; Mon, 2 Mar 2009 09:08:26 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B78443A69EA for ; Mon, 2 Mar 2009 09:08:24 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (174-147-224-192.pools.spcsdns.net [174.147.224.192]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22H8k49005651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 12:08:47 -0500 (EST) Date: Mon, 02 Mar 2009 12:08:45 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman Message-ID: <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:08:29 -0000 --On Monday, March 02, 2009 10:00:36 AM -0600 Nicolas Williams wrote: > Yes, but if we solve the mutual authentication case then for the cases > where we don't need mutual authentication we can probably live with a > weak PKI. No, that is not true. These days, people routinely establish new, real business relationships online. Companies like Amazon and PayPal depend on this model, and so do smaller merchants who probably number in the millions. In many cases, consumers engage in a single transaction with such a merchant and there is _never_ any enrollment. Mutual authentication plus channel binding is a great model for some things, but expecting to use off-line enrollment for everything forever is a non-starter. -- Jeff From Nicolas.Williams@sun.com Mon Mar 2 09:20:05 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2763A6887 for ; Mon, 2 Mar 2009 09:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.054, 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 UrfeIs-0BuRd for ; Mon, 2 Mar 2009 09:20:02 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id B6B253A6908 for ; Mon, 2 Mar 2009 09:20:02 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22HKSQW002615 for ; Mon, 2 Mar 2009 17:20:28 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 n22HKSCu004445 for ; Mon, 2 Mar 2009 10:20:28 -0700 (MST) 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 n22HBOUg012991; Mon, 2 Mar 2009 11:11:24 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22HBMow012990; Mon, 2 Mar 2009 11:11:22 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 11:11:22 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20090302171122.GM9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090302172135.DA43650822@romeo.rtfm.com> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org, der Mouse Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:20:05 -0000 On Mon, Mar 02, 2009 at 09:21:35AM -0800, Eric Rescorla wrote: > At Mon, 2 Mar 2009 10:11:35 -0600, > Nicolas Williams wrote: > > In my scheme (b) is solved by letting apps prompt for identities, > > but not any passwords -- and training users not to enter passwords into > > non-secure dialogs (see SAS comment) -- and by having authentication > > mechanisms where the relying party does not get to impersonate the > > client just because the client authenticated itself (this, in turn, > > creates another problem in that lots of web services need delegation). > > > > In particular I think the solution to (b) needs to go hand-in-hand with > > any solution to the mutual authentication problem. > > I would characterize this as handwaving. > > As long as the user's credential provided to their client is a human > readable password (and I think that's pretty clearly an invariant in a > large number of cases), then you have to worry about the user being > conned into typing their password into a dialog box controlled by the > attacker. Seeing as the available evidence suggests that there is > almost no UI chrome that can stop them from doing so, even when the > attacker only controls the ordinary browser interface. It will be a long time before users can be trained not to type passwords into attacker-controlled dialogs -- that is definitely true. And we'll also have passwords for a long time yet. These are not reasons to throw our hands up and give up. Deploy mutual authentication schemes first, then train users; training users first won't do since there's no way for the UI to distinguish password dialogs for web applications, since there's no mechanism other than sending the password in an HTML form. DIGEST-MD5 exists, and I'd advocate its use, but currently that always results in a browser-controlled dialog that app designers hate (or, if you use XmlHttpRequest then the application can prompt for the password in a form and then use DIGEST-MD5 without a browser dialog, but this is still an attacker-controlled form). The change that would make DIGEST-MD5 and friends more acceptable is to let the app provide a form where the user fills in a username, and then let the browser prompt for the password if it doesn't already have it. That's not handwaving -- there are specific details here. That it will take time to get there is not handwaving for that will be true of any solutions. > Sure, you can imagine training users not to do that, but since > there's no evidence that you can in fact do so, that seems fairly > speculative. Any solution will require training, if nothing else because otherwise everyone will continue doing what we all do today: typing passwords into HTML forms, so that servers get cleartext passwords, and MITMs get all our money. > -Ekr > > P.S. I don't see how SAS is at all relevant here. SAS depends on the existence > of a trusted channel to carry the SAS, and that's precisely what we don't > have. That's precisely what using a mutual authentication mechanism adds: a trusted channel. Now, mechanism strength will vary, and use of weak passwords with mechanisms that don't do well when used with weak passwords is a problem, but I'd much rather have that problem to worry about than the current one. Nico -- From Nicolas.Williams@sun.com Mon Mar 2 09:33:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E563A6908 for ; Mon, 2 Mar 2009 09:33:10 -0800 (PST) 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.053, 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 sphsI878hgVY for ; Mon, 2 Mar 2009 09:33:09 -0800 (PST) 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 359613A6902 for ; Mon, 2 Mar 2009 09:32:54 -0800 (PST) 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 n22HXKpL006940 for ; Mon, 2 Mar 2009 17:33:20 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 n22HXJka015704 for ; Mon, 2 Mar 2009 10:33:19 -0700 (MST) 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 n22HGlcN012997; Mon, 2 Mar 2009 11:16:47 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22HGl9K012996; Mon, 2 Mar 2009 11:16:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 11:16:47 -0600 From: Nicolas Williams To: Peter Gutmann Message-ID: <20090302171646.GN9992@Sun.COM> References: <20090226165448.GK9992@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: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:33:10 -0000 On Fri, Feb 27, 2009 at 07:56:12PM +1300, Peter Gutmann wrote: > Nicolas Williams writes: > > >What we need is something like DIGEST-MD5, but tied into browser apps in a > >different way than DIGEST-MD5 is today (more on this below). Given this we > >can forego PKI -- just do channel binding to TLS (with or without server > >certs, whether CA-issued or self-signed). > > We already have this, and have had for some years, it's called TLS-PSK. TLS-PSK is not sufficient by itself, and for two reasons: a) As the RFC says: "[h]owever, this document is not intended for web password authentication, but rather for other uses of TLS." Thus there is nothing about how to derive PSKs from passwords. Now, we could have PSKs bootstrapped by passwords, but that requires an enrolment protocol, and the result is non-portable credentials (where portable credentials are ones that require no physical devices in order to carry, except, perhaps, pen and paper). b) For any solution to scale that adds mutual authentication we'll need either the user to use the same password for all identities or federation. TLS-PSK does nothing about passwords (see (a)) and nothing about federation. > Unfortunately the browser vendors' approach is to keep on waiting for PKI to > start working, forever if necessary. "PKI meurt, elle ne se rend pas!" [0]. Not surpringly given the lack of usable mechanisms for mutual authentication. Nico -- From Nicolas.Williams@sun.com Mon Mar 2 09:43:17 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE19C3A692A for ; Mon, 2 Mar 2009 09:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.052, 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 ErozKkMF-l4L for ; Mon, 2 Mar 2009 09:43:17 -0800 (PST) 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 D2F8328C20B for ; Mon, 2 Mar 2009 09:42:47 -0800 (PST) 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 n22HhD2k010531 for ; Mon, 2 Mar 2009 17:43:13 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 n22HhDNe025311 for ; Mon, 2 Mar 2009 10:43:13 -0700 (MST) 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 n22HQfSm013013; Mon, 2 Mar 2009 11:26:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22HQf5h013012; Mon, 2 Mar 2009 11:26:41 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 11:26:41 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20090302172641.GP9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: Sam Hartman , der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:43:18 -0000 On Mon, Mar 02, 2009 at 12:08:45PM -0500, Jeffrey Hutzelman wrote: > --On Monday, March 02, 2009 10:00:36 AM -0600 Nicolas Williams > wrote: > >Yes, but if we solve the mutual authentication case then for the cases > >where we don't need mutual authentication we can probably live with a > >weak PKI. > > No, that is not true. These days, people routinely establish new, real > business relationships online. Companies like Amazon and PayPal depend on > this model, and so do smaller merchants who probably number in the > millions. In many cases, consumers engage in a single transaction with > such a merchant and there is _never_ any enrollment. > > Mutual authentication plus channel binding is a great model for some > things, but expecting to use off-line enrollment for everything forever is > a non-starter. I addressed enrolment in separate posts. I believe enrolment can be bootstrapped securely in a great many ways. For example: - via SMS (requires a phone) - via telephone (requires a phone) - at any network access point if you can authenticate the access point: Imagine a coffee house that posts a certificate fingerprint on a flyer by the cashier, then you can use the coffee house's infrastructure (an access point and a small service running on it) to enrol in any service federated with that coffee house. This method has anonymity. It is a form of off-line enrolment in that it requires finding such a coffee house and going there, but we all pretty much do that -- we're physical beings after all and most of us go places (and even those that can't go places can still, with the help of others, do enrolment). Note again that channel binding is but a means to an end -- if TLS were to provide suitable mutual authentication mechanisms then we'd not need channel binding as that would be but an internal detail of TLS. Sadly TLS does not (no, TLS-PSK is not a suitable mutual authentication mechanism, for reasons I set out in a reply to Peter just now). Nico -- From ekr@networkresonance.com Mon Mar 2 09:48:54 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28BF428C289 for ; Mon, 2 Mar 2009 09:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 jEiIxQKHOwdX for ; Mon, 2 Mar 2009 09:48:50 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4B2FD28C291 for ; Mon, 2 Mar 2009 09:48:26 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2B7B550822; Mon, 2 Mar 2009 10:11:43 -0800 (PST) Date: Mon, 02 Mar 2009 10:11:43 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20090302171122.GM9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <20090302171122.GM9992@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090302181143.2B7B550822@romeo.rtfm.com> Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:48:54 -0000 At Mon, 2 Mar 2009 11:11:22 -0600, Nicolas Williams wrote: > > On Mon, Mar 02, 2009 at 09:21:35AM -0800, Eric Rescorla wrote: > > At Mon, 2 Mar 2009 10:11:35 -0600, > > Nicolas Williams wrote: > > > In my scheme (b) is solved by letting apps prompt for identities, > > > but not any passwords -- and training users not to enter passwords into > > > non-secure dialogs (see SAS comment) -- and by having authentication > > > mechanisms where the relying party does not get to impersonate the > > > client just because the client authenticated itself (this, in turn, > > > creates another problem in that lots of web services need delegation). > > > > > > In particular I think the solution to (b) needs to go hand-in-hand with > > > any solution to the mutual authentication problem. > > > > I would characterize this as handwaving. > > > > As long as the user's credential provided to their client is a human n> > readable password (and I think that's pretty clearly an invariant in a > > large number of cases), then you have to worry about the user being > > conned into typing their password into a dialog box controlled by the > > attacker. Seeing as the available evidence suggests that there is > > almost no UI chrome that can stop them from doing so, even when the > > attacker only controls the ordinary browser interface. > > It will be a long time before users can be trained not to type passwords > into attacker-controlled dialogs -- that is definitely true. And we'll > also have passwords for a long time yet. These are not reasons to throw > our hands up and give up. > > Deploy mutual authentication schemes first, then train users; training > users first won't do since there's no way for the UI to distinguish > password dialogs for web applications, since there's no mechanism other > than sending the password in an HTML form. > > DIGEST-MD5 exists, and I'd advocate its use, but currently that always > results in a browser-controlled dialog that app designers hate (or, if > you use XmlHttpRequest then the application can prompt for the password > in a form and then use DIGEST-MD5 without a browser dialog, but this is > still an attacker-controlled form). The change that would make > DIGEST-MD5 and friends more acceptable is to let the app provide a form > where the user fills in a username, and then let the browser prompt for > the password if it doesn't already have it. And the attacker will just pop up a dialog that says "our cool new UI system is broken. Type your password into the form for now." This is quite clear from [SDO+07]. > That's not handwaving -- there are specific details here. That it will > take time to get there is not handwaving for that will be true of any > solutions. Except that you're handwaving about the UI, which is the critical part that we have no idea how to solve. We already have plenty of cryptographic protocols here. What we don't have is the UI. So, no, I don't think it's particularly useful to put a new coat of paint on the crypto. > > Sure, you can imagine training users not to do that, but since > > there's no evidence that you can in fact do so, that seems fairly > > speculative. > > Any solution will require training, if nothing else because otherwise > everyone will continue doing what we all do today: typing passwords into > HTML forms, so that servers get cleartext passwords, and MITMs get all > our money. "We must do something. This is something. We must do this." > > P.S. I don't see how SAS is at all relevant here. SAS depends on the existence > > of a trusted channel to carry the SAS, and that's precisely what we don't > > have. > > That's precisely what using a mutual authentication mechanism adds: a > trusted channel. Now, mechanism strength will vary, and use of weak > passwords with mechanisms that don't do well when used with weak > passwords is a problem, but I'd much rather have that problem to worry > about than the current one. Huh? If you already ahve mutual authentication, you don't need an SAS. An SAS is about establishing a cryptographically trusted channel from a low bandwidth non-cryptographic channel. -Ekr [SDO+07] S. Schechter, R. Dhajima, A. Ozment, I. Fischer, "The Emperor's New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies", IEEE Oakland 2007. From aland@deployingradius.com Mon Mar 2 09:57:08 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7159328C253 for ; Mon, 2 Mar 2009 09:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701, 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 KVgJ5GiZgNzZ for ; Mon, 2 Mar 2009 09:57:07 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 98B223A68F9 for ; Mon, 2 Mar 2009 09:57:07 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id C7A101234091; Mon, 2 Mar 2009 18:57:32 +0100 (CET) Message-ID: <49AC1E0C.8040407@deployingradius.com> Date: Mon, 02 Mar 2009 18:57:32 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Nicolas Williams References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> <20090302172641.GP9992@Sun.COM> In-Reply-To: <20090302172641.GP9992@Sun.COM> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org, Sam Hartman , der Mouse Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:57:08 -0000 Nicolas Williams wrote: > Imagine a coffee house ... doing anything but selling coffee. Nope, that's not going to work. I work with/for global WiFi operators, so I have some experience here. Take Starbucks, for example. They have WiFi. What do the employees know about it? Pretty much nothing. What do the people who installed it know about it? Pretty much nothing. What does the network operator *running* the network know about it? Pretty much nothing. You can't begin to believe how bad many of these networks are. > that posts a certificate fingerprint on a > flyer by the cashier, then you can use the coffee house's > infrastructure (an access point and a small service running on it) to > enrol in any service federated with that coffee house. This presumes that social engineering attacks, and/or re-printing flyers is hard. It's not. Alan DeKok. From jhutz@cmu.edu Mon Mar 2 10:09:22 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319D228C285 for ; Mon, 2 Mar 2009 10:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 XWhmzrErirbV for ; Mon, 2 Mar 2009 10:09:21 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 881DE28C2B9 for ; Mon, 2 Mar 2009 10:08:47 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22I966x007962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 13:09:06 -0500 (EST) Date: Mon, 02 Mar 2009 13:09:06 -0500 From: Jeffrey Hutzelman To: Alan DeKok , Nicolas Williams Message-ID: In-Reply-To: <49AC1E0C.8040407@deployingradius.com> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> <20090302172641.GP9992@Sun.COM> <49AC1E0C.8040407@deployingradius.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: Sam Hartman , der Mouse , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:09:22 -0000 --On Monday, March 02, 2009 06:57:32 PM +0100 Alan DeKok wrote: > Take Starbucks, for example. They have WiFi. What do the employees > know about it? Pretty much nothing. What do the people who installed > it know about it? Pretty much nothing. What does the network operator > *running* the network know about it? Pretty much nothing. Actually, I believe in the specific case of Starbucks, the network operator running the network is T-Mobile, and so probably actually _does_ know something about it. At least, at the macro level. But the point stands -- coffee houses are not network operators and they are not federated identity service providers. They are purveyors of concentrated liquid evil, and the occasional cup of tea. -- Jeff From jhutz@cmu.edu Mon Mar 2 10:18:50 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E1728C13E for ; Mon, 2 Mar 2009 10:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 NewkVZIYsf3A for ; Mon, 2 Mar 2009 10:18:50 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id DBDB43A659C for ; Mon, 2 Mar 2009 10:18:49 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22IJDk5008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 13:19:14 -0500 (EST) Date: Mon, 02 Mar 2009 13:19:13 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , Eric Rescorla Message-ID: <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> In-Reply-To: <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: saag@ietf.org, der Mouse Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:18:50 -0000 --On Monday, March 02, 2009 11:11:22 AM -0600 Nicolas Williams wrote: > It will be a long time before users can be trained not to type passwords > into attacker-controlled dialogs -- that is definitely true. No, no. It's a long way down the road to the chemist's. It will be _forever_ before users can be trained not to type passwords into attacker-controlled dialogs. We've been trying for decades, and some of the users in question have _been here_ for decades, and the message still hasn't gotten through. > And we'll > also have passwords for a long time yet. Again, probably forever. > DIGEST-MD5 exists, and I'd advocate its use, but currently that always > results in a browser-controlled dialog that app designers hate To a certain extent, this is too bad. For password dialogs to be safe, they _must_ be browser-controlled (or system-controlled) dialogs over which the app designers have no control. Note that virtually all of the security problems the web has today result from app designers demanding and browser vendors granting more control over the client computer than the system was designed to give them. Just for the record, the amount of control the system was designed to give app designers over the client computer is.... zero! Every security, performance, and usability problem the Web has today can be traced to violations of that design principle. -- Jeff From Nicolas.Williams@sun.com Mon Mar 2 10:25:35 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3267528C13E for ; Mon, 2 Mar 2009 10:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.051, 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 QHc76de+vuX9 for ; Mon, 2 Mar 2009 10:25:34 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 3602D3A69B9 for ; Mon, 2 Mar 2009 10:25:34 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n22IQ0hh029943 for ; Mon, 2 Mar 2009 18:26:00 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 n22IPx1t059939 for ; Mon, 2 Mar 2009 11:25:59 -0700 (MST) 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 n22IGxFu013058; Mon, 2 Mar 2009 12:16:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22IGvT2013057; Mon, 2 Mar 2009 12:16:57 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 12:16:57 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20090302181657.GV9992@Sun.COM> References: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <20090302171122.GM9992@Sun.COM> <20090302181143.2B7B550822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090302181143.2B7B550822@romeo.rtfm.com> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org, der Mouse Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:25:35 -0000 On Mon, Mar 02, 2009 at 10:11:43AM -0800, Eric Rescorla wrote: > And the attacker will just pop up a dialog that says "our cool new UI > system is broken. Type your password into the form for now." This is > quite clear from [SDO+07]. Clearly. Eventually this would no longer be true -- but we'll never get there if we don't provide any mechanisms that can overcome this. Certificates won't do because passwords remain, and will remain the lowest common denominator for a long time. Unless small, portable devices with UIs (mobile phones!) become so ubiquitous (they're getting there) that they are as portable and ever present as passwords. But I suspect the same will apply to that alternative: it will be years before we stop relying on passwords. > > Any solution will require training, if nothing else because otherwise > > everyone will continue doing what we all do today: typing passwords into > > HTML forms, so that servers get cleartext passwords, and MITMs get all > > our money. > > "We must do something. This is something. We must do this." There are so many "this" we can do, and any one will take time. Choose an approach. Requiring that everyone have bluetooth- and NFC-equipped cell phones (and probably data rate service) and desktops and laptops (terminals of any kind) will certainly do, provided that such a requirement is reasonable -- we're getting closer to where it is. Nico -- From ekr@networkresonance.com Mon Mar 2 10:37:39 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5661028C285 for ; Mon, 2 Mar 2009 10:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 5Hj3UUjSWPF8 for ; Mon, 2 Mar 2009 10:37:38 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 920E228C1DC for ; Mon, 2 Mar 2009 10:37:38 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6E11550822; Mon, 2 Mar 2009 11:00:55 -0800 (PST) Date: Mon, 02 Mar 2009 11:00:55 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20090302181657.GV9992@Sun.COM> References: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <20090302171122.GM9992@Sun.COM> <20090302181143.2B7B550822@romeo.rtfm.com> <20090302181657.GV9992@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090302190055.6E11550822@romeo.rtfm.com> Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:37:39 -0000 At Mon, 2 Mar 2009 12:16:57 -0600, Nicolas Williams wrote: > > On Mon, Mar 02, 2009 at 10:11:43AM -0800, Eric Rescorla wrote: > > And the attacker will just pop up a dialog that says "our cool new UI > > system is broken. Type your password into the form for now." This is > > quite clear from [SDO+07]. > > Clearly. Eventually this would no longer be true -- but we'll never get > there if we don't provide any mechanisms that can overcome this. > Certificates won't do because passwords remain, and will remain the > lowest common denominator for a long time. > > Unless small, portable devices with UIs (mobile phones!) become so > ubiquitous (they're getting there) that they are as portable and ever > present as passwords. But I suspect the same will apply to that > alternative: it will be years before we stop relying on passwords. > > > > Any solution will require training, if nothing else because otherwise > > > everyone will continue doing what we all do today: typing passwords into > > > HTML forms, so that servers get cleartext passwords, and MITMs get all > > > our money. > > > > "We must do something. This is something. We must do this." > > There are so many "this" we can do, and any one will take time. Choose > an approach. Requiring that everyone have bluetooth- and NFC-equipped > cell phones (and probably data rate service) and desktops and laptops > (terminals of any kind) will certainly do, provided that such a > requirement is reasonable -- we're getting closer to where it is. We're now in the discussion I told myself I didn't want to have. Suffice to say that for the reasons I've alredy indicated I don't think the technical direction you propose is at all promising. -Ekr From Nicolas.Williams@sun.com Mon Mar 2 10:41:53 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3254E28C22C for ; Mon, 2 Mar 2009 10:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 PQ4E9O8BXr+r for ; Mon, 2 Mar 2009 10:41:52 -0800 (PST) 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 4867D28C151 for ; Mon, 2 Mar 2009 10:41:52 -0800 (PST) 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 n22IgI7H006121 for ; Mon, 2 Mar 2009 18:42:18 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 n22IgI9m007304 for ; Mon, 2 Mar 2009 11:42:18 -0700 (MST) 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 n22IPmVX013072; Mon, 2 Mar 2009 12:25:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22IPmID013071; Mon, 2 Mar 2009 12:25:48 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 12:25:47 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20090302182547.GX9992@Sun.COM> References: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:41:53 -0000 On Mon, Mar 02, 2009 at 01:19:13PM -0500, Jeffrey Hutzelman wrote: > --On Monday, March 02, 2009 11:11:22 AM -0600 Nicolas Williams > wrote: > > >It will be a long time before users can be trained not to type passwords > >into attacker-controlled dialogs -- that is definitely true. > > No, no. It's a long way down the road to the chemist's. It will be > _forever_ before users can be trained not to type passwords into > attacker-controlled dialogs. We've been trying for decades, and some of > the users in question have _been here_ for decades, and the message still > hasn't gotten through. Mostly because the technology to move beyond application-controlled dialogs has not been deployed or the technologies that have been have been unsatisfactory. All I see in your reply is surrender. > >And we'll > >also have passwords for a long time yet. > > Again, probably forever. Indeed, cell phones and all. > >DIGEST-MD5 exists, and I'd advocate its use, but currently that always > >results in a browser-controlled dialog that app designers hate > > To a certain extent, this is too bad. For password dialogs to be safe, > they _must_ be browser-controlled (or system-controlled) dialogs over which > the app designers have no control. Note that virtually all of the security > problems the web has today result from app designers demanding and browser > vendors granting more control over the client computer than the system was > designed to give them. Indeed. I'm proposing an incremental approach to this problem. Perhaps I'm talking to the wrong crowd -- at SAAG we're mostly security engineers, whereas any conversation about overcoming the above problem must involve web application developers. > Just for the record, the amount of control the system was designed to give > app designers over the client computer is.... zero! Every security, > performance, and usability problem the Web has today can be traced to > violations of that design principle. Agreed. Nico -- From jhutz@cmu.edu Mon Mar 2 10:45:35 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2639C28C248 for ; Mon, 2 Mar 2009 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 j5-Hf8eAY3f3 for ; Mon, 2 Mar 2009 10:45:34 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 382063A6804 for ; Mon, 2 Mar 2009 10:45:34 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n22Ijw8e009444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 13:45:58 -0500 (EST) Date: Mon, 02 Mar 2009 13:45:58 -0500 From: Jeffrey Hutzelman To: Nicolas Williams Message-ID: <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> In-Reply-To: <20090302182547.GX9992@Sun.COM> References: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:45:35 -0000 --On Monday, March 02, 2009 12:25:47 PM -0600 Nicolas Williams wrote: > On Mon, Mar 02, 2009 at 01:19:13PM -0500, Jeffrey Hutzelman wrote: >> --On Monday, March 02, 2009 11:11:22 AM -0600 Nicolas Williams >> wrote: >> >> > It will be a long time before users can be trained not to type >> > passwords into attacker-controlled dialogs -- that is definitely true. >> >> No, no. It's a long way down the road to the chemist's. It will be >> _forever_ before users can be trained not to type passwords into >> attacker-controlled dialogs. We've been trying for decades, and some of >> the users in question have _been here_ for decades, and the message >> still hasn't gotten through. > > Mostly because the technology to move beyond application-controlled > dialogs has not been deployed or the technologies that have been have > been unsatisfactory. No, it has nothing to do with the technology. As long as users have a password, they will give it to anyone or anything that asks for it. You'll get through to some of them that they shouldn't give their password away, but not to most of them. Really. It's sad to say, but people in general do _not_ read directions and do _not_ follow procedures, even when they are carefully trained in procedures specifically designed to protect against particular threats, and even when the threat is to the user's life or safety. How do you expect users to remember not to give away their passwords when they can't be bothered to remember to wash their hands or look both ways before crossing a street? -- Jeff From Nicolas.Williams@sun.com Mon Mar 2 10:46:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C025E3A6A04 for ; Mon, 2 Mar 2009 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Lp0cxUPEGgo7 for ; Mon, 2 Mar 2009 10:46:10 -0800 (PST) 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 CD1A73A6804 for ; Mon, 2 Mar 2009 10:46:09 -0800 (PST) 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 n22IkaNL007554 for ; Mon, 2 Mar 2009 18:46:36 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 n22IkZSo010779 for ; Mon, 2 Mar 2009 11:46:35 -0700 (MST) 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 n22IMZio013064; Mon, 2 Mar 2009 12:22:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22IMWOI013063; Mon, 2 Mar 2009 12:22:32 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 12:22:32 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20090302182232.GW9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> <20090302172641.GP9992@Sun.COM> <49AC1E0C.8040407@deployingradius.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: saag@ietf.org, Sam Hartman , der Mouse Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:46:10 -0000 On Mon, Mar 02, 2009 at 01:09:06PM -0500, Jeffrey Hutzelman wrote: > --On Monday, March 02, 2009 06:57:32 PM +0100 Alan DeKok > wrote: > > > Take Starbucks, for example. They have WiFi. What do the employees > >know about it? Pretty much nothing. What do the people who installed > >it know about it? Pretty much nothing. What does the network operator > >*running* the network know about it? Pretty much nothing. > > Actually, I believe in the specific case of Starbucks, the network operator > running the network is T-Mobile, and so probably actually _does_ know > something about it. At least, at the macro level. > > But the point stands -- coffee houses are not network operators and they > are not federated identity service providers. They are purveyors of > concentrated liquid evil, and the occasional cup of tea. Coffee houses most definitely sell Internet access (or just give it away). And the point wasn't specific to coffe houses. Any access point could provide an enrolment bootstrapping service via federation if the market wanted that sort of service... ... but the market won't demand that because people will generally be happy to use existing relationships, such as phone service, for enrolment. And those that don't will settle for using the existing weak-PKI and will test for MITMs by trying to use their accounts from many different places in the network. I used coffee houses as an example of how anonymity could still be had while solving the enrolment process without a PKI. I didn't mean to propose that as the primary form of enrolment. Quite the contrary; in practice using SMS should do quite well. Nico -- From Nicolas.Williams@sun.com Mon Mar 2 10:52:15 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2620528C0FB for ; Mon, 2 Mar 2009 10:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.049, 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 pH-7fWzMOqdc for ; Mon, 2 Mar 2009 10:52:14 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 60E9428C28C for ; Mon, 2 Mar 2009 10:52:14 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22IqdNn020459 for ; Mon, 2 Mar 2009 18:52:39 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 n22IqdGb015342 for ; Mon, 2 Mar 2009 11:52:39 -0700 (MST) 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 n22IhdF3013105; Mon, 2 Mar 2009 12:43:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22Ihd2k013104; Mon, 2 Mar 2009 12:43:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 12:43:39 -0600 From: Nicolas Williams To: Eric Rescorla Message-ID: <20090302184339.GA9992@Sun.COM> References: <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <20090302171122.GM9992@Sun.COM> <20090302181143.2B7B550822@romeo.rtfm.com> <20090302181657.GV9992@Sun.COM> <20090302190055.6E11550822@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090302190055.6E11550822@romeo.rtfm.com> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org, der Mouse Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 18:52:15 -0000 On Mon, Mar 02, 2009 at 11:00:55AM -0800, Eric Rescorla wrote: > We're now in the discussion I told myself I didn't want to have. > Suffice to say that for the reasons I've alredy indicated I don't > think the technical direction you propose is at all promising. Fair enough. I've made one proposal (mutual auth mechanisms, various enrolment options) and mentioned an alternative (mobile devices everywhere, all the time). Your turn, when you feel like it. Nico -- From Nicolas.Williams@sun.com Mon Mar 2 11:06:55 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73203A6804 for ; Mon, 2 Mar 2009 11:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=0.048, 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 kM7ueax+twyV for ; Mon, 2 Mar 2009 11:06:55 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 06CA43A6901 for ; Mon, 2 Mar 2009 11:06:54 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22J7LYr028873 for ; Mon, 2 Mar 2009 19:07:21 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 n22J7KUG027540 for ; Mon, 2 Mar 2009 12:07:21 -0700 (MST) 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 n22Iopqj013111; Mon, 2 Mar 2009 12:50:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22Iooqs013110; Mon, 2 Mar 2009 12:50:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 12:50:50 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20090302185050.GB9992@Sun.COM> References: <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:06:55 -0000 On Mon, Mar 02, 2009 at 01:45:58PM -0500, Jeffrey Hutzelman wrote: > How do you expect users to remember not to give away their passwords when > they can't be bothered to remember to wash their hands or look both ways > before crossing a street? I must say that the frequency with which I see others *not* wash their hands at public restrooms is distressing. To the degree that such attitudes have negative externalities there's little that can be done short of changing liability, and perhaps therein lies the trouble: it's hard to establish, much less prove how online fraud happened, just as it is hard to prove that someone's not washing their hands at the restroom made you ill. On the other hand, we do provide restrooms with sinks and running water, and even soap. From aland@deployingradius.com Mon Mar 2 11:28:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA353A6821 for ; Mon, 2 Mar 2009 11:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 0DnW2tA8xcuF for ; Mon, 2 Mar 2009 11:28:09 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 09F533A6C2A for ; Mon, 2 Mar 2009 11:28:01 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id DAD861234091; Mon, 2 Mar 2009 20:28:26 +0100 (CET) Message-ID: <49AC335A.1000509@deployingradius.com> Date: Mon, 02 Mar 2009 20:28:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> <20090302172641.GP9992@Sun.COM> <49AC1E0C.8040407@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , der Mouse , Nicolas Williams , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 19:28:10 -0000 Jeffrey Hutzelman wrote: > > Actually, I believe in the specific case of Starbucks, the network > operator running the network is T-Mobile, AT&T for at least a year: http://wifinetnews.com/archives/2008/02/t-mobile_loses_starbucks_att_becomes_wi-fi_hotspot_giant.html Though the migration is taking time. > and so probably actually > _does_ know something about it. At least, at the macro level. No offense to T-Mobile (or anyone else), but managing 1000's of hotspots is hard. When you add large companies who want to use that network, it becomes nearly impossible. We have had a poor response rate from companies wanting to roll out a global WiFi network. "Authentication? What's that? Why can't we just have every WiFi network operator white-list our devices/users/traffic?" Really. So all this talk about PKI && certs is "pie in the sky". We can't even convince major players to use *passwords*. > But the point stands -- coffee houses are not network operators and they > are not federated identity service providers. They are purveyors of > concentrated liquid evil, and the occasional cup of tea. And their network providers are getting squeezed. No matter what T-Mobile does, their revenue from these locations is pretty low, and the user and corporate demands are high. Alan DeKok. From Nicolas.Williams@sun.com Mon Mar 2 13:13:13 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2593E28C261 for ; Mon, 2 Mar 2009 13:13:13 -0800 (PST) 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=[AWL=0.047, 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 4JiOlVjpZTbD for ; Mon, 2 Mar 2009 13:13:12 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A2ED228C1FC for ; Mon, 2 Mar 2009 13:13:06 -0800 (PST) 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 n22LDVXq003941 for ; Mon, 2 Mar 2009 21:13:32 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 n22LDVvB010813 for ; Mon, 2 Mar 2009 14:13:31 -0700 (MST) 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 n22KuxqD013157; Mon, 2 Mar 2009 14:56:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n22KuuTR013156; Mon, 2 Mar 2009 14:56:56 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 14:56:56 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Message-ID: <20090302205656.GF9992@Sun.COM> References: <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090302185050.GB9992@Sun.COM> User-Agent: Mutt/1.5.7i Cc: der Mouse , saag@ietf.org Subject: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:13:13 -0000 Perhaps the simplest fix, technologically speaking, would be to get a real PKI -- no technical changes needed, just political ones. But that strikes me as politically infeasible. A real PKI would imply: - trust anchor regulations - CA and DNS registrar regulations that work Seems unlikely. From ekr@networkresonance.com Mon Mar 2 13:49:52 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E563A67EC for ; Mon, 2 Mar 2009 13:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 fQMl24nsVH2p for ; Mon, 2 Mar 2009 13:49:51 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3EB0E3A67D0 for ; Mon, 2 Mar 2009 13:49:51 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5368850823; Mon, 2 Mar 2009 14:13:08 -0800 (PST) Date: Mon, 02 Mar 2009 14:13:08 -0800 From: Eric Rescorla To: Nicolas Williams In-Reply-To: <20090302171646.GN9992@Sun.COM> References: <20090226165448.GK9992@Sun.COM> <20090302171646.GN9992@Sun.COM> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090302221308.5368850823@romeo.rtfm.com> Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 21:49:52 -0000 At Mon, 2 Mar 2009 11:16:47 -0600, Nicolas Williams wrote: > > On Fri, Feb 27, 2009 at 07:56:12PM +1300, Peter Gutmann wrote: > > Nicolas Williams writes: > > > > >What we need is something like DIGEST-MD5, but tied into browser apps in a > > >different way than DIGEST-MD5 is today (more on this below). Given this we > > >can forego PKI -- just do channel binding to TLS (with or without server > > >certs, whether CA-issued or self-signed). > > > > We already have this, and have had for some years, it's called TLS-PSK. > > TLS-PSK is not sufficient by itself, and for two reasons: > > a) As the RFC says: "[h]owever, this document is not intended for web > password authentication, but rather for other uses of TLS." > > Thus there is nothing about how to derive PSKs from passwords. That's because there are already well-known mechanisms for deriving keys from passwords, as long as you're willing to live with low entropy. See PKCS#5. > Now, we could have PSKs bootstrapped by passwords, but that requires > an enrolment protocol, and the result is non-portable credentials > (where portable credentials are ones that require no physical devices > in order to carry, except, perhaps, pen and paper). Huh? At a high level, if what you want is an authentication mechanism derived form a password, there are only two sets of technical mechanisms: - Symmetric-key based systems like TLS-PSK, CRAM-MD5, Digest, etc. - ZKPP/PAKE systems such as SRP, EKE, etc. All the protocols in the former class have dictionary attacks on the password. The protocols in the latter class do not. TLS-PSK does not explicitly provide for passwords because we did not want to encourage the use of mechanisms which we knew were subject to offline dictionary attacks. This is a policy question, not a technical one. The technical problem is easily solved by specifying a mechanism to derive a shared key from a a password (e.g., PBKDF2). The credentials are quite portable. -Ekr From kent@bbn.com Mon Mar 2 16:24:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C6428C265 for ; Mon, 2 Mar 2009 16:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 Lq594Ajv4itH for ; Mon, 2 Mar 2009 16:24:13 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EFBC83A67E6 for ; Mon, 2 Mar 2009 16:22:58 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.151]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LeIPr-0006Ab-C5; Mon, 02 Mar 2009 19:23:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090302181657.GV9992@Sun.COM> References: <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <20090302171122.GM9992@Sun.COM> <20090302181143.2B7B550822@romeo.rtfm.com> <20090302181657.GV9992@Sun.COM> Date: Mon, 2 Mar 2009 17:02:13 -0500 To: Nicolas Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 00:24:14 -0000 At 12:16 PM -0600 3/2/09, Nicolas Williams wrote: >On Mon, Mar 02, 2009 at 10:11:43AM -0800, Eric Rescorla wrote: >> And the attacker will just pop up a dialog that says "our cool new UI >> system is broken. Type your password into the form for now." This is >> quite clear from [SDO+07]. > >Clearly. Eventually this would no longer be true -- but we'll never get >there if we don't provide any mechanisms that can overcome this. >Certificates won't do because passwords remain, and will remain the >lowest common denominator for a long time. > >Unless small, portable devices with UIs (mobile phones!) become so >ubiquitous (they're getting there) that they are as portable and ever >present as passwords. But I suspect the same will apply to that >alternative: it will be years before we stop relying on passwords. Not only does one need to carry a mobile phone everywhere to login, one also has to have an essentially free SMS service to avoid paying a phone service provider for authentication messages. The same requirement would apply to the sites that need to use SMS to send and receive these messages. Steve From kent@bbn.com Mon Mar 2 16:24:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD49028C1F9 for ; Mon, 2 Mar 2009 16:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 3nJZ9kE0+72L for ; Mon, 2 Mar 2009 16:24:14 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DAD9C28C205 for ; Mon, 2 Mar 2009 16:23:07 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.151]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LeIQ1-0006Ab-Bt; Mon, 02 Mar 2009 19:23:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090302160035.GF9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090302160035.GF9992@Sun.COM> Date: Mon, 2 Mar 2009 19:22:31 -0500 To: Nicolas Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 00:24:14 -0000 Nico, I'm unclear on the exact constraints you're trying to satisfy with the channle binding model, but here are some observations anyway. Mutual authentication is certainly desirable for most communication contexts. But, in contexts where neither party has a relationship with the other a priori, I don't think there is any magic bullet. The primary, large scale, global PKI to which PHB alluded is the only major example we have where a user can get a reasonable level of assurance for one-way authentication. That model enables a (conceptually simple) transition to two-way, cert-based authentication, where each web site can act as a CA for its users. However, the poor tools we have to manage a plethora of certs from these narrowly-scoped CAs makes it hard for users to buy into that model. In other parts of the world (especially in Asia)) there are large PKIs that serve substantial user communities. Often governments take the lead in issuing certs to individuals in these PKIs, and in creating CAs or bridge CAs to certify government and private sector organizations. But, none of this is free. Absent government subsidies, mandated use, or hidden taxes, one ought not surprised by business models that require users and/or web site owners to pay for certs. After all, in most contexts, at best you get what you pay for :-). The lack of a single credential that authenticates a user to everywhere is a good thing from a privacy perspective. Federated identity management schemes create lots of opportunities to link islands of authenticated users (and organizations), but they have sever drawbacks re security. I tend to think of such schemes as having all the charming features of Wikipedia :-). Steve From kent@bbn.com Mon Mar 2 16:24:15 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D3628C2A4 for ; Mon, 2 Mar 2009 16:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 a7n8TH9zRvKv for ; Mon, 2 Mar 2009 16:24:14 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C5AEF28C20E for ; Mon, 2 Mar 2009 16:23:09 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.151]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LeIQ3-0000er-En; Mon, 02 Mar 2009 19:23:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <200903021609.n22G9hIg014931@grapenut.srv.cs.cmu.edu> <1232E3FA9408ED0962D481EF@atlantis.pc.cs.cmu.edu> Date: Mon, 2 Mar 2009 19:23:30 -0500 To: Jeffrey Hutzelman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Sam Hartman , der Mouse , Nicolas Williams , saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 00:24:15 -0000 At 12:08 PM -0500 3/2/09, Jeffrey Hutzelman wrote: >--On Monday, March 02, 2009 10:00:36 AM -0600 Nicolas Williams > wrote: > >>Yes, but if we solve the mutual authentication case then for the cases >>where we don't need mutual authentication we can probably live with a >>weak PKI. > >No, that is not true. These days, people routinely establish new, >real business relationships online. Companies like Amazon and >PayPal depend on this model, and so do smaller merchants who >probably number in the millions. In many cases, consumers engage in >a single transaction with such a merchant and there is _never_ any >enrollment. > >Mutual authentication plus channel binding is a great model for some >things, but expecting to use off-line enrollment for everything >forever is a non-starter. > >-- Jeff Jeff, i think it is important to note the role of credit card companies in making these business relationships viable. I am willing to do business with an unknown, online, merchant based in large part on my ability to decline payment if the merchant misbehaves. Steve From kent@bbn.com Mon Mar 2 16:43:40 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970C028C1FE for ; Mon, 2 Mar 2009 16:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 K-cC-lDuV0Q8 for ; Mon, 2 Mar 2009 16:43:39 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D47CE3A690D for ; Mon, 2 Mar 2009 16:43:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.71.0.151]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LeIju-0000lf-DF; Mon, 02 Mar 2009 19:44:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090302205656.GF9992@Sun.COM> References: <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> Date: Mon, 2 Mar 2009 19:44:00 -0500 To: Nicolas Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 00:43:40 -0000 At 2:56 PM -0600 3/2/09, Nicolas Williams wrote: >Perhaps the simplest fix, technologically speaking, would be to get a >real PKI -- no technical changes needed, just political ones. But that >strikes me as politically infeasible. > >A real PKI would imply: > > - trust anchor regulations > - CA and DNS registrar regulations that work As I noted in the message I sent (which crossed in the ether) this is not uncommon in Asia. For example, CAs have to be licensed by the government in India (and, I think, South Korea). But in the EU and U.S., we have a laisse fare approach to CA regulation. That is a political issue. Steve From Nicolas.Williams@sun.com Mon Mar 2 17:01:43 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1CE28C2DA for ; Mon, 2 Mar 2009 17:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.142, 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 BqZ5+uxfK3VA for ; Mon, 2 Mar 2009 17:01:42 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 29F4028C28A for ; Mon, 2 Mar 2009 17:01:42 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n23128QL007659 for ; Tue, 3 Mar 2009 01:02:08 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 n23128tR022487 for ; Mon, 2 Mar 2009 18:02:08 -0700 (MST) 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 n230jbWd013451; Mon, 2 Mar 2009 18:45:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n230ja5T013450; Mon, 2 Mar 2009 18:45:36 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 18:45:36 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20090303004536.GE9992@Sun.COM> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <1235663917.3293.16.camel@localhost> <20090226165448.GK9992@Sun.COM> <20090302160035.GF9992@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: saag@ietf.org Subject: Re: [saag] Channel binding is great but not a silver bullet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 01:01:43 -0000 On Mon, Mar 02, 2009 at 07:22:31PM -0500, Stephen Kent wrote: > I'm unclear on the exact constraints you're trying to satisfy with > the channle binding model, but here are some observations anyway. Again, channel binding is incidental. I'll lay out the constraints below. > Mutual authentication is certainly desirable for most communication > contexts. But, in contexts where neither party has a relationship > with the other a priori, I don't think there is any magic bullet. This true, but there is a subtlety here: enrolment is rare, much rarer than login events. Enrolment still presents the same problem as typical web app logins today. But the fact that enrolment events are rare helps. I helps in several ways: 1) phishers would need to be luckier if all they could phish were enrolment attempts (just how much luckier than now depends on a variety of details, like how easy it is to poison every significant ISP's every DNS cache); 2) throw in federated authentication mechanisms and truly-initial enrolment events get rarer, which enhances effect #1 and, 3) allows one to leverage existing relationships for securing enrolment (at a cost in terms of anonymity, but then, this is optional). > The primary, large scale, global PKI to which PHB alluded is the only > major example we have where a user can get a reasonable level of > assurance for one-way authentication. Agreed. (But see (2) in conjunction with (3) above with regards to "one-way authentication" (meaning that it's the server that gets authenticated) in the context of enrolment. Non-enrolment-related needs for one-way authentication are probably much rarer than normal logins, and probably don't present as much of a phishing target (but I admit I'm not sure of this last). > That model enables a > (conceptually simple) transition to two-way, cert-based > authentication, where each web site can act as a CA for its users. > However, the poor tools we have to manage a plethora of certs from > these narrowly-scoped CAs makes it hard for users to buy into that > model. Agreed. > In other parts of the world (especially in Asia)) there are large > PKIs that serve substantial user communities. Often governments take > the lead in issuing certs to individuals in these PKIs, and in > creating CAs or bridge CAs to certify government and private sector > organizations. Even here, Stateside, the DoD has a huge PKI. > But, none of this is free. Absent government subsidies, mandated use, > or hidden taxes, one ought not surprised by business models that > require users and/or web site owners to pay for certs. After all, in > most contexts, at best you get what you pay for :-). Exactly. I'm not, I should add, trying to cut out what Peter called "nuissance fees." If authentication federations took off it's very likely that they'd have their own nuissance fees. > The lack of a single credential that authenticates a user to > everywhere is a good thing from a privacy perspective. Federated Indeed. But users also want convenience and are willing to trade off between the two. Thus one might have 100 accounts with no federation, or 10 with, using, say, one just for one's preferred dating site, etc... -- most accounts in my home are related to shopping, where privacy is somewhat less important, particularly considering the current online payment system). > identity management schemes create lots of opportunities to link > islands of authenticated users (and organizations), but they have > sever drawbacks re security. I tend to think of such schemes as > having all the charming features of Wikipedia :-). The ones that exist today, yes! But that's partly because they are all constrained to usign HTML forms for logins and redirects and all sorts of funny business. The constraints as I see them: a) Must have mutual authentication. b) Must use passwords (but need not necessarily be a DISGEST-MD5-like mechanism -- for example, Radia once proposed using SACRED to retrieve private keys and certs). c) Corollary of (a): must not send passwords to the server (whether over TLS or not). d) Must be acceptable to web application developers (they are the reason, after all, that DIGEST-MD5 is not used, they); specifically: - the user experience must be acceptable to web application developers. e) Password-based mechanisms (as opposed to, e.g., Radia's proposal mentioned above) must be federatable, if only because of the need to reduce truly-initial enrolment events, but likely also because of (d). This in order to minimize the number of times a user must type in a password in a browser-controlled dialog, under the theory that web app developers hate those). Cheers, Nico -- From Nicolas.Williams@sun.com Mon Mar 2 17:04:45 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAB73A676A for ; Mon, 2 Mar 2009 17:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.140, 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 wOoAcMSRosc9 for ; Mon, 2 Mar 2009 17:04:44 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id A930F3A6AFE for ; Mon, 2 Mar 2009 17:04:27 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2314sSR017255 for ; Tue, 3 Mar 2009 01:04:54 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 n2314sMZ024136 for ; Mon, 2 Mar 2009 18:04:54 -0700 (MST) 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 n230mNcj013457; Mon, 2 Mar 2009 18:48:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n230mNWv013456; Mon, 2 Mar 2009 18:48:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 2 Mar 2009 18:48:23 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20090303004823.GF9992@Sun.COM> References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@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: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 01:04:45 -0000 On Mon, Mar 02, 2009 at 07:44:00PM -0500, Stephen Kent wrote: > At 2:56 PM -0600 3/2/09, Nicolas Williams wrote: > >Perhaps the simplest fix, technologically speaking, would be to get a > >real PKI -- no technical changes needed, just political ones. But that > >strikes me as politically infeasible. > > > >A real PKI would imply: > > > > - trust anchor regulations > > - CA and DNS registrar regulations that work > > As I noted in the message I sent (which crossed in the ether) this is > not uncommon in Asia. For example, CAs have to be licensed by the > government in India (and, I think, South Korea). > > But in the EU and U.S., we have a laisse fare approach to CA > regulation. That is a political issue. Indeed. As I said, I suspect it's a difficult political issue, but then, perhaps it's not. I'm not sure how to gauge the likelihood of success of CA, registrart and browser trust anchor regulation, both as a political proposal, and if implemented (once implemented we'll know though :) From Pasi.Eronen@nokia.com Tue Mar 3 01:47:13 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C983A6908; Tue, 3 Mar 2009 01:47:13 -0800 (PST) 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.076, 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 Z0JUqpATFiQV; Tue, 3 Mar 2009 01:47:12 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8EF963A67E7; Tue, 3 Mar 2009 01:47:11 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n239lCJp009547; Tue, 3 Mar 2009 11:47:35 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 11:47:22 +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, 3 Mar 2009 11:47:17 +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, 3 Mar 2009 10:47:09 +0100 From: To: , Date: Tue, 3 Mar 2009 10:47:08 +0100 Thread-Topic: Pasi's AD Notes for February 2009 Thread-Index: Acmb5QOdXrbuN9VMT6yMP5mPZ4bxiA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA57C871@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2009 09:47:17.0625 (UTC) FILETIME=[0A1CDE90:01C99BE5] X-Nokia-AV: Clean Subject: [saag] Pasi's AD Notes for February 2009 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 09:47:13 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] WORKING GROUPS DKIM - Lot of discussion about draft-ietf-dkim-rfc4871-errata=20 (and I haven't read all the emails). - draft-ietf-dkim-ssp: waiting for the errata dust to settle. - draft-ietf-dkim-overview: I sent my AD review comments;=20 waiting for comments/revised ID [since 2009-02-27] - Waiting for WG to send list of RFC errata IDs (the current ones not related to d=3D/i=3D) the WG agrees on. EMU - draft-ietf-emu-gpsk: now published as RFC 5433 - Discussions about EAP-FAST and EAP-MSCHAPv2 IPSECME - (not WG document) draft-bellovin-useipsec was published as RFC 5406 - draft-ietf-ipsecme-ikev2-redirect went to WGLC ISMS - I hope we're ready to start IETF Last Call very soon KEYPROV - PSKC went to WGLC - IPR disclosure from VeriSign=20 PKIX - Note: I'm shepherding two PKIX drafts where Tim is a co-author - draft-ietf-pkix-ecc-subpubkeyinfo: in RFC Editor queue/AUTH48 --=20 waiting for Sean to get 5378 OK from Microsoft [since 2009-02-07] - draft-ietf-pkix-rfc4055-update: changes needed to address the discusses agreed; waiting for authors to submit a revised ID [since 2009-02-10] SASL - Lot of discussion about SCRAM/GS2 SYSLOG - The main WG documents should come out as RFC 542x any day now - draft-ietf-syslog-sign: I finally reviewed version -24 (apologies for taking so long), and sent my remaining comments (which should=20 be easy to handle); waiting for the authors to submit a revised=20 ID before starting IEF Last Call [since 2009-02-05] TLS - draft-ietf-tls-des-idea: now published as RFC 5469 - draft-ietf-tls-ecdhe-psk: was approved by IESG; now in RFC=20 Editor queue - draft-ietf-tls-psk-new-mac-aes-gcm: now in RFC Editor queue - Verified errata #1585 for RFC 5246 - The tls-authz saga continues... OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: now that -00 was posted, I have promised to comment and contribute. - draft-ietf-mpls-mpls-and-gmpls-security-framework: I've promised to read this. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-ietf-bfd-base: version -09 addressed some of my concerns, but not all -- waiting for authors to reply or submit a revised=20 ID [since 2009-02-13] - draft-ietf-calsify-rfc2445bis: waiting for authors to reply to my comment [since 2009-02-02] - draft-ietf-dime-qos-parameters: waiting for authors to propose text or submit a revised ID [since 2009-02-26] - draft-ietf-enum-combined: waiting for authors to reply if they're OK with proposed text [since 2009-02-26] - draft-ietf-idr-flow-spec: waiting for authors to submit=20 a revised ID [since 2009-02-13] - draft-ietf-l2tpext-tdm: waiting for Mark to do something about the downref [since 2009-02-07] - draft-ietf-roll-urban-routing-reqs: version -04 addressed many of my comments; waiting for authors to propose text for the remaining ones [since 2009-02-06] - draft-ietf-softwire-encaps-ipsec: waiting for me to read Lou's email about pre-created SAs [since 2009-02-23]; waiting for the authors to reply about IKE initiator authentication [since 2009-02-23] - draft-ietf-softwire-hs-framework-l2tpv2: waiting for me to read Carlos's email [since 2009-02-26] - draft-igoe-secsh-aes-gcm: waiting for Tim to propose solution to FIPS validation problem and solicit opinions from others=20 [since 2009-02-20] - draft-stjohns-sipso: I think we might have rough agreement on changes;=20 waiting for authors to submit a revised ID [since 2009-02-26] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] - draft-ietf-monami6-multiplecoa: some text agreed, waiting for authors to reply to my remaining comments [since 2009-01-28] - draft-ietf-ospf-lls: waiting for a revised ID or RFC Editor Notes to address my remaining comments [since 2009-01-19] - draft-ietf-radext-management-authorization: waiting for authors to reply to my comments [since 2009-01-28] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] - draft-ietf-sip-xcapevent: waiting for revised ID or RFC Editor Note to fix the ABNF/XML bugs [since 2008-10-24] - draft-ietf-sipping-policy-package: waiting for more information from Mary or Jon [since 2008-10-28] --end--= From Pasi.Eronen@nokia.com Tue Mar 3 04:58:12 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1D228C297 for ; Tue, 3 Mar 2009 04:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 OwYARtSNLb8Z for ; Tue, 3 Mar 2009 04:58:10 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 170463A6970 for ; Tue, 3 Mar 2009 04:57:41 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n23Cvt6u008662; Tue, 3 Mar 2009 14:58:05 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 14:58:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 14:57:57 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 3 Mar 2009 13:57:56 +0100 From: To: Date: Tue, 3 Mar 2009 13:57:53 +0100 Thread-Topic: Deployment Deadlock Thread-Index: AcmYH9sURUVD4BchSiSzrk0/zbdjzQAABw37APe5+4A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727EA57CAF1@NOK-EUMSG-01.mgdnok.nokia.com> References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com> <0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com> <2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com> <20090226143809.GF7227@mit.edu> <2788466ED3E31C418E9ACC5C3166155768B2D2@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2D2@mou1wnexmb09.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB7727EA57CAF1NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2009 12:57:57.0373 (UTC) FILETIME=[ACBBE2D0:01C99BFF] X-Nokia-AV: Clean Cc: saag@ietf.org Subject: Re: [saag] Deployment Deadlock X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 12:58:13 -0000 --_000_808FD6E27AD4884E94820BC333B2DB7727EA57CAF1NOKEUMSG01mgd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phillip, Would allowing a single certificate to be signed with multiple algorithms s= olve some of the problem? Doing it in backwards-compatible way (=3Dcurrent browsers just use the SHA1= signature, and ignore the others) probably would involve violating some pr= istine ASN.1 style guidelines, though :-) (The "obvious" place to put the "= other signatures" is a certificate extension, added after the "real" extens= ions.) But would this significantly help solving the transition problem? (Perhaps = something like this has been proposed before -- I haven't really thought ab= out the potential pitfalls here.) Best regards, Pasi ________________________________ From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of ext= Hallam-Baker, Phillip Sent: 26 February, 2009 17:33 To: Theodore Tso Cc: der Mouse; saag@ietf.org Subject: [saag] Deployment Deadlock Ted, Thanks for the comments. I agree that this is really hard, but I do not think that tragedy of the co= mmons is a good analogy. This is not a resource depletion issue. This is mo= re like a prisoner's dilema issue in which following their own best short t= erm interests causes everyone to end up with a worst-case result. Unlike th= e Axelrod prisoner's dilema, the problem does not go away when the game is = played repeatedly. On the contrary the deadlock becomes tighter. The reason that this is our problem is that the standards establish the set= of options available to the parties and the values of the outcomes. The good part is that if we can understand this issue and work out a system= atic theory of how to address it we have a key that can unlock the deployme= nt of other protocols - IPv6, ubiquitous IPSec, ubiquitous email encryption= and so on. We have encountered deployment deadlock in various forms in many different = protocols. We have a lot of experience of deployment deadlock but no system= atic theory. I think that we can develop an adequate theory for the purpose= s of protocol design by borrowing some ideas from the economists, in partic= ular rational choice theory. In rational choice theory we model the behavior of each party by *assuming*= that they will follow their exclusive best interests. I emphasize the word assume here as it is merely a modelling assumption and= not a factual claim or a normative ethic. I do not want to get into a dist= raction about whether the Rat Choice modelling assumption is a normative tr= uth. We are merely using it here as a modelling assumption, we do not need = to enter into a politcal digression. While it is very clear that some peopl= e act from altruistic motives on some occasions, and we could model this, i= t is necessary to assume an improbable degree of altruism to affect the out= come. What I did was to identify the parties: 1) Web browser providers 2) Certificate Authorities 3) Merchants I am using merchants as a subset of certificate holders to simplify matters= . While it may be argued that other certificate users will behave different= ly, the merchants are a large enough subset that their actions are sufficie= nt to determine the behavior of the CAs. Note that these parties are listed in a particular order. The IETF has the = greatest ability to communicate with the Web browser providers, somewhat le= ss contact with CAs and has negligible contact with the merchants. As a pra= gmatic matter it is much easier to change IETF specs than to mount an Al Go= re publicity campaign telling folk to move to SHA-n. And in any case we hav= e a very limited amount of jawboning bandwidth and we have to use that as a= last resort. I would much rather have Vint Cerf jawboning carriers into su= pport for IPv6. >From a business perspective, the actions are determined in the reverse orde= r. The CAs are driven by the demands of their customers. If any CA attempts= to behave altruistically by refusing to supply a product demanded by the m= erchants they will lose business. In practice the actions of the Web browse= r providers are driven by the facts on the ground in the same way. The facts on the ground in question are 1) The amount of business that merchants receive from browsers that do not = support SHA-n 2) The number of merchants who deploy SHA-n certificates We have some influence on the first factor but almost no influence on the s= econd. At this point it is reasonably clear that the browser providers are = either supporting SHA2 today or will do so in the very very near future. If= not they risk public shame every time RSA and Crypto come round. My problem is that based on my experience of the merchants, I cannot see an= y merchant voluntarily chosing a SHA-n certificate that provides only (100-= x)% coverage while there is a SHA-1 certificate on offer that gives 100% fo= r values of x greater than 2. No business is going to voluntarily sacrifice= even 1% of sales for a security issue that only affects the credit card is= suers. And there is no way for the browser providers to withdraw support for SHA1 = if 90% or more of merchants are using SHA1 certs. Not without proof-positiv= e that an actual break has occured which by definition means that we are to= o late. And even then it will take several years for the SHA1 capable brows= ers to be withdrawn from service and those will still be vulnerable in the = interim. That is a deployment deadlock. ________________________________ From: Theodore Tso [mailto:tytso@mit.edu] Sent: Thu 2/26/2009 9:38 AM To: Hallam-Baker, Phillip Cc: David Harrington; der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote: > > If people really think that Amazon.com is going to say 'I know that > only 95% of browsers support SHA1, but I am going to get an SHA2 > cert and lose that 5% of sales so that our transactions are as > secure as possible' because someone finds a practical attack on > SHA1, then let them say that. So far nobody has challenged the > analysis directly, they have merely described themselves as > unconvinced that there is a problem. > OK, so let's get real here. The reality is that transitioning between crypto algorithms is *hard*, and that the tragedy of the commons is hitting us hard. We can try to create technical solutions (such as the Svengali-style suicide note which causes browsers to break intranets), but their have shortcomings because this is fundamentally a social problem. There are couple of things we need to do in order to successfully carry off a migration: (1) We need to get browsers to add support for the new crypto algorithm (2) We need to get users to upgrade to the new browsers with support for the new crypto algorithm (3) Once (1) and (2) are done, we need to get secure commerce sites to upgrade to use certificates that utilize the new crypto algorithm. (In practice this will be the crypto checksum; but the same thing applies if we ever need to get nervous about replacing the PK algorithm.) This normally takes time --- years, but it is possible to speed things up. For example, an interested body, perhaps funded by far-sighted merchants and other concerned citizens, could track which browsers have added the new algorithms, and jawbone (and perhaps in the later part of the effort, publically shame) entities distributing browsers to implement the new algorithm. For (2), sites who were interested in being "good citizens" could test to see if the browser supports the new crypto algorithm, and display a "nag screen" if the browser apparently doesn't support the new crypto algorithm. Said nag message could be gentle at first, but could get increasingly strident; a lot of this would be up to the web site(s) involved, of course. So it's possible to encourage the ecosystem to move in a particular way, but it all requires effort and coordination, and the tragedy of the commons is that until the emergency comes up, it's unlikely that such an effort will get funding and support. But again, this is all nothing new, and I suspect one of the reasons why we're thrashing a little in this discussion is because it really is much more of a social problem than a technical problem, which means it's a bit outside of the IETF's core competency. - Ted --_000_808FD6E27AD4884E94820BC333B2DB7727EA57CAF1NOKEUMSG01mgd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] SHA-1 to SHA-n transition
Phillip,
 
Would allowing a single certificate to be signed= with=20 multiple algorithms solve some of the problem?
 
Doing it in backwards-comp= atible way=20 (=3Dcurrent browsers just use the SHA1 signature, and ignore the others) pr= obably=20 would involve violating some pristi= ne=20 ASN.1 style guidelines, though :-)=20 (The "obvious" place to=20 put the "other signatures" is a=20 certificate extension, added= after=20 the "real" extensions.)
 
But would this significant= ly help=20 solving the transition problem? (Pe= rhaps=20 something like this has been proposed before -- I haven't really thought about the potential pitfa= lls=20 here.)
 
Best=20 regards,
Pasi

From: saag-bounces@ietf.org=20 [mailto:saag-bounces@ietf.org] On Behalf Of ext Hallam-Baker,=20 Phillip
Sent: 26 February, 2009 17:33
To: Theodore=20 Tso
Cc: der Mouse; saag@ietf.org
Subject: [saag]=20 Deployment Deadlock

Ted,
 
Thanks for the comments.
 
I agree that this is really ha= rd, but I=20 do not think that tragedy of the commons is a good analogy. This is not a= =20 resource depletion issue. This is more like a prisoner's dilema issue in = which=20 following their own best short term interests causes everyone to end up w= ith a=20 worst-case result. Unlike the Axelrod prisoner's dilema, the problem does= not=20 go away when the game is played repeatedly. On the contrary the deadlock= =20 becomes tighter.
 
The reason that this is our pr= oblem is=20 that the standards establish the set of options available to the parties = and=20 the values of the outcomes.
 
The good part is that if we ca= n=20 understand this issue and work out a systematic theory of how to address = it we=20 have a key that can unlock the deployment of other protocols - IPv6,=20 ubiquitous IPSec, ubiquitous email encryption and so on.
 
 
We have encountered deployment= deadlock=20 in various forms in many different protocols. We have a lot of experience= of=20 deployment deadlock but no systematic theory. I think that we can develop= an=20 adequate theory for the purposes of protocol design by borrowing some ide= as=20 from the economists, in particular rational choice theory.
 
In rational choice theory we m= odel the=20 behavior of each party by *assuming* that they will follow their exclusiv= e=20 best interests.
 
I emphasize the word assume he= re as it is=20 merely a modelling assumption and not a factual claim or a normative=20 ethic. I do not want to get into a distraction about whether the Rat= =20 Choice modelling assumption is a normative truth. We are merely usin= g it=20 here as a modelling assumption, we do not need to enter into a politcal=20 digression. While it is very clear that some people act from altruistic=20 motives on some occasions, and we could model this, it is necessary to as= sume=20 an improbable degree of altruism to affect the outcome.
 
 
What I did was to identify the= =20 parties:
 
1) Web browser=20 providers
2) Certificate Authorities
3) Merchants
 
I am using merchants as a subs= et of=20 certificate holders to simplify matters. While it may be argued that othe= r=20 certificate users will behave differently, the merchants are a large enou= gh=20 subset that their actions are sufficient to determine the behavior of the= =20 CAs.
 
Note that these parties are li= sted in a=20 particular order. The IETF has the greatest ability to communicate with t= he=20 Web browser providers, somewhat less contact with CAs and has negligible= =20 contact with the merchants. As a pragmatic matter it is much easier to ch= ange=20 IETF specs than to mount an Al Gore publicity campaign telling folk to mo= ve to=20 SHA-n. And in any case we have a very limited amount of jawboning bandwid= th=20 and we have to use that as a last resort. I would much rather have Vint C= erf=20 jawboning carriers into support for IPv6.
 
From a business perspective, t= he actions=20 are determined in the reverse order. The CAs are driven by the demands of= =20 their customers. If any CA attempts to behave altruistically by refusing = to=20 supply a product demanded by the merchants they will lose business. In=20 practice the actions of the Web browser providers are driven by the facts= on=20 the ground in the same way.
 
The facts on the ground in que= stion=20 are
 
1) The amount of business that= merchants=20 receive from browsers that do not support SHA-n
2) The number of merchants who= deploy=20 SHA-n certificates
 
We have some influence on the = first=20 factor but almost no influence on the second. At this point it is reasona= bly=20 clear that the browser providers are either supporting SHA2 today or will= do=20 so in the very very near future. If not they risk public shame every time= RSA=20 and Crypto come round.
 
My problem is that based on my= experience=20 of the merchants, I cannot see any merchant voluntarily chosing a SHA-n=20 certificate that provides only (100-x)% coverage while there is a SH= A-1=20 certificate on offer that gives 100% for values of x greater than 2. No=20 business is going to voluntarily sacrifice even 1% of sales for a=20 security issue that only affects the credit card issuers.
 
And there is no way for the br= owser=20 providers to withdraw support for SHA1 if 90% or more of merchants are us= ing=20 SHA1 certs. Not without proof-positive that an actual break has occured w= hich=20 by definition means that we are too late. And even then it will take seve= ral=20 years for the SHA1 capable browsers to be withdrawn from service and thos= e=20 will still be vulnerable in the interim.
 
 
That is a deployment=20 deadlock.
 
 
From: Theodore Tso=20 [mailto:tytso@mit.edu]
Sent: Thu 2/26/2009 9:38 AM
To:=20 Hallam-Baker, Phillip
Cc: David Harrington; der Mouse;=20 saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n=20 transition

On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker,= =20 Phillip wrote:
> 
> If people really think that Amazon.c= om is=20 going to say 'I know that
> only 95% of browsers support SHA1, but = I am=20 going to get an SHA2
> cert and lose that 5% of sales so that our=20 transactions are as
> secure as possible' because someone finds a=20 practical attack on
> SHA1, then let them say that. So far nobody h= as=20 challenged the
> analysis directly, they have merely described=20 themselves as
> unconvinced that there is a=20 problem.
> 

OK, so let's get real here.  The reali= ty is=20 that transitioning between
crypto algorithms is *hard*, and that the=20 tragedy of the commons is
hitting us hard.  We can try to create= =20 technical solutions (such as
the Svengali-style suicide note which cau= ses=20 browsers to break
intranets), but their have shortcomings because this= is=20 fundamentally
a social problem.

There are couple of things we n= eed=20 to do in order to successfully
carry off a migration:

(1) We ne= ed to=20 get browsers to add support for the new crypto algorithm
(2) We need t= o get=20 users to upgrade to the new browsers with=20 support
        for the new crypto= =20 algorithm
(3) Once (1) and (2) are done, we need to get secure commerc= e=20 sites to
        upgrade to use=20 certificates that utilize the new crypto=20 algorithm.
        (In practice thi= s=20 will be the crypto checksum; but the same=20 thing
        applies if we ever ne= ed to=20 get nervous about replacing the=20 PK
        algorithm.)

This= =20 normally takes time --- years, but it is possible to speed things
up.&= nbsp;=20 For example, an interested body, perhaps funded by far-sighted
merchan= ts=20 and other concerned citizens, could track which browsers
have added th= e new=20 algorithms, and jawbone (and perhaps in the later
part of the effort,= =20 publically shame) entities distributing browsers
to implement the new= =20 algorithm.

For (2), sites who were interested in being "good citiz= ens"=20 could test
to see if the browser supports the new crypto algorithm, an= d=20 display a
"nag screen" if the browser apparently doesn't support the n= ew=20 crypto
algorithm.  Said nag message could be gentle at first, but= =20 could get
increasingly strident; a lot of this would be up to the web= =20 site(s)
involved, of course.

So it's possible to encourage the= =20 ecosystem to move in a particular
way, but it all requires effort and= =20 coordination, and the tragedy of
the commons is that until the emergen= cy=20 comes up, it's unlikely that
such an effort will get funding and=20 support. 

But again, this is all nothing new, and I suspect o= ne of=20 the reasons
why we're thrashing a little in this discussion is because= it=20 really
is much more of a social problem than a technical problem, whic= h=20 means
it's a bit outside of the IETF's core=20 competency.

       =20        =20        =20        =20         -=20 Ted

--_000_808FD6E27AD4884E94820BC333B2DB7727EA57CAF1NOKEUMSG01mgd_-- From pbaker@verisign.com Tue Mar 3 05:35:29 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AAF83A6C56 for ; Tue, 3 Mar 2009 05:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.533 X-Spam-Level: X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 GLaS9I2FjmqO for ; Tue, 3 Mar 2009 05:35:27 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 54D563A6C54 for ; Tue, 3 Mar 2009 05:35:27 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n23DBIS7001250; Tue, 3 Mar 2009 05:11:18 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:35:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C04.F8C420F2" Date: Tue, 3 Mar 2009 05:35:52 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2EA@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deployment Deadlock Thread-Index: AcmYH9sURUVD4BchSiSzrk0/zbdjzQAABw37APe5+4AAAERU/w== References: <2788466ED3E31C418E9ACC5C3166155768B2CB@mou1wnexmb09.vcorp.ad.vrsn.com><0c2301c9979f$8a1cd770$0600a8c0@china.huawei.com><2788466ED3E31C418E9ACC5C3166155768B2CE@mou1wnexmb09.vcorp.ad.vrsn.com><20090226143809.GF7227@mit.edu> <2788466ED3E31C418E9ACC5C3166155768B2D2@mou1wnexmb09.vcorp.ad.vrsn.com> <808FD6E27AD4884E94820BC333B2DB7727EA57CAF1@NOK-EUMSG-01.mgdnok.nokia.com> From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 03 Mar 2009 13:35:53.0863 (UTC) FILETIME=[F9A0B170:01C99C04] Cc: saag@ietf.org Subject: Re: [saag] Deployment Deadlock X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 13:35:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C04.F8C420F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is another option. But the cost is that every cert now has to carry = 512 bytes of extra baggage per algorithm. And this scheme is not so = responsive as any change has a lead time of the lifetime of the longest = certs - 2 or 3 years. That scheme works a lot better if you have ECC = crypto available. There are many ways that this can be addressed. But all of the ones I = have thought of so far are somewhat yukky. That is why I wanted to focus = on the fact that we have a problem before we jumped to solutions. So far I do not see anyone giving a substantive argument that the = deployment deadlock effect will not be a problem. I do see statements to = the effect that this is a problem that some people would like not to = have to think about or rule out of scope. And we go through these = arguments every single time someone suggests even thinking about real = world deployment constraints in a specification no matter how they are = put. We have the same problem in the DKIM spec. Take a look at how deployed = verifiers will react when a zone contains a key for an algorithm that = the verifier is unable to process. It is impossible for a verifier to = react correctly in that situation without additional information. = Publishing one unsupported key effectively negates the effect of the = policy. So nobody can deploy new keys without a new policy language. But = nobody in the group wants to think about that issue because it is the = product of an interaction between policy and signature and the group = wanted to keep them in two separate little boxes and hope they did not = affect each other. -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tue 3/3/2009 7:57 AM To: Hallam-Baker, Phillip Cc: saag@ietf.org Subject: RE: Deployment Deadlock =20 Phillip, =20 Would allowing a single certificate to be signed with multiple = algorithms solve some of the problem? =20 Doing it in backwards-compatible way (=3Dcurrent browsers just use the = SHA1 signature, and ignore the others) probably would involve violating = some pristine ASN.1 style guidelines, though :-) (The "obvious" place to = put the "other signatures" is a certificate extension, added after the = "real" extensions.) =20 But would this significantly help solving the transition problem? = (Perhaps something like this has been proposed before -- I haven't = really thought about the potential pitfalls here.) =20 Best regards, Pasi ________________________________ From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of = ext Hallam-Baker, Phillip Sent: 26 February, 2009 17:33 To: Theodore Tso Cc: der Mouse; saag@ietf.org Subject: [saag] Deployment Deadlock =09 =09 Ted, =20 Thanks for the comments. =20 I agree that this is really hard, but I do not think that tragedy of = the commons is a good analogy. This is not a resource depletion issue. = This is more like a prisoner's dilema issue in which following their own = best short term interests causes everyone to end up with a worst-case = result. Unlike the Axelrod prisoner's dilema, the problem does not go = away when the game is played repeatedly. On the contrary the deadlock = becomes tighter. =20 The reason that this is our problem is that the standards establish the = set of options available to the parties and the values of the outcomes. =20 The good part is that if we can understand this issue and work out a = systematic theory of how to address it we have a key that can unlock the = deployment of other protocols - IPv6, ubiquitous IPSec, ubiquitous email = encryption and so on. =20 =20 We have encountered deployment deadlock in various forms in many = different protocols. We have a lot of experience of deployment deadlock = but no systematic theory. I think that we can develop an adequate theory = for the purposes of protocol design by borrowing some ideas from the = economists, in particular rational choice theory. =20 In rational choice theory we model the behavior of each party by = *assuming* that they will follow their exclusive best interests.=20 =20 I emphasize the word assume here as it is merely a modelling assumption = and not a factual claim or a normative ethic. I do not want to get into = a distraction about whether the Rat Choice modelling assumption is a = normative truth. We are merely using it here as a modelling assumption, = we do not need to enter into a politcal digression. While it is very = clear that some people act from altruistic motives on some occasions, = and we could model this, it is necessary to assume an improbable degree = of altruism to affect the outcome. =20 =20 What I did was to identify the parties: =20 1) Web browser providers 2) Certificate Authorities 3) Merchants =20 I am using merchants as a subset of certificate holders to simplify = matters. While it may be argued that other certificate users will behave = differently, the merchants are a large enough subset that their actions = are sufficient to determine the behavior of the CAs. =20 Note that these parties are listed in a particular order. The IETF has = the greatest ability to communicate with the Web browser providers, = somewhat less contact with CAs and has negligible contact with the = merchants. As a pragmatic matter it is much easier to change IETF specs = than to mount an Al Gore publicity campaign telling folk to move to = SHA-n. And in any case we have a very limited amount of jawboning = bandwidth and we have to use that as a last resort. I would much rather = have Vint Cerf jawboning carriers into support for IPv6. =20 From a business perspective, the actions are determined in the reverse = order. The CAs are driven by the demands of their customers. If any CA = attempts to behave altruistically by refusing to supply a product = demanded by the merchants they will lose business. In practice the = actions of the Web browser providers are driven by the facts on the = ground in the same way. =20 The facts on the ground in question are =20 1) The amount of business that merchants receive from browsers that do = not support SHA-n 2) The number of merchants who deploy SHA-n certificates =20 We have some influence on the first factor but almost no influence on = the second. At this point it is reasonably clear that the browser = providers are either supporting SHA2 today or will do so in the very = very near future. If not they risk public shame every time RSA and = Crypto come round. =20 My problem is that based on my experience of the merchants, I cannot = see any merchant voluntarily chosing a SHA-n certificate that provides = only (100-x)% coverage while there is a SHA-1 certificate on offer that = gives 100% for values of x greater than 2. No business is going to = voluntarily sacrifice even 1% of sales for a security issue that only = affects the credit card issuers. =20 And there is no way for the browser providers to withdraw support for = SHA1 if 90% or more of merchants are using SHA1 certs. Not without = proof-positive that an actual break has occured which by definition = means that we are too late. And even then it will take several years for = the SHA1 capable browsers to be withdrawn from service and those will = still be vulnerable in the interim. =20 =20 That is a deployment deadlock. =20 =20 ________________________________ From: Theodore Tso [mailto:tytso@mit.edu] Sent: Thu 2/26/2009 9:38 AM To: Hallam-Baker, Phillip Cc: David Harrington; der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =09 =09 On Wed, Feb 25, 2009 at 05:35:04PM -0800, Hallam-Baker, Phillip wrote: >=20 > If people really think that Amazon.com is going to say 'I know that > only 95% of browsers support SHA1, but I am going to get an SHA2 > cert and lose that 5% of sales so that our transactions are as > secure as possible' because someone finds a practical attack on > SHA1, then let them say that. So far nobody has challenged the > analysis directly, they have merely described themselves as > unconvinced that there is a problem. >=20 =09 OK, so let's get real here. The reality is that transitioning between crypto algorithms is *hard*, and that the tragedy of the commons is hitting us hard. We can try to create technical solutions (such as the Svengali-style suicide note which causes browsers to break intranets), but their have shortcomings because this is fundamentally a social problem. =09 There are couple of things we need to do in order to successfully carry off a migration: =09 (1) We need to get browsers to add support for the new crypto algorithm (2) We need to get users to upgrade to the new browsers with support for the new crypto algorithm (3) Once (1) and (2) are done, we need to get secure commerce sites to upgrade to use certificates that utilize the new crypto = algorithm. (In practice this will be the crypto checksum; but the same = thing applies if we ever need to get nervous about replacing the PK algorithm.) =09 This normally takes time --- years, but it is possible to speed things up. For example, an interested body, perhaps funded by far-sighted merchants and other concerned citizens, could track which browsers have added the new algorithms, and jawbone (and perhaps in the later part of the effort, publically shame) entities distributing browsers to implement the new algorithm. =09 For (2), sites who were interested in being "good citizens" could test to see if the browser supports the new crypto algorithm, and display a "nag screen" if the browser apparently doesn't support the new crypto algorithm. Said nag message could be gentle at first, but could get increasingly strident; a lot of this would be up to the web site(s) involved, of course. =09 So it's possible to encourage the ecosystem to move in a particular way, but it all requires effort and coordination, and the tragedy of the commons is that until the emergency comes up, it's unlikely that such an effort will get funding and support.=20 =09 But again, this is all nothing new, and I suspect one of the reasons why we're thrashing a little in this discussion is because it really is much more of a social problem than a technical problem, which means it's a bit outside of the IETF's core competency. =09 - Ted =09 ------_=_NextPart_001_01C99C04.F8C420F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Deployment Deadlock

That is another option. But the cost is that every = cert now has to carry 512 bytes of extra baggage per algorithm. And this = scheme is not so responsive as any change has a lead time of the = lifetime of the longest certs - 2 or 3 years. That scheme works a lot = better if you have ECC crypto available.

There are many ways that this can be addressed. But all of the ones I = have thought of so far are somewhat yukky. That is why I wanted to focus = on the fact that we have a problem before we jumped to solutions.


So far I do not see anyone giving a substantive argument that the = deployment deadlock effect will not be a problem. I do see statements to = the effect that this is a problem that some people would like not to = have to think about or rule out of scope. And we go through these = arguments every single time someone suggests even thinking about real = world deployment constraints in a specification no matter how they are = put.

We have the same problem in the DKIM spec. Take a look at how deployed = verifiers will react when a zone contains a key for an algorithm that = the verifier is unable to process. It is impossible for a verifier to = react correctly in that situation without additional information. = Publishing one unsupported key effectively negates the effect of the = policy. So nobody can deploy new keys without a new policy language. But = nobody in the group wants to think about that issue because it is the = product of an interaction between policy and signature and the group = wanted to keep them in two separate little boxes and hope they did not = affect each other.


-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tue 3/3/2009 7:57 AM
To: Hallam-Baker, Phillip
Cc: saag@ietf.org
Subject: RE: Deployment Deadlock

Phillip,

Would allowing a single certificate to be signed with multiple = algorithms solve some of the problem?

Doing it in backwards-compatible way (=3Dcurrent browsers just use the = SHA1 signature, and ignore the others) probably would involve violating = some pristine ASN.1 style guidelines, though :-) (The = "obvious" place to put the "other signatures" is a = certificate extension, added after the "real" extensions.)

But would this significantly help solving the transition problem? = (Perhaps something like this has been proposed before -- I haven't = really thought about the potential pitfalls here.)

Best regards,
Pasi




________________________________

        From: saag-bounces@ietf.org = [mailto:saag-bounces@ietf.org] = On Behalf Of ext Hallam-Baker, Phillip
        Sent: 26 February, 2009 = 17:33
        To: Theodore Tso
        Cc: der Mouse; = saag@ietf.org
        Subject: [saag] Deployment = Deadlock
       
       
        Ted,
        
        Thanks for the comments.
        
        I agree that this is really = hard, but I do not think that tragedy of the commons is a good analogy. = This is not a resource depletion issue. This is more like a prisoner's = dilema issue in which following their own best short term interests = causes everyone to end up with a worst-case result. Unlike the Axelrod = prisoner's dilema, the problem does not go away when the game is played = repeatedly. On the contrary the deadlock becomes tighter.
        
        The reason that this is our = problem is that the standards establish the set of options available to = the parties and the values of the outcomes.
        
        The good part is that if we = can understand this issue and work out a systematic theory of how to = address it we have a key that can unlock the deployment of other = protocols - IPv6, ubiquitous IPSec, ubiquitous email encryption and so = on.
        
        
        We have encountered = deployment deadlock in various forms in many different protocols. We = have a lot of experience of deployment deadlock but no systematic = theory. I think that we can develop an adequate theory for the purposes = of protocol design by borrowing some ideas from the economists, in = particular rational choice theory.
        
        In rational choice theory we = model the behavior of each party by *assuming* that they will follow = their exclusive best interests.
        
        I emphasize the word assume = here as it is merely a modelling assumption and not a factual claim or a = normative ethic. I do not want to get into a distraction about whether = the Rat Choice modelling assumption is a normative truth. We are merely = using it here as a modelling assumption, we do not need to enter into a = politcal digression. While it is very clear that some people act from = altruistic motives on some occasions, and we could model this, it is = necessary to assume an improbable degree of altruism to affect the = outcome.
        
        
        What I did was to identify = the parties:
        
        1) Web browser providers
        2) Certificate = Authorities
        3) Merchants
        
        I am using merchants as a = subset of certificate holders to simplify matters. While it may be = argued that other certificate users will behave differently, the = merchants are a large enough subset that their actions are sufficient to = determine the behavior of the CAs.
        
        Note that these parties are = listed in a particular order. The IETF has the greatest ability to = communicate with the Web browser providers, somewhat less contact with = CAs and has negligible contact with the merchants. As a pragmatic matter = it is much easier to change IETF specs than to mount an Al Gore = publicity campaign telling folk to move to SHA-n. And in any case we = have a very limited amount of jawboning bandwidth and we have to use = that as a last resort. I would much rather have Vint Cerf jawboning = carriers into support for IPv6.
        
        From a business perspective, = the actions are determined in the reverse order. The CAs are driven by = the demands of their customers. If any CA attempts to behave = altruistically by refusing to supply a product demanded by the merchants = they will lose business. In practice the actions of the Web browser = providers are driven by the facts on the ground in the same way.
        
        The facts on the ground in = question are
        
        1) The amount of business = that merchants receive from browsers that do not support SHA-n
        2) The number of merchants = who deploy SHA-n certificates
        
        We have some influence on the = first factor but almost no influence on the second. At this point it is = reasonably clear that the browser providers are either supporting SHA2 = today or will do so in the very very near future. If not they risk = public shame every time RSA and Crypto come round.
        
        My problem is that based on = my experience of the merchants, I cannot see any merchant voluntarily = chosing a SHA-n certificate that provides only (100-x)% coverage while = there is a SHA-1 certificate on offer that gives 100% for values of x = greater than 2. No business is going to voluntarily sacrifice even 1% of = sales for a security issue that only affects the credit card = issuers.
        
        And there is no way for the = browser providers to withdraw support for SHA1 if 90% or more of = merchants are using SHA1 certs. Not without proof-positive that an = actual break has occured which by definition means that we are too late. = And even then it will take several years for the SHA1 capable browsers = to be withdrawn from service and those will still be vulnerable in the = interim.
        
        
        That is a deployment = deadlock.
        
        
________________________________

        From: Theodore Tso [mailto:tytso@mit.edu]
        Sent: Thu 2/26/2009 9:38 = AM
        To: Hallam-Baker, Phillip
        Cc: David Harrington; der = Mouse; saag@ietf.org
        Subject: Re: [saag] SHA-1 to = SHA-n transition
       
       

        On Wed, Feb 25, 2009 at = 05:35:04PM -0800, Hallam-Baker, Phillip wrote:
        >
        > If people really think = that Amazon.com is going to say 'I know that
        > only 95% of browsers = support SHA1, but I am going to get an SHA2
        > cert and lose that 5% of = sales so that our transactions are as
        > secure as possible' = because someone finds a practical attack on
        > SHA1, then let them say = that. So far nobody has challenged the
        > analysis directly, they = have merely described themselves as
        > unconvinced that there = is a problem.
        >
       
        OK, so let's get real = here.  The reality is that transitioning between
        crypto algorithms is *hard*, = and that the tragedy of the commons is
        hitting us hard.  We can = try to create technical solutions (such as
        the Svengali-style suicide = note which causes browsers to break
        intranets), but their have = shortcomings because this is fundamentally
        a social problem.
       
        There are couple of things we = need to do in order to successfully
        carry off a migration:
       
        (1) We need to get browsers = to add support for the new crypto algorithm
        (2) We need to get users to = upgrade to the new browsers with support
        =         for the new crypto = algorithm
        (3) Once (1) and (2) are = done, we need to get secure commerce sites to
        =         upgrade to use certificates = that utilize the new crypto algorithm.
        =         (In practice this will be the = crypto checksum; but the same thing
        =         applies if we ever need to = get nervous about replacing the PK
        =         algorithm.)
       
        This normally takes time --- = years, but it is possible to speed things
        up.  For example, an = interested body, perhaps funded by far-sighted
        merchants and other concerned = citizens, could track which browsers
        have added the new = algorithms, and jawbone (and perhaps in the later
        part of the effort, = publically shame) entities distributing browsers
        to implement the new = algorithm.
       
        For (2), sites who were = interested in being "good citizens" could test
        to see if the browser = supports the new crypto algorithm, and display a
        "nag screen" if the = browser apparently doesn't support the new crypto
        algorithm.  Said nag = message could be gentle at first, but could get
        increasingly strident; a lot = of this would be up to the web site(s)
        involved, of course.
       
        So it's possible to encourage = the ecosystem to move in a particular
        way, but it all requires = effort and coordination, and the tragedy of
        the commons is that until the = emergency comes up, it's unlikely that
        such an effort will get = funding and support.
       
        But again, this is all = nothing new, and I suspect one of the reasons
        why we're thrashing a little = in this discussion is because it really
        is much more of a social = problem than a technical problem, which means
        it's a bit outside of the = IETF's core competency.
       
        =             &= nbsp;           &n= bsp;           &nb= sp;   - Ted
       

------_=_NextPart_001_01C99C04.F8C420F2-- From pbaker@verisign.com Tue Mar 3 06:25:01 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692733A688A for ; Tue, 3 Mar 2009 06:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.147 X-Spam-Level: X-Spam-Status: No, score=-7.147 tagged_above=-999 required=5 tests=[AWL=1.451, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 uuoCNyr8QKJm for ; Tue, 3 Mar 2009 06:25:00 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 4AF723A6887 for ; Tue, 3 Mar 2009 06:25:00 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n23EPIaZ007790; Tue, 3 Mar 2009 06:25:18 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 06:25:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C0B.E0415FCA" Date: Tue, 3 Mar 2009 06:25:17 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) Thread-Index: Acmbe8/toVJcqdjGQuqpi9nb3nzg5AAiyIvR References: <1235663917.3293.16.camel@localhost><20090226165448.GK9992@Sun.COM><20090227022359.8D45150822@romeo.rtfm.com><20090302161134.GG9992@Sun.COM><20090302172135.DA43650822@romeo.rtfm.com><200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu><864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu><20090302182547.GX9992@Sun.COM><0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu><20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> From: "Hallam-Baker, Phillip" To: "Nicolas Williams" , "Jeffrey Hutzelman" X-OriginalArrivalTime: 03 Mar 2009 14:25:18.0106 (UTC) FILETIME=[E07447A0:01C99C0B] Cc: der Mouse , saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:25:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C0B.E0415FCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A PKI does not grow of its own accord. The SSL PKI only exists because = there was a clear business driver that drove its deployment. That is not to say that it is impossible to deploy an alternative = design. Only that it is necessary to model and understand the real world = deployment constraints and design for deployment. And the biggest mistake most designers make is to over-estimate the = extent to which security is actually desired. As far as actual end users = are concerned the SHA-n transition issue is irrelevant, it is even = irrelevant as far as the banks and so on are concerned. Everyone else in = the system expects 'the boffins' to come up with a fix that won't = require them to do too much. In particular, they don't want a solution = that might require them to actually think. The only way that an imminent crisis can lead to large scale concerted = action is if (1) the underlying technical issue is simple enough for = anyone to grasp and (2) those required to act have other motives for = action. The reason that the Y2K scam was so successful was because it = enabled a clique of mediocre corporate VPs to engage in empire building. = After a short while the scam became self-perpetuating because the first = act of a Y2K vampire was to send out letters to every supplier demanding = proof of Y2K certification - and so the infection was spread. You do not need to be an economist or apply fancy algebra to understand = the effects of economic processes. If we are not prepared to try to = understand the economists, why should the economists attempt to = understand us? -----Original Message----- From: saag-bounces@ietf.org on behalf of Nicolas Williams Sent: Mon 3/2/2009 3:56 PM To: Jeffrey Hutzelman Cc: der Mouse; saag@ietf.org Subject: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) =20 Perhaps the simplest fix, technologically speaking, would be to get a real PKI -- no technical changes needed, just political ones. But that strikes me as politically infeasible. A real PKI would imply: - trust anchor regulations - CA and DNS registrar regulations that work Seems unlikely. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99C0B.E0415FCA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n = transition)

A PKI does not grow of its own accord. The SSL PKI = only exists because there was a clear business driver that drove its = deployment.

That is not to say that it is impossible to deploy an alternative = design. Only that it is necessary to model and understand the real world = deployment constraints and design for deployment.

And the biggest mistake most designers make is to over-estimate the = extent to which security is actually desired. As far as actual end users = are concerned the SHA-n transition issue is irrelevant, it is even = irrelevant as far as the banks and so on are concerned. Everyone else in = the system expects 'the boffins' to come up with a fix that won't = require them to do too much. In particular, they don't want a solution = that might require them to actually think.

The only way that an imminent crisis can lead to large scale concerted = action is if (1) the underlying technical issue is simple enough for = anyone to grasp and (2) those required to act have other motives for = action. The reason that the Y2K scam was so successful was because it = enabled a clique of mediocre corporate VPs to engage in empire building. = After a short while the scam became self-perpetuating because the first = act of a Y2K vampire was to send out letters to every supplier demanding = proof of Y2K certification - and so the infection was spread.


You do not need to be an economist or apply fancy algebra to understand = the effects of economic processes. If we are not prepared to try to = understand the economists, why should the economists attempt to = understand us?


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Nicolas Williams
Sent: Mon 3/2/2009 3:56 PM
To: Jeffrey Hutzelman
Cc: der Mouse; saag@ietf.org
Subject: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n = transition)

Perhaps the simplest fix, technologically speaking, would be to get = a
real PKI -- no technical changes needed, just political ones.  But = that
strikes me as politically infeasible.

A real PKI would imply:

 - trust anchor regulations
 - CA and DNS registrar regulations that work

Seems unlikely.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C99C0B.E0415FCA-- From mcgrew@cisco.com Tue Mar 3 06:29:24 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8253A685C for ; Tue, 3 Mar 2009 06:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 FuGRTilige2S for ; Tue, 3 Mar 2009 06:29:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4DB823A6803 for ; Tue, 3 Mar 2009 06:29:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,296,1233532800"; d="scan'208";a="38936189" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2009 14:29:49 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n23ETnIn020566; Tue, 3 Mar 2009 09:29:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n23ETn8C016319; Tue, 3 Mar 2009 14:29:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 09:29:49 -0500 Received: from [172.16.1.3] ([10.86.247.61]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 09:29:49 -0500 Message-Id: <9DC7C372-2D02-4AEA-A951-74F64AF5EE03@cisco.com> From: David McGrew To: Tim Polk In-Reply-To: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 06:29:48 -0800 References: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 14:29:49.0328 (UTC) FILETIME=[821D7900:01C99C0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=757; t=1236090589; x=1236954589; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Re=3A=20[saag]=20Request=20for=20agenda=20items |Sender:=20 |To:=20Tim=20Polk=20; bh=ICq1s0v9IP95KI+TVRB4gVs+atW3GF3k1TAmQn3EMSI=; b=E8MMjZQABLQWvmtz0efKrfp44ytGVbhcCOBJFuv8KYBB2lOhQSZSFEXVnw NrY8oYX94FwRUnb1Ao8G4HiCZkepIa9hNhfeVHuCq8Cs3L88sWR60/7NR76i cRNn4Tc3YM; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: saag@ietf.org Subject: Re: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:29:24 -0000 Hi Tim, I am in the process of preparing a revision of "Threshold Secret Sharing", draft-mcgrew-tss-02, which I'll submit this week. If there is interest in the security area, I offer to give an overview of this work. I have also heard of some interest in threshold digital signatures, which is outside the scope of this draft, but which might be worth covering in the meeting. best regards, David On Feb 20, 2009, at 9:56 AM, Tim Polk wrote: > Folks, > > Pasi and I are working on the agenda for saag at IETF 74. We would > appreciate any suggestions! > > Thanks, > > Tim Polk > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From pgut001@cs.auckland.ac.nz Tue Mar 3 07:39:54 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A6C3A6452 for ; Tue, 3 Mar 2009 07:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 tSpusMk7Mk5P for ; Tue, 3 Mar 2009 07:39:54 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id D88EC3A6359 for ; Tue, 3 Mar 2009 07:39:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DFF9B9E803; Wed, 4 Mar 2009 04:40:17 +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 BWO1dc+8+lxR; Wed, 4 Mar 2009 04:40:17 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A86A89E7EF; Wed, 4 Mar 2009 04:40:16 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 79D2A1DE4001; Wed, 4 Mar 2009 04:40:15 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeWj9-0006nD-Ad; Wed, 04 Mar 2009 04:40:15 +1300 From: Peter Gutmann To: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz In-Reply-To: <20090302171646.GN9992@Sun.COM> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 04:40:15 +1300 Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:39:54 -0000 Nicolas Williams writes: >TLS-PSK is not sufficient by itself, and for two reasons: > >a) As the RFC says: "[h]owever, this document is not intended for web > password authentication, but rather for other uses of TLS." That was added as a sop to the "we already have PKI in all its infinite perfection and splendor, why provide an alternative?" crowd. >Thus there is nothing about how to derive PSKs from passwords. Yeah, my fault, I've had an RFC draft prepared but not quite posted yet for ages. >b) For any solution to scale that adds mutual authentication we'll need >either the user to use the same password for all identities or federation. Huh? Where did this requirement come from? You need neither of those two. Peter. From pgut001@cs.auckland.ac.nz Tue Mar 3 07:46:17 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012CD3A6857 for ; Tue, 3 Mar 2009 07:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 meRuRTvF00zg for ; Tue, 3 Mar 2009 07:46:16 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 2D5C23A6359 for ; Tue, 3 Mar 2009 07:46:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3AB399E852; Wed, 4 Mar 2009 04:46:43 +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 zNIAUJi0Qxy3; Wed, 4 Mar 2009 04:46:43 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6C6F29E803; Wed, 4 Mar 2009 04:46:42 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 647551DE4001; Wed, 4 Mar 2009 04:46:42 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeWpO-00075B-8L; Wed, 04 Mar 2009 04:46:42 +1300 From: Peter Gutmann To: ekr@networkresonance.com, Nicolas.Williams@sun.com In-Reply-To: <20090302181143.2B7B550822@romeo.rtfm.com> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 04:46:42 +1300 Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:46:17 -0000 Eric Rescorla writes: >"We must do something. This is something. We must do this." So you've got the choice between the Polician's Fallacy (the above) and psychosis ("PKI has been failing for 30 years [0], let's try more of it in the hope that it suddenly works this time"). I think we need psychiatrists for this more than we need security geeks. (I don't know the answer either, but admitting you have a problem with your current approach is always the first step to recovery). Peter. [0] Or 20 years if you measure your epoch from X.509 rather than Kohnfelder. From Nicolas.Williams@sun.com Tue Mar 3 08:16:37 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6AAE28C232 for ; Tue, 3 Mar 2009 08:16:37 -0800 (PST) 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 71k4mrOPbVdY for ; Tue, 3 Mar 2009 08:16:37 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C3A333A69E9 for ; Tue, 3 Mar 2009 08:16:31 -0800 (PST) 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 n23GGwSa009531 for ; Tue, 3 Mar 2009 16:16:59 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 n23GGsXx005155 for ; Tue, 3 Mar 2009 09:16:54 -0700 (MST) 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 n23G0CMV014154; Tue, 3 Mar 2009 10:00:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23G07QT014153; Tue, 3 Mar 2009 10:00:07 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Mar 2009 10:00:07 -0600 From: Nicolas Williams To: Peter Gutmann Message-ID: <20090303160007.GW9992@Sun.COM> References: <20090302181143.2B7B550822@romeo.rtfm.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: saag@ietf.org, mouse@Rodents-Montreal.ORG Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:16:37 -0000 On Wed, Mar 04, 2009 at 04:46:42AM +1300, Peter Gutmann wrote: > Eric Rescorla writes: > >"We must do something. This is something. We must do this." > > So you've got the choice between the Polician's Fallacy (the above) and > psychosis ("PKI has been failing for 30 years [0], let's try more of it in the > hope that it suddenly works this time"). Well, no, there's also the choice of making PKIs work -- that requires more political work than technical, and may be as infeasible as a good unregulated PKI has been. Also, I'm not sure that well-regulated PKI will necessarily be a good thing -- I can already imagine the complaints about how red tape slows everything down, doesn't scale, blah, blah, blah. But if the consensus here was that that is what we need, and if politicians told us it's feasible then it'd be worth trying. > I think we need psychiatrists for this more than we need security geeks. > > (I don't know the answer either, but admitting you have a problem with your > current approach is always the first step to recovery). How long has the consensus been that web security is broke? Admitting you have a problem is the first step, but it is not sufficient. Nico -- From pgut001@cs.auckland.ac.nz Tue Mar 3 08:26:23 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA753A6955 for ; Tue, 3 Mar 2009 08:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 WLkX0TFkydoV for ; Tue, 3 Mar 2009 08:26:22 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 7DBA63A684F for ; Tue, 3 Mar 2009 08:26:21 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0C24B19A7F; Wed, 4 Mar 2009 05:26:48 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8u1vFs0d6h9; Wed, 4 Mar 2009 05:26:47 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E0F4319714; Wed, 4 Mar 2009 05:26:47 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 635FC1DE4001; Wed, 4 Mar 2009 05:26:47 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeXSB-0000gr-AM; Wed, 04 Mar 2009 05:26:47 +1300 From: Peter Gutmann To: Nicolas.Williams@sun.com, pgut001@cs.auckland.ac.nz In-Reply-To: <20090303160007.GW9992@Sun.COM> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 05:26:47 +1300 Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:26:23 -0000 Nicolas Williams writes: >On Wed, Mar 04, 2009 at 04:46:42AM +1300, Peter Gutmann wrote: >> (I don't know the answer either, but admitting you have a problem with your >> current approach is always the first step to recovery). > >How long has the consensus been that web security is broke? Admitting >you have a problem is the first step, but it is not sufficient. By "current approach" I meant PKI as a means of addressing web security problems. The response to 20 (or 30, see before) years of PKI failure as recently as a year ago has been EV certs, i.e. more of what we already know doesn't work. It looks like we're nowhere near admitting that we have a problem yet if the response to the failure of PKI is PKI-me-harder. Peter. From pgut001@cs.auckland.ac.nz Tue Mar 3 08:33:50 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313963A6938 for ; Tue, 3 Mar 2009 08:33:50 -0800 (PST) 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=[AWL=0.600, 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 QlUVKdgYUaFd for ; Tue, 3 Mar 2009 08:33:49 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 571913A6917 for ; Tue, 3 Mar 2009 08:33:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7062A1A612; Wed, 4 Mar 2009 05:34:16 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cire+iVXwu16; Wed, 4 Mar 2009 05:34:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 519641A3D2; Wed, 4 Mar 2009 05:34:16 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D38C71DE4001; Wed, 4 Mar 2009 05:34:15 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeXZP-0000x0-NP; Wed, 04 Mar 2009 05:34:15 +1300 From: Peter Gutmann To: jhutz@cmu.edu, Nicolas.Williams@sun.com In-Reply-To: <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 05:34:15 +1300 Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:33:50 -0000 Jeffrey Hutzelman writes: >How do you expect users to remember not to give away their passwords when >they can't be bothered to remember to wash their hands or look both ways >before crossing a street? site_password = HMAC( user_password || 128-bit salt, site_URL ); (or assorted variations thereof, there are a pile of password-fortification techniques around, and all manner of free and low-cost commercial products that implement them). That way even if they hand their password over a phisher, it won't do the phisher much good. At this point I expect the peanut gallery to jump in with the usual million or so corner cases where this won't work, but the important point is that the above would help most of the people most of the time, and in particular it'd help the demographic who are most likely to fall into phisher traps, i.e. non- technical people for whom the standard "the salt isn't portable across my eight computers and three laptops and therefore your scheme isn't worth trying" objection doesn't apply. Peter. From Nicolas.Williams@sun.com Tue Mar 3 08:38:37 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEECE3A6835 for ; Tue, 3 Mar 2009 08:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.199, 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 UvHM2PsrnjXE for ; Tue, 3 Mar 2009 08:38:36 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id AFFDE3A679C for ; Tue, 3 Mar 2009 08:38:36 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n23Gd3d4015886 for ; Tue, 3 Mar 2009 16:39:03 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 n23Gd3kv022177 for ; Tue, 3 Mar 2009 09:39:03 -0700 (MST) 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 n23GU2uZ014212; Tue, 3 Mar 2009 10:30:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23GU2Qx014211; Tue, 3 Mar 2009 10:30:02 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Mar 2009 10:30:02 -0600 From: Nicolas Williams To: "Hallam-Baker, Phillip" Message-ID: <20090303163002.GA9992@Sun.COM> References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:38:37 -0000 On Tue, Mar 03, 2009 at 06:25:17AM -0800, Hallam-Baker, Phillip wrote: > The only way that an imminent crisis can lead to large scale concerted > action is if [...] ... it happens. > You do not need to be an economist or apply fancy algebra to > understand the effects of economic processes. If we are not prepared > to try to understand the economists, why should the economists attempt > to understand us? As I said, a real PKI is a political problem. Is it really necessary in this day and age to point out that economists take a back seat to politicians? It seems there's nothing that government can't do now, so why not a PKI? :^/ Stephen pointed to regulated PKIs in Asia, proving the point, though if those PKIs are lousy, then it was a lousy point, but at least we might be able to gather data on what the impact of a real PKI might be. From Nicolas.Williams@sun.com Tue Mar 3 09:04:06 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800FA3A6917 for ; Tue, 3 Mar 2009 09:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.196, 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 KrRbIyCm0IiY for ; Tue, 3 Mar 2009 09:04:05 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 865B03A679C for ; Tue, 3 Mar 2009 09:04:05 -0800 (PST) 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 n23H4WnF008014 for ; Tue, 3 Mar 2009 17:04:32 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 n23H4WpU044583 for ; Tue, 3 Mar 2009 10:04:32 -0700 (MST) 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 n23GeVpV014232; Tue, 3 Mar 2009 10:40:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n23GeV5Y014231; Tue, 3 Mar 2009 10:40:31 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Mar 2009 10:40:31 -0600 From: Nicolas Williams To: Peter Gutmann Message-ID: <20090303164030.GD9992@Sun.COM> References: <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:04:06 -0000 On Wed, Mar 04, 2009 at 05:34:15AM +1300, Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >How do you expect users to remember not to give away their passwords when > >they can't be bothered to remember to wash their hands or look both ways > >before crossing a street? > > site_password = HMAC( user_password || 128-bit salt, site_URL ); I've had sundry such browser plugins installed and I still don't use them. I tried, but I stopped when I noticed that using such passwords in my cell phone was a royal PITA. Thanks, you've managed to depress me :) You've also disproved my point and proved EKR's. The clarity is welcomed. From pbaker@verisign.com Tue Mar 3 09:05:25 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315553A6A57 for ; Tue, 3 Mar 2009 09:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aWgdHuYMDeGf for ; Tue, 3 Mar 2009 09:05:24 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 60F483A6A8D for ; Tue, 3 Mar 2009 09:05:24 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n23H5pdS014032; Tue, 3 Mar 2009 09:05:51 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:05:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C22.4DD0C516" Date: Tue, 3 Mar 2009 09:04:39 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2EE@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) Thread-Index: AcmcH6SFlVG9w8rFQ+6rpeeGn4ZJswAAn8nh References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> <20090303163002.GA9992@Sun.COM> From: "Hallam-Baker, Phillip" To: "Nicolas Williams" X-OriginalArrivalTime: 03 Mar 2009 17:05:51.0688 (UTC) FILETIME=[4E843C80:01C99C22] Cc: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:05:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C22.4DD0C516 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Governments can regulate PKIs to be employed for government purposes. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] Sent: Tue 3/3/2009 11:30 AM To: Hallam-Baker, Phillip Cc: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) =20 On Tue, Mar 03, 2009 at 06:25:17AM -0800, Hallam-Baker, Phillip wrote: > The only way that an imminent crisis can lead to large scale concerted > action is if [...] ... it happens. > You do not need to be an economist or apply fancy algebra to > understand the effects of economic processes. If we are not prepared > to try to understand the economists, why should the economists attempt > to understand us? As I said, a real PKI is a political problem. Is it really necessary in this day and age to point out that economists take a back seat to politicians? It seems there's nothing that government can't do now, so why not a PKI? :^/ Stephen pointed to regulated PKIs in Asia, proving the point, though if those PKIs are lousy, then it was a lousy point, but at least we might be able to gather data on what the impact of a real PKI might be. ------_=_NextPart_001_01C99C22.4DD0C516 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n = transition)

Governments can regulate PKIs to be employed for = government purposes.



-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams@sun.com<= /A>]
Sent: Tue 3/3/2009 11:30 AM
To: Hallam-Baker, Phillip
Cc: saag@ietf.org
Subject: Re: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n = transition)

On Tue, Mar 03, 2009 at 06:25:17AM -0800, Hallam-Baker, Phillip = wrote:
> The only way that an imminent crisis can lead to large scale = concerted
> action is if [...]

... it happens.

> You do not need to be an economist or apply fancy algebra to
> understand the effects of economic processes. If we are not = prepared
> to try to understand the economists, why should the economists = attempt
> to understand us?

As I said, a real PKI is a political problem.  Is it really = necessary in
this day and age to point out that economists take a back seat to
politicians?  It seems there's nothing that government can't do = now, so
why not a PKI?  :^/

Stephen pointed to regulated PKIs in Asia, proving the point, though = if
those PKIs are lousy, then it was a lousy point, but at least we = might
be able to gather data on what the impact of a real PKI might be.

------_=_NextPart_001_01C99C22.4DD0C516-- From jhutz@cmu.edu Tue Mar 3 09:23:31 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B823A687E for ; Tue, 3 Mar 2009 09:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 yhHuJPFzxkNE for ; Tue, 3 Mar 2009 09:23:31 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id C84723A6774 for ; Tue, 3 Mar 2009 09:23:10 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23HN0ai010959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 12:23:02 -0500 (EST) Date: Tue, 03 Mar 2009 12:23:00 -0500 From: Jeffrey Hutzelman To: David McGrew , Tim Polk Message-ID: <6EA6C31538D7841189B8B9EC@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903031429.n23ETtTp021297@toasties.srv.cs.cmu.edu> References: <75DF90B8-EA79-43A2-B60C-21BE70ED5A73@nist.gov> <200903031429.n23ETtTp021297@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: saag@ietf.org Subject: Re: [saag] Request for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:23:31 -0000 --On Tuesday, March 03, 2009 06:29:48 AM -0800 David McGrew wrote: > I am in the process of preparing a revision of "Threshold Secret > Sharing", draft-mcgrew-tss-02, which I'll submit this week. If there is > interest in the security area, I offer to give an overview of this work. > I have also heard of some interest in threshold digital signatures, which > is outside the scope of this draft, but which might be worth covering in > the meeting. I for one would be very interested in hearing more about this work. -- Jeff From jhutz@cmu.edu Tue Mar 3 09:26:24 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6458E3A6C04 for ; Tue, 3 Mar 2009 09:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 ZtAhxfTKjgrE for ; Tue, 3 Mar 2009 09:26:23 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 80E773A6C09 for ; Tue, 3 Mar 2009 09:26:23 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23HQkfA011069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 12:26:48 -0500 (EST) Date: Tue, 03 Mar 2009 12:26:46 -0500 From: Jeffrey Hutzelman To: "Hallam-Baker, Phillip" , Nicolas Williams Message-ID: <183A1EC1708C7DD712F81C64@atlantis.pc.cs.cmu.edu> In-Reply-To: <200903031705.n23H5uJa024119@toasties.srv.cs.cmu.edu> References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> <20090303163002.GA9992@Sun.COM> <200903031705.n23H5uJa024119@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:26:24 -0000 --On Tuesday, March 03, 2009 09:04:39 AM -0800 "Hallam-Baker, Phillip" wrote: > Governments can regulate PKIs to be employed for government purposes. I think you misunderstand the nature of a government's power. From ekr@networkresonance.com Tue Mar 3 09:34:07 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70B13A67A4 for ; Tue, 3 Mar 2009 09:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 XiHeXgjk4mdU for ; Tue, 3 Mar 2009 09:34:07 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 834223A6774 for ; Tue, 3 Mar 2009 09:34:06 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A169950822; Tue, 3 Mar 2009 09:57:24 -0800 (PST) Date: Tue, 03 Mar 2009 09:57:24 -0800 From: Eric Rescorla To: Peter Gutmann In-Reply-To: References: <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090303175724.A169950822@romeo.rtfm.com> Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:34:07 -0000 At Wed, 04 Mar 2009 05:34:15 +1300, Peter Gutmann wrote: > > Jeffrey Hutzelman writes: > > >How do you expect users to remember not to give away their passwords when > >they can't be bothered to remember to wash their hands or look both ways > >before crossing a street? > > site_password = HMAC( user_password || 128-bit salt, site_URL ); > > (or assorted variations thereof, there are a pile of password-fortification > techniques around, and all manner of free and low-cost commercial products > that implement them). That way even if they hand their password over a > phisher, it won't do the phisher much good. > > At this point I expect the peanut gallery to jump in with the usual million or > so corner cases where this won't work, but the important point is that the > above would help most of the people most of the time, and in particular it'd > help the demographic who are most likely to fall into phisher traps, i.e. non- > technical people for whom the standard "the salt isn't portable across my > eight computers and three laptops and therefore your scheme isn't worth > trying" objection doesn't apply. Peter, While I think this general class of solutions has some utility, but the difficulty is that it requires some UI mechanism to stop the phisher from convincing the user to type their password into a dialog which goes directly to the phisher rather than being hashed. I'm unaware of any general solution to that problem, and this is not really a corner case but rather the main case. -Ekr From pbaker@verisign.com Tue Mar 3 09:54:32 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3682B3A6C85 for ; Tue, 3 Mar 2009 09:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wNrpy5oTNaqz for ; Tue, 3 Mar 2009 09:54:31 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 6028F3A6C89 for ; Tue, 3 Mar 2009 09:54:02 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n23Hs4SQ016076; Tue, 3 Mar 2009 09:54:24 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:54:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C29.0C26B3F2" Date: Tue, 3 Mar 2009 09:54:06 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2F0@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmcF0aeonTVg2p2S36gmYbUFxILPAADOD4q References: From: "Hallam-Baker, Phillip" To: "Peter Gutmann" , , X-OriginalArrivalTime: 03 Mar 2009 17:54:08.0187 (UTC) FILETIME=[0CF6E8B0:01C99C29] Cc: mouse@Rodents-Montreal.ORG, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:54:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C29.0C26B3F2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First step would be to try to understand the business issues that cause = people to avoid deployment. If we are going to get anywhere we have to recognize that these issues = are not only in IETF scope, they are the most important issues for the = IETF to consider if the IETF is going to have the real-world relevance = that we all hope for. We have to face the fact that deployment of new protocols has often been = a failure and that changes to deployed protocols have failed with even = greater frequency. -----Original Message----- From: saag-bounces@ietf.org on behalf of Peter Gutmann Sent: Tue 3/3/2009 10:46 AM To: ekr@networkresonance.com; Nicolas.Williams@sun.com Cc: mouse@Rodents-Montreal.ORG; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =20 Eric Rescorla writes: >"We must do something. This is something. We must do this." So you've got the choice between the Polician's Fallacy (the above) and psychosis ("PKI has been failing for 30 years [0], let's try more of it = in the hope that it suddenly works this time"). I think we need psychiatrists for this more than we need security geeks. (I don't know the answer either, but admitting you have a problem with = your current approach is always the first step to recovery). Peter. [0] Or 20 years if you measure your epoch from X.509 rather than = Kohnfelder. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99C29.0C26B3F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] SHA-1 to SHA-n transition

First step would be to try to understand the business = issues that cause people to avoid deployment.

If we are going to get anywhere we have to recognize that these issues = are not only in IETF scope, they are the most important issues for the = IETF to consider if the IETF is going to have the real-world relevance = that we all hope for.

We have to face the fact that deployment of new protocols has often been = a failure and that changes to deployed protocols have failed with even = greater frequency.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Peter Gutmann
Sent: Tue 3/3/2009 10:46 AM
To: ekr@networkresonance.com; Nicolas.Williams@sun.com
Cc: mouse@Rodents-Montreal.ORG; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

Eric Rescorla <ekr@networkresonance.com> writes:

>"We must do something. This is something. We must do = this."

So you've got the choice between the Polician's Fallacy (the above) = and
psychosis ("PKI has been failing for 30 years [0], let's try more = of it in the
hope that it suddenly works this time").

I think we need psychiatrists for this more than we need security = geeks.

(I don't know the answer either, but admitting you have a problem with = your
current approach is always the first step to recovery).

Peter.

[0] Or 20 years if you measure your epoch from X.509 rather than = Kohnfelder.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C99C29.0C26B3F2-- From pgut001@cs.auckland.ac.nz Tue Mar 3 10:19:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD13628C2B9 for ; Tue, 3 Mar 2009 10:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 dZ7wyZAsa63Z for ; Tue, 3 Mar 2009 10:19:10 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id C8C903A6C08 for ; Tue, 3 Mar 2009 10:19:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DEEAC1A6FE; Wed, 4 Mar 2009 07:19:33 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgs2Y+TaqYvI; Wed, 4 Mar 2009 07:19:33 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 745A919EA7; Wed, 4 Mar 2009 07:19:31 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D049A1DE4001; Wed, 4 Mar 2009 07:19:30 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeZDG-0006FF-Os; Wed, 04 Mar 2009 07:19:30 +1300 From: Peter Gutmann To: ekr@networkresonance.com, pgut001@cs.auckland.ac.nz In-Reply-To: <20090303175724.A169950822@romeo.rtfm.com> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 07:19:30 +1300 Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:19:10 -0000 Eric Rescorla writes: >While I think this general class of solutions has some utility, but the >difficulty is that it requires some UI mechanism to stop the phisher from >convincing the user to type their password into a dialog which goes directly >to the phisher rather than being hashed. Uhh, read my original message again, it doesn't matter if the phisher gets the password or not (obviously it'd be better if they didn't, but if they do then it's not serious because they still need to get the 128-bit salt, and the only way to get that is via malware on the victim's PC at which point any measure at all is going to fail). That's the beauty of it, as Jeff pointed out you're never going to stop users from giving out their password to anything that asks for it so the solution is to create a mechanism where this isn't an issue any more. OTPs are one example of this, but that one's a lot more work than a simple password diversifier. (There's a whole pile of other problems that this addresses as well, for example the user only has to remember a single password, recovery can be handled via standard backup mechanisms like the Windows password reset disk (PRD) via DPAPI, and so on. The full run-down gets quite complicated because there's a pile of carry-on effects that address a lot of other problems with password-based authentication). Peter. From jhutz@cmu.edu Tue Mar 3 10:29:55 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8BA3A6B29 for ; Tue, 3 Mar 2009 10:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=1.143, 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 Ps-Tjs6rdvam for ; Tue, 3 Mar 2009 10:29:45 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 5E5813A6C87 for ; Tue, 3 Mar 2009 10:28:35 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23ISpQp012880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 13:28:54 -0500 (EST) Date: Tue, 03 Mar 2009 13:28:51 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , ekr@networkresonance.com Message-ID: <630A197A21A391B6C148B3D7@atlantis.pc.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:29:55 -0000 --On Wednesday, March 04, 2009 07:19:30 AM +1300 Peter Gutmann wrote: > Eric Rescorla writes: > >> While I think this general class of solutions has some utility, but the >> difficulty is that it requires some UI mechanism to stop the phisher from >> convincing the user to type their password into a dialog which goes >> directly to the phisher rather than being hashed. > > Uhh, read my original message again, it doesn't matter if the phisher > gets the password or not (obviously it'd be better if they didn't, but if > they do then it's not serious because they still need to get the 128-bit > salt, and the only way to get that is via malware on the victim's PC at > which point any measure at all is going to fail). That's the beauty of > it, as Jeff pointed out you're never going to stop users from giving out > their password to anything that asks for it so the solution is to create > a mechanism where this isn't an issue any more. OTPs are one example of > this, but that one's a lot more work than a simple password diversifier. > > (There's a whole pile of other problems that this addresses as well, for > example the user only has to remember a single password, recovery can be > handled via standard backup mechanisms like the Windows password reset > disk (PRD) via DPAPI, and so on. The full run-down gets quite > complicated because there's a pile of carry-on effects that address a lot > of other problems with password-based authentication). Unfortunately, it also creates a fairly signficant set of problems, in that the credentials are no longer portable -- besides needing to know your password, you need a salt that's hidden somewhere in your browser's long-term state. That makes it hard to use multple browsers on multiple machines, and guarantees that if you lose your disk, you also lose the ability to log in to anything and everything. -- Jeff From kent@bbn.com Tue Mar 3 10:53:52 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A8E3A69C0 for ; Tue, 3 Mar 2009 10:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 Wlm2-QPGQVPm for ; Tue, 3 Mar 2009 10:53:51 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id F1A683A69BB for ; Tue, 3 Mar 2009 10:53:50 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.34.4.253]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LeZku-0002sm-A1; Tue, 03 Mar 2009 13:54:16 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2EE@mou1wnexmb09.vcorp.ad.vrsn.com> References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> <20090303163002.GA9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EE@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 3 Mar 2009 13:53:05 -0500 To: "Hallam-Baker, Phillip" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org, Nicolas Williams Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:53:52 -0000 At 9:04 AM -0800 3/3/09, Hallam-Baker, Phillip wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C99C22.4DD0C516" > >Governments can regulate PKIs to be employed for government purposes. > A government can regulate CAs that operate in its country, for ANY purpose, if so desires. But, I already noted that this outcome is likely in the U.S. or the EU. Steve From pbaker@verisign.com Tue Mar 3 11:15:57 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7203A69BB for ; Tue, 3 Mar 2009 11:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yLJTooQO79VN for ; Tue, 3 Mar 2009 11:15:55 -0800 (PST) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id D16C83A695E for ; Tue, 3 Mar 2009 11:15:55 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n23IpbpE015165; Tue, 3 Mar 2009 10:51:37 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 11:16:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C34.8435B596" Date: Tue, 3 Mar 2009 11:12:46 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2F3@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) Thread-Index: AcmcMXUztgJ2QE6DQ4ujbgfcaav7dAAApQY5 References: <20090227022359.8D45150822@romeo.rtfm.com> <20090302161134.GG9992@Sun.COM> <20090302172135.DA43650822@romeo.rtfm.com> <200903021720.n22HKZOv006388@grapenut.srv.cs.cmu.edu> <864C82388E530D27DCB6002F@minbar.fac.cs.cmu.edu> <20090302182547.GX9992@Sun.COM> <0DE6E86D395C657BABF43B97@minbar.fac.cs.cmu.edu> <20090302185050.GB9992@Sun.COM> <20090302205656.GF9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EC@mou1wnexmb09.vcorp.ad.vrsn.com> <20090303163002.GA9992@Sun.COM> <2788466ED3E31C418E9ACC5C3166155768B2EE@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Stephen Kent" X-OriginalArrivalTime: 03 Mar 2009 19:16:13.0841 (UTC) FILETIME=[84E21010:01C99C34] Cc: saag@ietf.org, Nicolas Williams Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:15:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C34.8435B596 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We already went through that phase. Early in the life of PKI there was a = whole slew of state regulation. At one point there was an entire wall in = the practices group covered in certification and accreditation plaques. None of it had any real effect. These are hard problems that governments have difficulty with as well. = It was a government inquiry that started my thinking on this topic. Regulation is a government tool, it is rarely a government objective in = its own right. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tue 3/3/2009 1:53 PM To: Hallam-Baker, Phillip Cc: Nicolas Williams; saag@ietf.org Subject: Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n transition) =20 At 9:04 AM -0800 3/3/09, Hallam-Baker, Phillip wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C99C22.4DD0C516" > >Governments can regulate PKIs to be employed for government purposes. > A government can regulate CAs that operate in its country, for ANY=20 purpose, if so desires. But, I already noted that this outcome is likely in the U.S. or the EU. Steve ------_=_NextPart_001_01C99C34.8435B596 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n = transition)

We already went through that phase. Early in the life = of PKI there was a whole slew of state regulation. At one point there = was an entire wall in the practices group covered in certification and = accreditation plaques.

None of it had any real effect.

These are hard problems that governments have difficulty with as well. = It was a government inquiry that started my thinking on this topic.


Regulation is a government tool, it is rarely a government objective in = its own right.


-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tue 3/3/2009 1:53 PM
To: Hallam-Baker, Phillip
Cc: Nicolas Williams; saag@ietf.org
Subject: Re: [saag] Or grow a real PKI (Re:  SHA-1 to SHA-n = transition)

At 9:04 AM -0800 3/3/09, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>       = boundary=3D"----_=3D_NextPart_001_01C99C22.4DD0C516"
>
>Governments can regulate PKIs to be employed for government = purposes.
>

A government can regulate CAs that operate in its country, for ANY
purpose, if so desires.

But, I already noted that this outcome is likely in the U.S. or the = EU.

Steve

------_=_NextPart_001_01C99C34.8435B596-- From pgut001@cs.auckland.ac.nz Tue Mar 3 11:22:21 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3261D3A69BB for ; Tue, 3 Mar 2009 11:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 jwPK8kXCHNDh for ; Tue, 3 Mar 2009 11:22:20 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 6A70728C2B3 for ; Tue, 3 Mar 2009 11:22:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A52B481D64; Wed, 4 Mar 2009 08:22:46 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzF8MwDJR9yT; Wed, 4 Mar 2009 08:22:46 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D944F481D5E; Wed, 4 Mar 2009 08:22:45 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2C52D1DE4001; Wed, 4 Mar 2009 08:22:45 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LeaCT-0001WI-2K; Wed, 04 Mar 2009 08:22:45 +1300 From: Peter Gutmann To: ekr@networkresonance.com, jhutz@cmu.edu, pgut001@cs.auckland.ac.nz In-Reply-To: <630A197A21A391B6C148B3D7@atlantis.pc.cs.cmu.edu> Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 08:22:45 +1300 Cc: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:22:21 -0000 Jeffrey Hutzelman writes: >Unfortunately, it also creates a fairly signficant set of problems, in that >the credentials are no longer portable -- besides needing to know your >password, you need a salt that's hidden somewhere in your browser's long-term >state. Yes, I know, and I also knew that every time anyone mentions something like this someone immediately raises the point you've just made, which is why I addressed it in my original message. Peter. From jhutz@cmu.edu Tue Mar 3 11:33:42 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275593A685D for ; Tue, 3 Mar 2009 11:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=1.091, 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 GKyRusDjIqqT for ; Tue, 3 Mar 2009 11:33:41 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 4BFE03A67F9 for ; Tue, 3 Mar 2009 11:33:41 -0800 (PST) Received: from 68-247-236-105.pools.spcsdns.net (173-115-63-122.pools.spcsdns.net [173.115.63.122]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n23JXvfV015531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 14:33:59 -0500 (EST) Date: Tue, 03 Mar 2009 14:33:57 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , ekr@networkresonance.com Message-ID: <7B2E73A2FEDFDF2435195247@atlantis.pc.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com, saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 19:33:42 -0000 --On Wednesday, March 04, 2009 08:22:45 AM +1300 Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >> Unfortunately, it also creates a fairly signficant set of problems, in >> that the credentials are no longer portable -- besides needing to know >> your password, you need a salt that's hidden somewhere in your browser's >> long-term state. > > Yes, I know, and I also knew that every time anyone mentions something > like this someone immediately raises the point you've just made, which is > why I addressed it in my original message. You seem to imply that only weird technical people have or use more than one computer. This is certainly not true; many people have a computer at home and one at work, and many of those are quite non-technical. Computers have become commonplace desktop items both in the home and in the office. Also, telling people "if the disk on your home PC dies, your life is over" is a good way to get them _not_ to use a scheme like this. Saying the solution is to always have backups is just going to get you laughed at. -- Jeff From ekr@networkresonance.com Tue Mar 3 20:15:00 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6373D3A6930 for ; Tue, 3 Mar 2009 20:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 fGau2A84sZqc for ; Tue, 3 Mar 2009 20:14:59 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A823B3A68E8 for ; Tue, 3 Mar 2009 20:14:59 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7157F50822; Tue, 3 Mar 2009 20:38:18 -0800 (PST) Date: Tue, 03 Mar 2009 20:38:18 -0800 From: Eric Rescorla To: Jeffrey Hutzelman In-Reply-To: <7B2E73A2FEDFDF2435195247@atlantis.pc.cs.cmu.edu> References: <7B2E73A2FEDFDF2435195247@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.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: <20090304043818.7157F50822@romeo.rtfm.com> Cc: saag@ietf.org, mouse@Rodents-Montreal.ORG, Nicolas.Williams@sun.com Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 04:15:00 -0000 At Tue, 03 Mar 2009 14:33:57 -0500, Jeffrey Hutzelman wrote: > > --On Wednesday, March 04, 2009 08:22:45 AM +1300 Peter Gutmann > wrote: > > > Jeffrey Hutzelman writes: > > > >> Unfortunately, it also creates a fairly signficant set of problems, in > >> that the credentials are no longer portable -- besides needing to know > >> your password, you need a salt that's hidden somewhere in your browser's > >> long-term state. > > > > Yes, I know, and I also knew that every time anyone mentions something > > like this someone immediately raises the point you've just made, which is > > why I addressed it in my original message. > > You seem to imply that only weird technical people have or use more than > one computer. This is certainly not true; many people have a computer at > home and one at work, and many of those are quite non-technical. Computers > have become commonplace desktop items both in the home and in the office. > > Also, telling people "if the disk on your home PC dies, your life is over" > is a good way to get them _not_ to use a scheme like this. Saying the > solution is to always have backups is just going to get you laughed at. Indeed. You're of course free to feel that this issue is out of scope, but I assure you that when you explain this to nontechnical people, they take it seriously. -Ekr From pgut001@cs.auckland.ac.nz Tue Mar 3 22:40:45 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10F33A6B57 for ; Tue, 3 Mar 2009 22:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, TVD_PH_REC=2.996] 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+xmnlcTLEoA for ; Tue, 3 Mar 2009 22:40:44 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 6DEEB3A6B58 for ; Tue, 3 Mar 2009 22:40:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 582B81A7E6; Wed, 4 Mar 2009 19:41:09 +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 (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH-HIvpQDdQm; Wed, 4 Mar 2009 19:41:09 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3BF561A7E2; Wed, 4 Mar 2009 19:41:09 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BEE701DE4001; Wed, 4 Mar 2009 19:41:08 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1Lekmy-0001Zx-KD; Wed, 04 Mar 2009 19:41:08 +1300 From: Peter Gutmann To: jhutz@cmu.edu, saag@ietf.org Message-Id: Sender: pgut001 Date: Wed, 04 Mar 2009 19:41:08 +1300 Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 06:40:45 -0000 Jeffrey Hutzelman writes: >You seem to imply that only weird technical people have or use more than one >computer. This is certainly not true; many people have a computer at home and >one at work, and many of those are quite non-technical. Computers have become >commonplace desktop items both in the home and in the office. Thanks, you just won me $20. (The wager was that, no matter how many disclaimers and explanatory comments I add (e.g. "not perfect but works for most of the people most of the time and it's a damn sight better than what we have now"), someone will always, always pipe up with some variation of "I own eight computers and this would never work for me and therefore it won't work for anyone else either". As long as there are at least 2-3 geeks in the audience and they're not HCI people, this one never fails). >Also, telling people "if the disk on your home PC dies, your life is over" is >a good way to get them _not_ to use a scheme like this. How is this different from the fact that if the never-backed-up 250GB disk full of financial records, family photos, personal letters, and business data on their PC dies their life is over anyway, whether there's crypto info on there or not? If you think that having to do a password reset for the few critical accounts that actually matter and re-enrolling for www.knittingpatterns.com is in the same league as losing your business account records and the last photos taken of your parents before they passed away then you seem to have a somewhat odd interpretation of "a life" :-). Peter. From pbaker@verisign.com Wed Mar 4 05:34:24 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CB43A68ED for ; Wed, 4 Mar 2009 05:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_PH_REC=2.996] 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 K9RZxMr6+Yyv for ; Wed, 4 Mar 2009 05:34:23 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 9A49C3A68D4 for ; Wed, 4 Mar 2009 05:34:23 -0800 (PST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n24DYjIF024917; Wed, 4 Mar 2009 05:34:45 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 05:34:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CCD.F9D1F202" Date: Wed, 4 Mar 2009 05:34:43 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2F7@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: AcmclDpxGgEArUrcRJKn9LN7IPbX5AAN53UJ References: From: "Hallam-Baker, Phillip" To: "Peter Gutmann" , , X-OriginalArrivalTime: 04 Mar 2009 13:34:44.0870 (UTC) FILETIME=[FAEAF260:01C99CCD] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 13:34:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CCD.F9D1F202 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are now into the identity issue which has precisley nothing to do = with algorithm transitions. Even if a 'real' PKI was deployed it would = still suffer from deployment deadlock issues. We do in fact have an example of a fairly widely deployed system that = works in precisely the way Peter suggests, Windows CardSpace. It is a = way for a machine to give a solid non-portable authentication credential = tied to an account. I think that it is perfectly reasonable to divide the problem into two - = solid machine based credentials and portable credentials. And I do note that whenever we have any debate that there is always = someone who leaps in with a requirement that is purportedly blocking and = tells us that it proves that the idea is utterly impossible, can't be = solved, not ever no way no how.=20 And often it is for a group of users that the speaker has no direct = connection with. Whenever we suggest dropping support for something = genuinely obsolete there will be someone who claims that it is still in = use 'in Africa', as if there is a third world time warp that forces them = to use obsolete software as well as obsolete hardware... The machine portability issue is real, it can even be solved = inexpensively using cell phones and PDAs that have the ability to run a = downloaded OTP application. -----Original Message----- From: saag-bounces@ietf.org on behalf of Peter Gutmann Sent: Wed 3/4/2009 1:41 AM To: jhutz@cmu.edu; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =20 Jeffrey Hutzelman writes: >You seem to imply that only weird technical people have or use more = than one >computer. This is certainly not true; many people have a computer at = home and >one at work, and many of those are quite non-technical. Computers have = become >commonplace desktop items both in the home and in the office. Thanks, you just won me $20. (The wager was that, no matter how many disclaimers and explanatory = comments I=20 add (e.g. "not perfect but works for most of the people most of the time = and=20 it's a damn sight better than what we have now"), someone will always, = always=20 pipe up with some variation of "I own eight computers and this would = never=20 work for me and therefore it won't work for anyone else either". As = long as=20 there are at least 2-3 geeks in the audience and they're not HCI people, = this=20 one never fails). >Also, telling people "if the disk on your home PC dies, your life is = over" is >a good way to get them _not_ to use a scheme like this. How is this different from the fact that if the never-backed-up 250GB = disk full of financial records, family photos, personal letters, and business = data on their PC dies their life is over anyway, whether there's crypto info = on there or not? If you think that having to do a password reset for the = few critical accounts that actually matter and re-enrolling for www.knittingpatterns.com is in the same league as losing your business = account records and the last photos taken of your parents before they passed = away then you seem to have a somewhat odd interpretation of "a life" :-). Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99CCD.F9D1F202 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] SHA-1 to SHA-n transition

We are now into the identity issue which has precisley = nothing to do with algorithm transitions. Even if a 'real' PKI was = deployed it would still suffer from deployment deadlock issues.

We do in fact have an example of a fairly widely deployed system that = works in precisely the way Peter suggests, Windows CardSpace. It is a = way for a machine to give a solid non-portable authentication credential = tied to an account.


I think that it is perfectly reasonable to divide the problem into two - = solid machine based credentials and portable credentials.


And I do note that whenever we have any debate that there is always = someone who leaps in with a requirement that is purportedly blocking and = tells us that it proves that the idea is utterly impossible, can't be = solved, not ever no way no how.

And often it is for a group of users that the speaker has no direct = connection with. Whenever we suggest dropping support for something = genuinely obsolete there will be someone who claims that it is still in = use 'in Africa', as if there is a third world time warp that forces them = to use obsolete software as well as obsolete hardware...


The machine portability issue is real, it can even be solved = inexpensively using cell phones and PDAs that have the ability to run a = downloaded OTP application.



-----Original Message-----
From: saag-bounces@ietf.org on behalf of Peter Gutmann
Sent: Wed 3/4/2009 1:41 AM
To: jhutz@cmu.edu; saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

Jeffrey Hutzelman <jhutz at cmu.edu> writes:

>You seem to imply that only weird technical people have or use more = than one
>computer. This is certainly not true; many people have a computer at = home and
>one at work, and many of those are quite non-technical. Computers = have become
>commonplace desktop items both in the home and in the office.

Thanks, you just won me $20.

(The wager was that, no matter how many disclaimers and explanatory = comments I
add (e.g. "not perfect but works for most of the people most of the = time and
it's a damn sight better than what we have now"), someone will = always, always
pipe up with some variation of "I own eight computers and this = would never
work for me and therefore it won't work for anyone else = either".  As long as
there are at least 2-3 geeks in the audience and they're not HCI people, = this
one never fails).

>Also, telling people "if the disk on your home PC dies, your = life is over" is
>a good way to get them _not_ to use a scheme like this.

How is this different from the fact that if the never-backed-up 250GB = disk
full of financial records, family photos, personal letters, and business = data
on their PC dies their life is over anyway, whether there's crypto info = on
there or not?  If you think that having to do a password reset for = the few
critical accounts that actually matter and re-enrolling for
www.knittingpatterns.com is in the same league as losing your business = account
records and the last photos taken of your parents before they passed = away then
you seem to have a somewhat odd interpretation of "a life" = :-).

Peter.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C99CCD.F9D1F202-- From jhutz@cmu.edu Wed Mar 4 08:21:42 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C15E3A6D29 for ; Wed, 4 Mar 2009 08:21:42 -0800 (PST) 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 BX31mwRY672p for ; Wed, 4 Mar 2009 08:21:41 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 89C443A6C29 for ; Wed, 4 Mar 2009 08:21:19 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (174-147-215-117.pools.spcsdns.net [174.147.215.117]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n24GLdho009726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 11:21:41 -0500 (EST) Date: Wed, 04 Mar 2009 11:21:39 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , saag@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:21:42 -0000 --On Wednesday, March 04, 2009 07:41:08 PM +1300 Peter Gutmann wrote: > Thanks, you just won me $20. > > (The wager was that, no matter how many disclaimers and explanatory > comments I add (e.g. "not perfect but works for most of the people most > of the time and it's a damn sight better than what we have now"), > someone will always, always pipe up with some variation of "I own eight > computers and this would never work for me and therefore it won't work > for anyone else either". As long as there are at least 2-3 geeks in the > audience and they're not HCI people, this one never fails). I don't think you won your wager. I said nothing of the sort. What I said was that _most_ people use more than one computer. Not own, just use. Not eight, just "more than one". From jhutz@cmu.edu Wed Mar 4 08:31:45 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573553A6CD5 for ; Wed, 4 Mar 2009 08:31:45 -0800 (PST) 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 N-5bXT6CWH0l for ; Wed, 4 Mar 2009 08:31:44 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 73A0D3A6D01 for ; Wed, 4 Mar 2009 08:31:44 -0800 (PST) Received: from 68-247-180-249.pools.spcsdns.net (174-147-215-117.pools.spcsdns.net [174.147.215.117]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n24GW5Ko010137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 11:32:06 -0500 (EST) Date: Wed, 04 Mar 2009 11:32:04 -0500 From: Jeffrey Hutzelman To: "Hallam-Baker, Phillip" , Peter Gutmann , saag@ietf.org Message-ID: <1A3A77AE3B3614022A6C60C3@atlantis.pc.cs.cmu.edu> In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B2F7@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C3166155768B2F7@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 16:31:45 -0000 --On Wednesday, March 04, 2009 05:34:43 AM -0800 "Hallam-Baker, Phillip" wrote: > We are now into the identity issue which has precisley nothing to do with > algorithm transitions. Thanks for bringing us back around to the original point. I'm not sure how we got into talking about identity and user credentials, but I seem to recall this thread started with a discussion of hash algorithm transition, and rather quickly moved away from that topic without any real resolution. Can we perhaps get back to discussing a technical problem we can solve, instead of one that is outside our expertise? -- Jeff From tytso@mit.edu Wed Mar 4 10:16:16 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5960228C430 for ; Wed, 4 Mar 2009 10:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, IP_NOT_FRIENDLY=0.334] 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 5LL0n0Sak+Ol for ; Wed, 4 Mar 2009 10:16:15 -0800 (PST) Received: from thunker.thunk.org (THUNK.ORG [69.25.196.29]) by core3.amsl.com (Postfix) with ESMTP id 6B6BF28C42E for ; Wed, 4 Mar 2009 10:16:15 -0800 (PST) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1Leve1-00012f-NK; Wed, 04 Mar 2009 13:16:37 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1Levdz-0002RP-PL; Wed, 04 Mar 2009 13:16:35 -0500 Date: Wed, 4 Mar 2009 13:16:35 -0500 From: Theodore Tso To: Jeffrey Hutzelman Message-ID: <20090304181635.GC6305@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:16:16 -0000 On Wed, Mar 04, 2009 at 11:21:39AM -0500, Jeffrey Hutzelman wrote: > --On Wednesday, March 04, 2009 07:41:08 PM +1300 Peter Gutmann > wrote: > >> Thanks, you just won me $20. >> >> (The wager was that, no matter how many disclaimers and explanatory >> comments I add (e.g. "not perfect but works for most of the people most >> of the time and it's a damn sight better than what we have now"), >> someone will always, always pipe up with some variation of "I own eight >> computers and this would never work for me and therefore it won't work >> for anyone else either". As long as there are at least 2-3 geeks in the >> audience and they're not HCI people, this one never fails). > > I don't think you won your wager. I said nothing of the sort. > What I said was that _most_ people use more than one computer. > Not own, just use. Not eight, just "more than one". How many people have a laptop plus an iPhone, for example? :-) Maybe even a non-techie's Macbook? - Ted From pbaker@verisign.com Wed Mar 4 10:34:36 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0B428C172 for ; Wed, 4 Mar 2009 10:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8JrVNxj+AgMM for ; Wed, 4 Mar 2009 10:34:35 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id 93F5328C123 for ; Wed, 4 Mar 2009 10:34:35 -0800 (PST) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n24IYw9h005331; Wed, 4 Mar 2009 10:34:58 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 10:34:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CF7.EB5D2CC2" Date: Wed, 4 Mar 2009 10:34:57 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2FA@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] SHA-1 to SHA-n transition Thread-Index: Acmc5sctBEbpTWrTQrasOfazvo7AxgAD9Y7Q References: <2788466ED3E31C418E9ACC5C3166155768B2F7@mou1wnexmb09.vcorp.ad.vrsn.com> <1A3A77AE3B3614022A6C60C3@atlantis.pc.cs.cmu.edu> From: "Hallam-Baker, Phillip" To: "Jeffrey Hutzelman" , "Peter Gutmann" , X-OriginalArrivalTime: 04 Mar 2009 18:34:59.0007 (UTC) FILETIME=[EC2E1CF0:01C99CF7] Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:34:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CF7.EB5D2CC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Jeff. At this point I think that it is clear that we can solve this problem, = albeit with solutions that are somewhat 'yukky'. The most important = questions in my mind are: * Is the deployment deadlock problem real? * Is the problem significant enough to add a barnacle to SSL or PKIX? The problem with barnacles is not the individual barnacle, its the fact = that they accumulate and eventually slow the ship down. I don't see the = 'yuk' factor as being trivial. On the other hand a deployment deadlock = on SHA-n makes me nervous. -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Wed 3/4/2009 11:32 AM To: Hallam-Baker, Phillip; Peter Gutmann; saag@ietf.org Cc: jhutz@cmu.edu Subject: RE: [saag] SHA-1 to SHA-n transition =20 --On Wednesday, March 04, 2009 05:34:43 AM -0800 "Hallam-Baker, Phillip" = wrote: > We are now into the identity issue which has precisley nothing to do = with > algorithm transitions. Thanks for bringing us back around to the original point. I'm not sure = how=20 we got into talking about identity and user credentials, but I seem to=20 recall this thread started with a discussion of hash algorithm = transition,=20 and rather quickly moved away from that topic without any real = resolution.=20 Can we perhaps get back to discussing a technical problem we can solve,=20 instead of one that is outside our expertise? -- Jeff ------_=_NextPart_001_01C99CF7.EB5D2CC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] SHA-1 to SHA-n transition

Thanks Jeff.

At this point I think that it is clear that we can solve this problem, = albeit with solutions that are somewhat 'yukky'. The most important = questions in my mind are:

* Is the deployment deadlock problem real?
* Is the problem significant enough to add a barnacle to SSL or = PKIX?

The problem with barnacles is not the individual barnacle, its the fact = that they accumulate and eventually slow the ship down. I don't see the = 'yuk' factor as being trivial. On the other hand a deployment deadlock = on SHA-n makes me nervous.


-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]
Sent: Wed 3/4/2009 11:32 AM
To: Hallam-Baker, Phillip; Peter Gutmann; saag@ietf.org
Cc: jhutz@cmu.edu
Subject: RE: [saag] SHA-1 to SHA-n transition

--On Wednesday, March 04, 2009 05:34:43 AM -0800 "Hallam-Baker, = Phillip"
<pbaker@verisign.com> wrote:

> We are now into the identity issue which has precisley nothing to = do with
> algorithm transitions.

Thanks for bringing us back around to the original point.  I'm not = sure how
we got into talking about identity and user credentials, but I seem = to
recall this thread started with a discussion of hash algorithm = transition,
and rather quickly moved away from that topic without any real = resolution.
Can we perhaps get back to discussing a technical problem we can = solve,
instead of one that is outside our expertise?

-- Jeff

------_=_NextPart_001_01C99CF7.EB5D2CC2-- From sommerfeld@sun.com Wed Mar 4 10:43:28 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAB428C150 for ; Wed, 4 Mar 2009 10:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 VE99B7avK-+L for ; Wed, 4 Mar 2009 10:43:28 -0800 (PST) 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 1E3DF28C0D8 for ; Wed, 4 Mar 2009 10:43:28 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n24IhmdZ014310; Wed, 4 Mar 2009 18:43:49 GMT Received: from localhost.east.sun.com (vroom.SFBay.Sun.COM [10.7.251.192]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n24Ihlv9059632; Wed, 4 Mar 2009 13:43:48 -0500 (EST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n24IhlCl006704; Wed, 4 Mar 2009 10:43:47 -0800 (PST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n24Ihinm006700; Wed, 4 Mar 2009 10:43:44 -0800 (PST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Theodore Tso In-Reply-To: <20090304181635.GC6305@mit.edu> References: <20090304181635.GC6305@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 04 Mar 2009 10:43:42 -0800 Message-Id: <1236192222.9386.76.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:43:28 -0000 On Wed, 2009-03-04 at 13:16 -0500, Theodore Tso wrote: > How many people have a laptop plus an iPhone, for example? :-) > > Maybe even a non-techie's Macbook? or a gaming console with a network connection and a web browser? From pbaker@verisign.com Wed Mar 4 10:48:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FFFB28C172 for ; Wed, 4 Mar 2009 10:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SC9rZSSLFACw for ; Wed, 4 Mar 2009 10:48:10 -0800 (PST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id F10893A698D for ; Wed, 4 Mar 2009 10:47:50 -0800 (PST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n24ImGeq005904; Wed, 4 Mar 2009 10:48:16 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 10:48:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99CF9.C72AEEFE" Date: Wed, 4 Mar 2009 10:48:15 -0800 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2FB@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Credential portability RE: [saag] SHA-1 to SHA-n transition Thread-Index: Acmc9ZDPN/t8YnpqTC6l/++w6N/HnwAAvw4q References: <20090304181635.GC6305@mit.edu> From: "Hallam-Baker, Phillip" To: "Theodore Tso" , "Jeffrey Hutzelman" X-OriginalArrivalTime: 04 Mar 2009 18:48:16.0922 (UTC) FILETIME=[C7C647A0:01C99CF9] Cc: saag@ietf.org Subject: [saag] Credential portability RE: SHA-1 to SHA-n transition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 18:48:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99CF9.C72AEEFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are nine machines that have a keyboard and display in the house, = but I only use three of them on a regular basis. I think that is the point. Even if I end up having to register or pair = each machine, that is three registrations, and once that is done I = should have seamless access across all three machines. Basically any scheme that is robust enough to cope with the fact that = desktops have a five year max lifespan and laptops typically two is = going to be able to cope with the degree of portability that most users = require. Having spent a whole night last week trying to install ubuntu, only to = discover that the official 'CD-ROM' distribution is too large to fit on = a CD-ROM, I am somewhat skeptical as to the claims made by techies as to = usability. Incidentally, that is also the reason that hardware has a = more limited effective life than folk imagine. -----Original Message----- From: saag-bounces@ietf.org on behalf of Theodore Tso Sent: Wed 3/4/2009 1:16 PM To: Jeffrey Hutzelman Cc: saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition =20 On Wed, Mar 04, 2009 at 11:21:39AM -0500, Jeffrey Hutzelman wrote: > --On Wednesday, March 04, 2009 07:41:08 PM +1300 Peter Gutmann =20 > wrote: > >> Thanks, you just won me $20. >> >> (The wager was that, no matter how many disclaimers and explanatory >> comments I add (e.g. "not perfect but works for most of the people = most >> of the time and it's a damn sight better than what we have now"), >> someone will always, always pipe up with some variation of "I own = eight >> computers and this would never work for me and therefore it won't = work >> for anyone else either". As long as there are at least 2-3 geeks in = the >> audience and they're not HCI people, this one never fails). > > I don't think you won your wager. I said nothing of the sort. > What I said was that _most_ people use more than one computer. > Not own, just use. Not eight, just "more than one". How many people have a laptop plus an iPhone, for example? :-) Maybe even a non-techie's Macbook? - Ted _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------_=_NextPart_001_01C99CF9.C72AEEFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Credential portability RE: [saag] SHA-1 to SHA-n = transition

There are nine machines that have a keyboard and = display in the house, but I only use three of them on a regular = basis.

I think that is the point. Even if I end up having to register or pair = each machine, that is three registrations, and once that is done I = should have seamless access across all three machines.


Basically any scheme that is robust enough to cope with the fact that = desktops have a five year max lifespan and laptops typically two is = going to be able to cope with the degree of portability that most users = require.

Having spent a whole night last week trying to install ubuntu, only to = discover that the official 'CD-ROM' distribution is too large to fit on = a CD-ROM, I am somewhat skeptical as to the claims made by techies as to = usability. Incidentally, that is also the reason that hardware has a = more limited effective life than folk imagine.


-----Original Message-----
From: saag-bounces@ietf.org on behalf of Theodore Tso
Sent: Wed 3/4/2009 1:16 PM
To: Jeffrey Hutzelman
Cc: saag@ietf.org
Subject: Re: [saag] SHA-1 to SHA-n transition

On Wed, Mar 04, 2009 at 11:21:39AM -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, March 04, 2009 07:41:08 PM +1300 Peter = Gutmann 
> <pgut001@cs.auckland.ac.nz> wrote:
>
>> Thanks, you just won me $20.
>>
>> (The wager was that, no matter how many disclaimers and = explanatory
>> comments I  add (e.g. "not perfect but works for most = of the people most
>> of the time and  it's a damn sight better than what we = have now"),
>> someone will always, always  pipe up with some variation = of "I own eight
>> computers and this would never  work for me and therefore = it won't work
>> for anyone else either".  As long as  there are = at least 2-3 geeks in the
>> audience and they're not HCI people, this  one never = fails).
>
> I don't think you won your wager.  I said nothing of the = sort.
> What I said was that _most_ people use more than one computer.
> Not own, just use.  Not eight, just "more than = one".

How many people have a laptop plus an iPhone, for example?   = :-)

Maybe even a non-techie's Macbook?

         =        =         =               =         - Ted
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag

------_=_NextPart_001_01C99CF9.C72AEEFE-- From housley@vigilsec.com Wed Mar 4 13:16:59 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55CC03A693B for ; Wed, 4 Mar 2009 13:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.768 X-Spam-Level: X-Spam-Status: No, score=-101.768 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 BfAia+xctSEt for ; Wed, 4 Mar 2009 13:16:57 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 580733A6874 for ; Wed, 4 Mar 2009 13:16:57 -0800 (PST) Received: (qmail 4901 invoked by uid 0); 4 Mar 2009 21:17:19 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 4 Mar 2009 21:17:19 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Mar 2009 16:17:21 -0500 To: saag@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20090304211657.580733A6874@core3.amsl.com> Subject: [saag] Fwd: Call for Participation: OASIS Key Management Interoperability Protocol (KMIP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 21:16:59 -0000 People on this list make be interested in this proposed OASIS Technical Committee.

Russ


-----Original Message-----
From: Mary McRae
To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
CC: kmip@lists.oasis-open.org
Sent: Wed Mar 04 15:17:07 2009
Subject: Call for Participation: OASIS Key Management Interoperability Protocol (KMIP) Technical Committee

To:  OASIS members & interested parties

   A new OASIS technical committee is being formed. The OASIS Key Management
Interoperability Protocol (KMIP) Technical Committee has been proposed by
the members of OASIS listed below. The TC name, statement of purpose, scope,
list of deliverables, audience, and language specified in the proposal will
constitute the TC's official charter. Submissions of technology for
consideration by the TC, and the beginning of technical discussions, may
occur no sooner than the TC's first meeting.

   The eligibility requirements for becoming a participant in the TC at the
first meeting (see details below) are:

   (a) you must be an employee of an OASIS member organization or an
individual member of OASIS, and
   (b) you must join the Technical Committee, which members may do by using
the "Join this TC" button on the TC's public page at [a].

   To be considered a voting member at the first meeting, you must:
   (a) join the Technical Committee at least 15 days prior to the first
meeting; and
   (b) you must attend the first meeting of the TC, at the time and date
fixed below.

Of course, participants also may join the TC at a later time. OASIS and the
TC welcomes all interested parties.

   Non-OASIS members who wish to participate may contact us about joining
OASIS [b]. In addition, the public may access the information resources
maintained for each TC: a mail list archive, document repository and public
comments facility, which will be linked from the TC's public home page at
[a].

   Please feel free to forward this announcement to any other appropriate
lists. OASIS is an open standards organization; we encourage your
participation.

Regards,

Mary

---------------------------------------------------
Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
phone: 1.603.232.9090

[a] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip
[b] See http://www.oasis-open.org/join/

CALL FOR PARTICIPATION
OASIS Key Management Interoperability Protocol (KMIP) Technical Committee

Statement of purpose:
The KMIP Technical Committee will develop specification(s) for the
interoperability of key management services with key management clients. The
specifications will address anticipated customer requirements for key
lifecycle management (generation, refresh, distribution, tracking of use,
life-cycle policies including states, archive, and destruction), key
sharing, and long-term availability of cryptographic objects of all types
(public/private keys and certificates, symmetric keys, and other forms of
"shared secrets") and related areas.


Scope:
The initial goal is to define an interoperable protocol for standard
communication between key management servers, and clients and other actors
which can utilize these keys. Secure key management for TPMs (Trusted
Platform Modules) and Storage Devices will be addressed. The scope of the
keys addressed is enterprise-wide, including a wide range of actors: that
is, machine, software, or human participants exercising the protocol within
the framework. Actors for KMIP may include:

* Storage Devices
* Networking Devices
* Personal devices with embedded storage (e.g. Personal Computers, Handheld
Computers, Cell Phones)
* Users
* Applications
* Databases
* Operating Systems
* Input/Output Subsystems
* Management Frameworks
* Key Management Systems
* Agents

Out of scope areas include:
* Implementation specific internals of prototypes and products
* Multi-vendor Key Management facility mirrors or clusters
* Definition of an architectural design for a central enterprise key
management or certificate management system other than any necessary models,
interfaces and protocols strictly required to support interoperability
between Actors in the multi-vendor certificate and key management framework.
* Framework interfaces not dedicated to secure key and certificate
management
* Certain areas of functionality related to key management are also outside
the scope of this technical committee, in particular registration of
clients, server-to-server communication and key migration.
* Bindings other than tag-length-value wire protocol and XSD-based
encodings.

List of deliverables:
The deliverables for the KMIP Technical Committee are anticipated to include
the following:
* Revised KMIP Specification v0.98. This provides the normative expression
of the protocol, including objects, attributes, operations and other
elements. A Committee Specification is scheduled for completion within 12
months of the first TC meeting.
* Revised KMIP Usage Guide v0.98. This provides illustrative and explanatory
information on implementing the protocol, including authentication profiles,
implementation recommendations, conformance guidelines and security
considerations. A Committee Specification is scheduled for completion within
12 months of the first TC meeting.
* Revised KMIP Use Cases and Test Cases v0.98. This provides sample use
cases for KMIP, test cases for implementing those use cases, and examples of
the protocol implementing those test cases. A Committee Specification is
scheduled for completion within 12 months of the first TC meeting.
* Revised KMIP Frequently Asked Questions. This document provides guidance
on what KMIP is, the problems it is intended to address and other frequently
asked questions.

KMIP, as defined in the above deliverables, will be scoped to include the
following:
1) Comprehensive Key and Certificate Lifecycle Management Framework
  A. Lifecycle Management Framework to Include:
    a) Provisioning of Keys and Certificates
       i) Creation
      ii) Distribution
     iii) Exchange/Interchange
      iv) Auditing
    b) Reporting
    c) Logging (Usage tracking)
    d) Backup
    e) Restore
    f) Archive
    g) Update/Refresh
    h) Management of trust mechanisms between EKCLM (Enterprise Key and
Certificate Lifecycle Management) actors only as necessary to support EKCLM
  B. Comprehensive Key and Certificate Policy Framework to include:
    a) Creation
    b) Distribution
    c) Exchange/Interchange
    d) Auditing
    e) Reporting
    f) Logging (Usage tracking)
    g) Backup
    h) Restore
    i) Archive
    j) Update/Refresh
    k) Expectation of Policy Enforcement
       i) At endpoints
      ii) At Key Manager
     iii) At intermediaries between endpoints and Key Manager facility
  C. Interoperability between Machine Actors in performing all aspects of A)
and B), and addressing:
    a) pre-provisioning and late binding of keys and certificates
    b) support for hierarchical or delegation or direct models
    c) actor discovery and enrollment as necessary to support ECKLM
    d) key, certificate and policy migration
    e) audit and logging facilities
  D. General Capabilities may include:
    a) Secure and Robust Mechanisms, Techniques, Protocols and Algorithms
    b) Recovery capabilities, only as needed by interoperable interfaces,
anticipating power failure, or other common failures of automated Actors
    c) Forward compatibility considerations
    d) Interface to Identity Management facilities as necessary for A) and
B)
    e) Interface to Enterprise Directory facilities as necessary for A) and
B)

KMIP TC will also support activities to encourage adoption of KMIP. This
would likely include:
Interoperability sessions to test effectiveness of the specification
Reference implementations of KMIP functionality

IPR Mode under which the TC will operate:
The KMIP TC is anticipated to operate under RF on RAND.


Anticipated audience or users:
KMIP is intended for the following audiences:

* Architects, designers and implementers of providers and consumers of
enterprise key management services.

Language:
Work group business and proceedings will be conducted in English.


Non-normative information

Identification of similar or applicable work:

Similar work is currently underway in several other organizations:
* OASIS EKMI TC. We see KMIP TC as addressing a broader scope than the
primarily symmetric key focused EKMI, providing a more comprehensive
protocol in which SKSML can potentially participate.
* IEEE P1619.3. We see KMIP TC as addressing a broad scope than the
primarily storage-related P1619.3.
* TCG Infrastructure Working Group. We see KMIP TC as addressing a broader
scope than the primarily TPM related TCG IWG.
* IETF Keyprov. We see KMIP TC as addressing a broader scope than the
primarily mobile-related IETF Keyprov.

KMIP TC intends to establish liaisons with each of these organizations and
may also establish liaisons with other organizations that are identified as
focused on similar or applicable work.

Date, time, and location of the first meeting:
The date for the first meeting is April 24th 2009, from 9am PDT until 5pm
PDT, to be held as a Face to Face meeting in San Francisco in conjunction
with the RSA Conference. Call-in facilities will be provided for those
unable to attend in person.

Projected on-going meeting:
Conference calls will be held weekly, to be sponsored by one or more of the
companies proposing the KMIP TC. These conference calls will be complemented
by the following:
* Face to face meetings as determined by the KMIP TC.
* General communication will be via email reflectors with archiving provided
by the KMIP TC.
* KMIP TC progress will be communicated via a KMIP TC web page.
* The KMIP TC will communicate (conference calls, joint working sessions,
etc.) with external groups as appropriate.
* The KMIP TC will communicate (conference calls, joint working sessions
etc.) with internal OASIS groups (other TCs) as appropriate.

Names, electronic mail addresses, and membership affiliations of at least
Minimum Membership:
Robert Griffin, EMC/RSA, Robert.griffin@rsa.com
Robert Philpott, EMC/RSA, Robert.philpott@rsa.com
Mark Schiller, HP, mark.schiller@hp.com
Jishnu Mukerji, HP, jishnu@hp.com
Anthony Nadalin, IBM, drsecure@us.ibm.com
Robert Haas, IBM, rha@zurich.ibm.com
Walt Hubis, LSI, walt.hubis@lsi.com
Jon Geater, Thales, jon.geater@thales-esecurity.com
Marcus Streets, Thales, marcus.streets@thales-esecurity.com
Martin Skagen, Brocade, mskagen@brocade.com
Karla Thomas, Brocade, karlat@brocade.com
Scott Kipp, Brocade, skipp@brocade.com
Subhash Sankuratripati, NetApp, Subhash@netapp.com
Paolo Bezoari, NetApp, Bezoari@netapp.com
Dave B Anderson, Seagate, dave.b.anderson@seagate.com
Landon Curt Noll, Cisco, chongo@cisco.com


The name of the Convener who must be an Eligible Person:
Robert Griffin (EMC)


The name of the Member Section with which the TC intends to affiliate, if
any.
The KMIP TC intends to affiliate with the IDtrust Member Section.

List of contributions of existing technical work that the proposers
anticipate will be made to this TC:
* KMIP Specification v0.98
http://xml.coverpages.org/KMIP/KMIP-v0.98-final.pdf 
* KMIP Usage Guide v0.98
http://xml.coverpages.org/KMIP/KMIP-UsageGuide-v0.98-final.pdf
* KMIP Use Cases and Test Cases v0.98
http://xml.coverpages.org/KMIP/KMIP-UseCases-v0.98-final.pdf
* KMIP FAQ
http://xml.coverpages.org/KMIP/KMIP-FAQ.pdf


Frequently Asked Questions (FAQ) document:
See preceding list of contributions.


Proposed working title and acronym for the specification(s) to be developed
by the TC.
* KMIP Specification
* KMIP Usage Guide
* KMIP Use Cases and Test Cases
* KMIP FAQ







---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium communications.

Opt-out requests may be sent to member-services@oasis-open.org, however, all members are strongly encouraged to maintain a subscription to this list.

 From gregory.ietf@gmail.com Mon Mar 16 13:10:58 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0533A6B1C; Mon, 16 Mar 2009 13:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4+630anInu8h; Mon, 16 Mar 2009 13:10:57 -0700 (PDT) Received: from mail-gx0-f165.google.com (mail-gx0-f165.google.com [209.85.217.165]) by core3.amsl.com (Postfix) with ESMTP id 4C59C3A684E; Mon, 16 Mar 2009 13:10:57 -0700 (PDT) Received: by gxk9 with SMTP id 9so2179356gxk.13 for ; Mon, 16 Mar 2009 13:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=O1a18HrTsd7l+bPgyv9YT5rHCOP0pzQUQv/5cIBwbQY=; b=F5GctCoZsA1luOTyj0VgPHufMdra+tuKyL0s3zFeZJMbY127jLPKp0DyJsJ2n4ZUa+ 3oOyhsaudNT5+81pVeXtFQ4zv/alXvsiL8DFeQJKfrFvbeTJ0j0kjaKatL5xq5wHTdCI GcGsAQEPhSc4OjgRUNHKYVV6e/F5tiz0gmyx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=TARE6hEuQqDIvXXgkpyq4a2dgX2fqfJS66igyNAjS4kM5cBYzU+7ydCwHgiZK57ALn rlS1EHugpmAO7B1l2BGvZE/i81ch7GFER1QaICLhl6rjCBI0hwxIMGTxHBxROIK1GIpB D/bbcVoqUiOZrIRHwzZmMO2C+D9GtbryxTyXI= MIME-Version: 1.0 Received: by 10.231.16.74 with SMTP id n10mr1120752iba.23.1237234298949; Mon, 16 Mar 2009 13:11:38 -0700 (PDT) Date: Mon, 16 Mar 2009 13:11:38 -0700 Message-ID: From: Gregory Lebovitz To: kmart@ietf.org, saag@ietf.org, rtgwg@ietf.org Content-Type: multipart/alternative; boundary=000325574d7ae491c50465420e7a Cc: Ross Callon Subject: [saag] Pls review draft-lebovitz-kmart-roadmap-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 20:10:58 -0000 --000325574d7ae491c50465420e7a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey all, The -01 draft that captures the goals, definition of work, and order of priorities for securing routing protocol transports is here: http://www.ietf.org/internet-drafts/draft-lebovitz-kmart-roadmap-01.txt This represents joint work of the IAB, RTG and SAAG areas, under the guidance of the ADs of both. This document will be presented in IETF74 at: - RTG WG - SAAG - SIDR (brief advertisement) - Others ? (pls let me know) Pls respond with comments to me, and cc the kmart@ietf.org mail list. Gregory. -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000325574d7ae491c50465420e7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey all,
=A0
The -01 draft that captures the goals, definition of work, and order o= f priorities for securing routing protocol transports is here:
=A0
This represents joint work of the IAB, RTG and SAAG areas, under the g= uidance of the ADs of both.
=A0
This document will be presented in IETF74=A0at:
=A0- RTG WG
=A0- SAAG
=A0- SIDR (brief advertisement)
=A0- Others ? (pls let me know)
=A0
Pls respond with comments to me, and cc the kmart@ietf.org mail list.
=A0
Gregory.

--
----
IETF related email fromGregory M. Lebovitz
Juniper Networks
--000325574d7ae491c50465420e7a-- From Hannes.Tschofenig@gmx.net Wed Mar 18 01:55:06 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C6928C158 for ; Wed, 18 Mar 2009 01:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, GB_I_LETTER=-2] 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 JI2egUyQxaSV for ; Wed, 18 Mar 2009 01:55:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 60F633A69BC for ; Wed, 18 Mar 2009 01:55:05 -0700 (PDT) Received: (qmail invoked by alias); 18 Mar 2009 08:55:48 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp046) with SMTP; 18 Mar 2009 09:55:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX198x+JEA0l8t8DxjJ1NnbWWTtmB5ed2RpKg5ajbel DNvS1+asgYzRiA From: "Hannes Tschofenig" To: Date: Wed, 18 Mar 2009 10:56:59 +0200 Message-ID: <000201c9a7a7$7fe34e70$9c11a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmhEhfYzVUcOjReTn2UlDmONQfYhwALDYTwAADb92ABmRbjIA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Subject: [saag] OAuth X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 08:55:06 -0000 Hi all, I would like to point you to the Open Web authentication BOF on Monday, 1300-1500, in Continental 4. Your security related review comments are highly appreciated. Here is the link to the latest version of the OAuth draft: http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.txt Ciao Hannes >-----Original Message----- >From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf Of ext Eran Hammer-Lahav >Sent: 10 March, 2009 07:34 >To: oauth@ietf.org >Subject: Re: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt > >Forgot to mention the blog post is: > >http://www.hueniverse.com/hueniverse/2009/03/oauth-core-10-reborn.html > >EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, March 09, 2009 10:20 PM >> To: oauth@ietf.org >> Subject: [oauth] FW: I-D Action:draft-hammer-oauth-01.txt >> >> I spent the last 3 days writing the entire spec from scratch (except >> for the security consideration section which was just >adjusted to the >> new terminology). The new revision is based on feedback I collected >> over the past year for the original specification. The main >> differences >> are: >> >> * Terminology. Gone are the confusing terms (consumer, >request token, >> consumer key, etc.). Instead I am using terms from the HTTP spec, >> slightly adjusted. >> >> * Structure. The previous revision mixed authentication with >> authorization and had very little reason to the way >normative text was >> placed across sections. The new structure splits the spec in >two. The >> first part talks about how to make authenticated requests using two >> sets of credentials. The second part offers a method (one of >many) for >> getting a token via redirection. >> >> * Encoding. The biggest issue with the previous revision was >confusion >> over parameter encoding and the signature base string. I cleaned up >> that section, added new examples, and removed a couple >instruction to >> encode the signature (bugs). If followed to the letter, the >spec would >> break all existing implementations... The good thing is it is >> confusing enough that most people understood it the wrong way (which >> is actually the right way). Take a look at the old section >about PLAINTEXT: >> >> --- >> oauth_signature is set to the concatenated encoded values of the >> Consumer Secret and Token Secret, separated by a '&' >character (ASCII >> code 38), even if either secret is empty. The result MUST be encoded >> again. >> --- >> >> 'The result MUST be encoded again' is just plain wrong. It >is encoded >> again but according to the parameter transmission method, not the >> special way OAuth does it, and the spec as written would actually >> double encode it. >> >> * Normative requirements. The spec previously contained many >MUSTs and >> SHOULDs about stuff that could not be verified like >documentation and >> obtaining client credentials. I took out all the ones that didn't >> actually made any practical difference. >> >> I'm sure there is more, since this is practically a brand new spec >> (same exact protocol). Please read and provide feedback. >> >> EHL >> >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org >> Sent: Monday, March 09, 2009 4:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-hammer-oauth-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : The OAuth Core Protocol >> Author(s) : E. Hammer-Lahav, B. Cook >> Filename : draft-hammer-oauth-01.txt >> Pages : 33 >> Date : 2009-03-09 >> >> This document specifies the OAuth core protocol. OAuth provides a >> method for clients to access server resources on behalf of another >> party (such a different client or an end user). It also provides a >> redirection-based user agent process for end users to >authorize access >> to clients by substituting their credentials (typically, a username >> and password pair) with a different set of delegation- specific >> credentials. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hammer-oauth-01.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. >_______________________________________________ >oauth mailing list >oauth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > From kent@bbn.com Tue Mar 24 13:26:28 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92923A6A93 for ; Tue, 24 Mar 2009 13:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 vIyf+kHAy-k9 for ; Tue, 24 Mar 2009 13:26:28 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CC3653A680B for ; Tue, 24 Mar 2009 13:26:27 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.68.195]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmDDS-0002oS-9g for saag@ietf.org; Tue, 24 Mar 2009 16:27:18 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 24 Mar 2009 16:27:15 -0400 To: saag@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-974196059==_ma============" Subject: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:26:28 -0000 --============_-974196059==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" PKIX Meeting report We have one document in the RFC editor's queue and twelve I-Ds in process. PRQP, targeted to Experimental status, will be revised one more time, and them move to WGLC. Traceable Autonomous Certificates, also targeted to Experimental status, has been revised in response to numerous comments from David Cooper. It will be posted and hopefully move to WGLC next month. The Trust Anchor management requirements document passed WGLC. The format for TA material and the TAMP spec are both ready for WGLC. An initial OCSP algorithm agility I-D defines the default behavior for a client, and proposes additional client behavior rules to deal with one algorithm mismatch problem. However, SHA-1 is hardwired into the spec and this needs to be addressed, if only for perception reasons. Providing true algorithm agility here may require a more innovative approach, e.g., use of different port or protocol values. RFC 3161 (Time Stamp Protocol,) will be updated to address a hash agility concern and to address terminology issues (to be compatible with ETSI documents). David Cooper is assembling data to support advancement of RFC 5280 to Proposed status. The new ASN.1 draft has been revised and is ready for WGLC, in parallel with a straw poll to determine whether the document should be Informational or Standards track. The I-D that provides OIDs for use with DSA and ECDSA will progress to WGLC, despite its dependence on a FIPS (186-3) that has yet to be issued. The meeting concluded with a presentation by Stefan Santesson on a proposal to include a PDF as a next generation logotype capability. The goal is to do a better job of conveying the identity of a certificate holder to a (human) relying party, compared to display of certificate contents, etc. --============_-974196059==_ma============ Content-Type: text/html; charset="us-ascii" PKIX report
PKIX Meeting report

We have one document in the RFC editor's queue and twelve I-Ds in process.

PRQP, targeted to Experimental status, will be revised one more time, and them move to WGLC.

Traceable Autonomous Certificates, also targeted to Experimental status, has been revised in response to numerous comments from David Cooper. It will be posted and hopefully move to WGLC next month.

The Trust Anchor management requirements document passed WGLC. The format for TA material and the TAMP spec are both ready for WGLC.

An initial OCSP algorithm agility I-D defines the default behavior for a client, and proposes additional client behavior rules to deal with one algorithm mismatch problem. However, SHA-1 is hardwired into the spec and this needs to be addressed, if only for perception reasons. Providing true algorithm agility here may require a more innovative approach, e.g., use of different port or protocol values.

RFC 3161 (Time Stamp Protocol,) will be updated to address a hash agility concern and to address terminology issues (to be compatible with ETSI documents).

David Cooper is assembling data to support advancement of RFC 5280  to Proposed status.

The new ASN.1 draft has been revised and is ready for WGLC,  in parallel with a straw poll to determine whether the document should be Informational or Standards track.

The I-D that provides OIDs for use with DSA and ECDSA will progress to WGLC, despite its dependence on a FIPS (186-3) that has yet to be issued.

The meeting concluded with a presentation by Stefan Santesson on a proposal to include a PDF as a next generation logotype capability. The goal is to do a better job of conveying the identity of a certificate holder to a (human) relying party, compared to  display of certificate contents, etc.
--============_-974196059==_ma============-- From clonvick@cisco.com Tue Mar 24 14:02:00 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922213A6989 for ; Tue, 24 Mar 2009 14:02:00 -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 2W630P34bk9T for ; Tue, 24 Mar 2009 14:01:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CA51C3A6D3D for ; Tue, 24 Mar 2009 14:01:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,414,1233532800"; d="scan'208";a="146064378" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2009 21:02:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2OL2moO030182 for ; Tue, 24 Mar 2009 14:02:48 -0700 Received: from sjc-cde-010.cisco.com (sjc-cde-010.cisco.com [128.107.183.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2OL2mqT001361 for ; Tue, 24 Mar 2009 21:02:48 GMT Date: Tue, 24 Mar 2009 14:02:48 -0700 (PDT) From: Chris Lonvick To: saag@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=762; t=1237928568; x=1238792568; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20syslog=20WG=20report |Sender:=20; bh=7tq17YDf86tyPcEbC5wY045XMnpXlp/wSPzQ/qcSyxU=; b=QtiOhjKBuP32OCOQSHV2fX5VlyQau0Pyd9uhjmHVqOvfdW8IKJJcQazCWM b2XVSRSmPkLEwHJ2QUTWeXQXTzoqdh0JU99wEOHtfD4SFQmAdC078eNkjned kiMXClKRUST0WFkftJsOSq98jh/KSCUsH2C6uShUsuJ/hS+gUOUwY=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [saag] syslog WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:02:00 -0000 Hi, Syslog WG Report chairs: Chris Lonvick, Dave Harrington syslog did not meet at IETF 74 Milestones in our current charter: * syslog-protocol was published as RFC5424 * syslog-tls was published as RFC5425 * syslog-udp was published as RFC5426 * syslog-tc-mib is in the RFC Ed's Queue awaiting update of MIB copyright boilerplate * syslog-sign is in AD Evaluation and a revised ID is needed There are ongoing discussions about whether to recharter in the Security Area, or to recharter into the OPS Area, or to close. Most proposed topics and new goals are not securit related. Many of these are date modelling SDEs, or translating between syslog and other network management protocols such as SNMP. Thanks, David and Chris From shanna@juniper.net Tue Mar 24 15:51:01 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D1A28C0E6 for ; Tue, 24 Mar 2009 15:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 prd4XHM0-AnF for ; Tue, 24 Mar 2009 15:50:59 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 2F3E93A68B1 for ; Tue, 24 Mar 2009 15:50:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSclkBjBPLz3S6QfD8I0u58seUNjl1T9n@postini.com; Tue, 24 Mar 2009 15:51:51 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 15:49:54 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 15:49:54 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 15:49:54 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 18:49:53 -0400 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: Tue, 24 Mar 2009 18:49:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA WG report Thread-Index: AcmsH8hXHsgwY+dwSw2KhPdJ5ABQdAAqbGlg From: Stephen Hanna To: X-OriginalArrivalTime: 24 Mar 2009 22:49:53.0108 (UTC) FILETIME=[D86FB940:01C9ACD2] Subject: [saag] NEA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 22:51:01 -0000 The IETF NEA WG met on Monday afternoon. We reviewed the changes in our current Internet Drafts, draft-ietf-nea-pa-tnc-03.txt and draft-ietf-nea-pb-tnc-03.txt. We also discussed the comments received in the recently closed Working Group Last Call. The spec editors presented proposals to address all the comments and no concerns were raised. These proposals will now be forwarded to the NEA WG email list to verify WG consensus. Then new versions of the specs will be prepared and these versions will be submitted to the IESG for their review, requesting approval as Standards Track RFCs. This will complete our current set of milestones. Discussion then turned to our next steps. We need to identify or develop PT standards since this is the last thing needed to have fully interoperable systems based on the NEA protocols. We need to recharter slightly to work on PT since our current charter says that we won't do anything else until PA and PB are done. Tim Polk (our AD) said that we can start work on rechartering as soon as we have sent PA and PB to him. He suggested that our recharter focus only on PT for now. Other work related to NEA (like Assertion Attributes) can proceed as individual submissions, which can be discussed in the NEA WG and adopted as WG drafts via rechartering when they are sufficiently mature. From pbaker@verisign.com Tue Mar 24 16:49:46 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB4B3A68A2 for ; Tue, 24 Mar 2009 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.433 X-Spam-Level: X-Spam-Status: No, score=-5.433 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 gRq1kxGQstPn for ; Tue, 24 Mar 2009 16:49:45 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id D96383A67EE for ; Tue, 24 Mar 2009 16:49:40 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id n2ONoOF2018608; Tue, 24 Mar 2009 16:50:24 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:50:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACDB.4CE53F39" Date: Tue, 24 Mar 2009 16:48:18 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B34A@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] PKIX report thread-index: AcmsvvMi3/oZa4V7R7eZw6SK7aKGzQAHA7fv References: From: "Hallam-Baker, Phillip" To: "Stephen Kent" , X-OriginalArrivalTime: 24 Mar 2009 23:50:24.0612 (UTC) FILETIME=[4CFB4240:01C9ACDB] Subject: Re: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:49:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACDB.4CE53F39 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I dispute the assertion that a new protocol or port # might be required = for OCSP. The protocol is adequately extendable. =20 What I put in the slides was what I felt that the group had already = agreed to. Since this was the first occasion where the issues had been = raised, I was not proposing a solution. If it is agreed that there is a = problem, there is a simple solution. ________________________________ From: saag-bounces@ietf.org on behalf of Stephen Kent Sent: Tue 3/24/2009 4:27 PM To: saag@ietf.org Subject: [saag] PKIX report PKIX Meeting report We have one document in the RFC editor's queue and twelve I-Ds in = process. PRQP, targeted to Experimental status, will be revised one more time, = and them move to WGLC. Traceable Autonomous Certificates, also targeted to Experimental status, = has been revised in response to numerous comments from David Cooper. It = will be posted and hopefully move to WGLC next month. The Trust Anchor management requirements document passed WGLC. The = format for TA material and the TAMP spec are both ready for WGLC. An initial OCSP algorithm agility I-D defines the default behavior for a = client, and proposes additional client behavior rules to deal with one = algorithm mismatch problem. However, SHA-1 is hardwired into the spec = and this needs to be addressed, if only for perception reasons. = Providing true algorithm agility here may require a more innovative = approach, e.g., use of different port or protocol values. RFC 3161 (Time Stamp Protocol,) will be updated to address a hash = agility concern and to address terminology issues (to be compatible with = ETSI documents). David Cooper is assembling data to support advancement of RFC 5280 to = Proposed status. The new ASN.1 draft has been revised and is ready for WGLC, in parallel = with a straw poll to determine whether the document should be = Informational or Standards track. The I-D that provides OIDs for use with DSA and ECDSA will progress to = WGLC, despite its dependence on a FIPS (186-3) that has yet to be = issued. The meeting concluded with a presentation by Stefan Santesson on a = proposal to include a PDF as a next generation logotype capability. The = goal is to do a better job of conveying the identity of a certificate = holder to a (human) relying party, compared to display of certificate = contents, etc. ------_=_NextPart_001_01C9ACDB.4CE53F39 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PKIX report=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
I dispute the = assertion that a new protocol or port # might be required for OCSP. The = protocol is adequately extendable.
=0A=
 
=0A=
What I put in the slides was = what I felt that the group had already agreed to. Since this was the = first occasion where the issues had been raised, I was not proposing a = solution. If it is agreed that there is a problem, there is a simple = solution.
=0A=

=0A=
=0A= From: saag-bounces@ietf.org on = behalf of Stephen Kent
Sent: Tue 3/24/2009 4:27 = PM
To: saag@ietf.org
Subject: [saag] PKIX = report

=0A=
=0A=
PKIX Meeting = report

We have one document in the RFC editor's queue and twelve = I-Ds in process.

PRQP, targeted to Experimental status, will be = revised one more time, and them move to WGLC.

Traceable = Autonomous Certificates, also targeted to Experimental status, has been = revised in response to numerous comments from David Cooper. It will be = posted and hopefully move to WGLC next month.

The Trust Anchor = management requirements document passed WGLC. The format for TA material = and the TAMP spec are both ready for WGLC.

An initial OCSP = algorithm agility I-D defines the default behavior for a client, and = proposes additional client behavior rules to deal with one algorithm = mismatch problem. However, SHA-1 is hardwired into the spec and this = needs to be addressed, if only for perception reasons. Providing true = algorithm agility here may require a more innovative approach, e.g., use = of different port or protocol values.

RFC 3161 (Time Stamp = Protocol,) will be updated to address a hash agility concern and to = address terminology issues (to be compatible with ETSI = documents).

David Cooper is assembling data to support = advancement of RFC 5280  to Proposed status.

The new ASN.1 = draft has been revised and is ready for WGLC,  in parallel with a = straw poll to determine whether the document should be Informational or = Standards track.

The I-D that provides OIDs for use with DSA and = ECDSA will progress to WGLC, despite its dependence on a FIPS (186-3) = that has yet to be issued.

The meeting concluded with a = presentation by Stefan Santesson on a proposal to include a PDF as a = next generation logotype capability. The goal is to do a better job of = conveying the identity of a certificate holder to a (human) relying = party, compared to  display of certificate contents, = etc.
------_=_NextPart_001_01C9ACDB.4CE53F39-- From kent@bbn.com Tue Mar 24 17:00:18 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4C13A6880 for ; Tue, 24 Mar 2009 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 o1cp+5PlxXHo for ; Tue, 24 Mar 2009 17:00:17 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 54EDC3A63CB for ; Tue, 24 Mar 2009 17:00:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.68.195]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmGYL-0005El-Fv; Tue, 24 Mar 2009 20:01:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B34A@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C3166155768B34A@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 24 Mar 2009 20:00:42 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-974183231==_ma============" Cc: saag@ietf.org Subject: Re: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:00:18 -0000 --============_-974183231==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:48 PM -0700 3/24/09, Hallam-Baker, Phillip wrote: >I dispute the assertion that a new protocol or port # might be >required for OCSP. The protocol is adequately extendable. > >What I put in the slides was what I felt that the group had already >agreed to. Since this was the first occasion where the issues had >been raised, I was not proposing a solution. If it is agreed that >there is a problem, there is a simple solution. Phil, The PKIX report is a summary of the meeting minutes. I suggest you dead the PKIX minutes for a more complete description of the discussion that accompanied Stefan's presentation of your slides. For example, the minutes note that Paul Hoffman suggested the use of different ports or a different protocol number, as a possibly preferable way to address the algorithm agility concerns (vs. adding OCSP extensions). Russ emphasized the need to address the dependence on SHA-1 sooner rather than later. Steve --============_-974183231==_ma============ Content-Type: text/html; charset="us-ascii" RE: [saag] PKIX report
At 4:48 PM -0700 3/24/09, Hallam-Baker, Phillip wrote:
I dispute the assertion that a new protocol or port # might be required for OCSP. The protocol is adequately extendable.
 
What I put in the slides was what I felt that the group had already agreed to. Since this was the first occasion where the issues had been raised, I was not proposing a solution. If it is agreed that there is a problem, there is a simple solution.

Phil,

The PKIX report is a summary of the meeting minutes. I suggest you dead the PKIX minutes for a more complete description of the discussion that accompanied Stefan's presentation of your slides. For example, the minutes note that Paul Hoffman suggested the use of different ports or a different protocol number, as a possibly preferable way to address the algorithm agility concerns (vs. adding OCSP extensions). Russ emphasized the need to address the dependence on SHA-1 sooner rather than later.

Steve
--============_-974183231==_ma============-- From pbaker@verisign.com Tue Mar 24 17:53:04 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C6F3A68A7 for ; Tue, 24 Mar 2009 17:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.406 X-Spam-Level: X-Spam-Status: No, score=-5.406 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 3HNKopCrHdZL for ; Tue, 24 Mar 2009 17:53:03 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id BA4063A6ACE for ; Tue, 24 Mar 2009 17:53:02 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id n2P0SExc016473; Tue, 24 Mar 2009 17:28:14 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 17:53:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACE4.24EE2989" Date: Tue, 24 Mar 2009 17:52:51 -0700 Message-ID: <2788466ED3E31C418E9ACC5C3166155768B34D@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] PKIX report thread-index: Acms3M4wB3tNCqhVSBS7l3lVcGSLxgABzfuk References: <2788466ED3E31C418E9ACC5C3166155768B34A@mou1wnexmb09.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" To: "Stephen Kent" X-OriginalArrivalTime: 25 Mar 2009 00:53:42.0917 (UTC) FILETIME=[24F29B50:01C9ACE4] Cc: saag@ietf.org Subject: Re: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:53:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACE4.24EE2989 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I read the minutes, the summary is quite a bit different.=20 ________________________________ From: Stephen Kent [mailto:kent@bbn.com] Sent: Tue 3/24/2009 8:00 PM To: Hallam-Baker, Phillip Cc: saag@ietf.org Subject: RE: [saag] PKIX report At 4:48 PM -0700 3/24/09, Hallam-Baker, Phillip wrote: I dispute the assertion that a new protocol or port # might be required = for OCSP. The protocol is adequately extendable. =20 What I put in the slides was what I felt that the group had already = agreed to. Since this was the first occasion where the issues had been = raised, I was not proposing a solution. If it is agreed that there is a = problem, there is a simple solution. Phil, The PKIX report is a summary of the meeting minutes. I suggest you dead = the PKIX minutes for a more complete description of the discussion that = accompanied Stefan's presentation of your slides. For example, the = minutes note that Paul Hoffman suggested the use of different ports or a = different protocol number, as a possibly preferable way to address the = algorithm agility concerns (vs. adding OCSP extensions). Russ emphasized = the need to address the dependence on SHA-1 sooner rather than later. Steve ------_=_NextPart_001_01C9ACE4.24EE2989 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [saag] PKIX report=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
 
=0A=
I read the minutes, the summary is quite a bit different. =
=0A=
=0A= From: Stephen Kent = [mailto:kent@bbn.com]
Sent: Tue 3/24/2009 8:00 = PM
To: Hallam-Baker, Phillip
Cc: = saag@ietf.org
Subject: RE: [saag] PKIX = report

=0A=
=0A=
At 4:48 PM -0700 3/24/09, Hallam-Baker, Phillip wrote:
=0A=
I = dispute the assertion that a new protocol or port # might be required = for OCSP. The protocol is adequately extendable.
=0A=
 
=0A=
What I put in the = slides was what I felt that the group had already agreed to. Since this = was the first occasion where the issues had been raised, I was not = proposing a solution. If it is agreed that there is a problem, there is = a simple solution.
=0A=

=0A=
Phil,
=0A=

=0A=
The PKIX report is a summary of the meeting minutes. I suggest you = dead the PKIX minutes for a more complete description of the discussion = that accompanied Stefan's presentation of your slides. For example, the = minutes note that Paul Hoffman suggested the use of different ports or a = different protocol number, as a possibly preferable way to address the = algorithm agility concerns (vs. adding OCSP extensions). Russ emphasized = the need to address the dependence on SHA-1 sooner rather than = later.
=0A=

=0A=
Steve
------_=_NextPart_001_01C9ACE4.24EE2989-- From kent@bbn.com Tue Mar 24 17:59:23 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306703A6B01 for ; Tue, 24 Mar 2009 17:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 VBVmHRkPqSVF for ; Tue, 24 Mar 2009 17:59:22 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7BA2A3A68A7 for ; Tue, 24 Mar 2009 17:59:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.68.195]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmHTZ-0005a9-ED; Tue, 24 Mar 2009 21:00:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2788466ED3E31C418E9ACC5C3166155768B34D@mou1wnexmb09.vcorp.ad.vrsn.com> References: <2788466ED3E31C418E9ACC5C3166155768B34A@mou1wnexmb09.vcorp.ad.vrsn.com> <2788466ED3E31C418E9ACC5C3166155768B34D@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Tue, 24 Mar 2009 21:00:02 -0400 To: "Hallam-Baker, Phillip" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] PKIX report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:59:23 -0000 At 5:52 PM -0700 3/24/09, Hallam-Baker, Phillip wrote: > >I read the minutes, the summary is quite a bit different. The summary conveyed the essential points, i.e., the principle points that the slides conveyed and the primary audience responses to the slides. Steve From Shawn.Emery@Sun.COM Wed Mar 25 13:23:33 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11FC3A6BC4 for ; Wed, 25 Mar 2009 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[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 t-AjAqLpq53o for ; Wed, 25 Mar 2009 13:23:33 -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 2C18A3A688A for ; Wed, 25 Mar 2009 13:23:33 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PKOPUL019672 for ; Wed, 25 Mar 2009 20:24:25 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200300V02QC00@mail-amer.sun.com> for saag@ietf.org; Wed, 25 Mar 2009 14:24:25 -0600 (MDT) Received: from dhcp-16b2.meeting.ietf.org ([unknown] [129.150.36.219]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200D4BWOIVR00@mail-amer.sun.com> for saag@ietf.org; Wed, 25 Mar 2009 14:24:18 -0600 (MDT) Date: Wed, 25 Mar 2009 14:23:36 -0600 From: "Shawn M. Emery" Sender: Shawn.Emery@Sun.COM To: saag@ietf.org Message-id: <49CA92C8.9020405@sun.com> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Subject: [saag] IETF 74 Kitten Working Group Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:23:34 -0000 The kitten-wg met Tuesday, 3/24/09, during afternoon session three. Co-chairs: Alexey Melnikov and Shawn Emery The goals of the meeting were to review the state of the active working group items, one individual submission, Charter, and Milestones. gssapi-extensions-iana ---------------------------- Needs cleanup of idnits before PROTO-writeup. Initial registry will be populated during IANA review (during RFC publishing). gssapi-channel-bindings ------------------------------ ASN.1 nit corrected and GenART-comment to clarify document and dicusss history addressed in 06. Ballot issued. extended-mech-inquiry ----------------------------- WGLC expired in first week of December. Comment by Love; memory management concern with respect to buffer and oid sets. Nico will add text in respect to releasing buffers. Will be sent for AD (Tim Polk) review shortly. gssapi-store-cred --------------------- WGLC ended in the last week in December. idnits cleaned up in 03 and 04. PROTO-writeup complete. I-D publication requested. rfc2853bis ------------- idnits cleaned up in 04 and 05. PROTO-writeup complete. I-D publication requested. gssapi-naming-exts ------------------------ Editor posted questions to the mailing list: Should we keep the mapped or critical flag? No. Should we replace the negative with a complete flag? Yes. Should we have char * instead of OIDs for attribute naming? There was not a strong consensus in the room, will take this to the list again. draft-lha-gssapi-delegate-policy --------------------------------------- LC comments cleaned up in 03 and 04. IANA registry will occur for this draft during the IANA review of IANA registry. PROTO-writeup complete. Current I-D state is AD evaluation. Charter/Milestones ------------------------ Charter: Need volunteers/momentum behind: Updates to v2 RFCs: Guidance for mechanism and application protocol designers. Thread safety. C-binding clarifications (types, name space, etc.). Still need to remove C# binding work item. New milestone: WGLC gssapi-naming-exts 05/09 (Orig 11/07) Shawn and Alexey. -- From stephen.farrell@cs.tcd.ie Wed Mar 25 18:29:04 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E52B3A680A for ; Wed, 25 Mar 2009 18:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=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 OQi2YOpPvwy9 for ; Wed, 25 Mar 2009 18:29:03 -0700 (PDT) Received: from services-1.meeting.ietf.org (unknown [130.129.5.6]) by core3.amsl.com (Postfix) with ESMTP id 287BA3A659C for ; Wed, 25 Mar 2009 18:29:03 -0700 (PDT) Received: from [130.129.19.198] (dhcp-13c6.meeting.ietf.org [130.129.19.198]) by services-1.meeting.ietf.org (Postfix) with ESMTP id 02BD7A6D8A; Wed, 25 Mar 2009 18:29:54 -0700 (PDT) Message-ID: <49CADAC9.3020106@cs.tcd.ie> Date: Thu, 26 Mar 2009 01:30:49 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: ietf-dkim , saag@ietf.org References: <9abf48a60903251334s38c070fanfbefbde86deaa652@mail.gmail.com> In-Reply-To: <9abf48a60903251334s38c070fanfbefbde86deaa652@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] DKIM SAAG writeup... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:29:04 -0000 DKIM met on Wednesday at 9am. About 40 people attended. Discussion centred on the content of, and how to process, an I-D describing mostly terminology changes to RFC 4871. The consensus in the room was to quickly finish up that I-D (we had three areas where some tweaking might be needed), and then to submit it to the AD for normal IETF LC etc. The AD has said that he'll try expedite that processing as there are some in the DKIM community who consider that the clarifications proposed are urgently needed. For ADSP, the discussion on the above clarifications has thrown up a possible related change. The chairs will start a 1-week discussion on this (and only on this) on the list, after which there may or may not be a need to modify the draft. Since the possible substantive change is expected to only affect one paragraph we do not intend to carry out another WGLC after that discussion. We also discussed other I-Ds, the overview is with the AD, work on the deployment guide in ongoing. We finally discussed a 4871bis effort. There is some interest in the WG in progressing 4871, or at least in rolling up the set of existing errata. The chairs will start a discussion on the scope of such an effort. Stephen & Barry. From turners@ieca.com Wed Mar 25 19:25:27 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5F53A6A8B for ; Wed, 25 Mar 2009 19:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 5mjwfkOZOr0P for ; Wed, 25 Mar 2009 19:25:19 -0700 (PDT) Received: from smtp104.biz.mail.mud.yahoo.com (smtp104.biz.mail.mud.yahoo.com [68.142.200.252]) by core3.amsl.com (Postfix) with SMTP id 792D33A6A8C for ; Wed, 25 Mar 2009 19:25:18 -0700 (PDT) Received: (qmail 19562 invoked from network); 26 Mar 2009 02:26:11 -0000 Received: from unknown (HELO dhcp-179d.meeting.ietf.org) (turners@130.129.23.157 with plain) by smtp104.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 02:26:11 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: Y5zq0I4VM1kNZCP7vvbWiAsmiAAzKeTUuQMSUQgf1O5QZ5rWpqvxpOpqmlfN.Oq.AMv6fLbJCcbWszOy49IJR0ak92MMtb._g7zOAMXvYocBXuWQzpkpxpJcknnCFDEtwVJm4a4BrYBXKzo.sqLNM_tTUjctKi1oWLHAoe7DHPI12y7gqlG_mTnSuVK4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CAE7C2.5080008@ieca.com> Date: Wed, 25 Mar 2009 19:26:10 -0700 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] SMIME report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:25:27 -0000 The SMIME WG did not meet (again) but we haven't closed (yet) so here's a summary of what happened since last time: - draft-ietf-smime-sha2: entered the RFC editor's queue - draft-ietf-smime-3850bis: addressing IESG DISCUSSES (all resolved, in the eyes of the author, awaiting submission of new ID with get-out-of-jail boiler plate text*) - draft-ietf-smime-3851bis: addressing IESG DISCUSSES (all resolved awaiting author submission of new ID, awaiting submission of new ID with get-out-of-jail boiler plate text*) - draft-ietf-smime-3278bis: WGLC issued/passed, RFC 4858 write-up provided to AD, awaiting AD review and inclusion on IESG agenda - draft-ietf-smime-new-asn1: WGLC issued, new version posted addressing WGLC comments, awaiting RFC 4858 write-up (will be completed by the end of the week), and passed to Tim - draft-ietf-smime-cms-rsa-kem: STALLED!?! Text to address Steve Kent's SECDIR review provided to authors, and we're awaiting a response. I have been approached about three new IDs. The proposed plan is for each author to initially submit their ID as individual ID and then the WG will consider adoption. Cheers, spt * If I can reach Steve Dusse, Laurence Lundblade, Lisa Repka, Bill Flanigan, and Elliot Ginsberg then I won't have to include the text. If somebody has contact info for any of these people please let me know. From CWallace@cygnacom.com Wed Mar 25 08:20:52 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B790F3A69F0 for ; Wed, 25 Mar 2009 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 vj8J3O+4Dq-F for ; Wed, 25 Mar 2009 08:20:52 -0700 (PDT) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by core3.amsl.com (Postfix) with SMTP id F090A28C111 for ; Wed, 25 Mar 2009 08:20:51 -0700 (PDT) Received: (qmail 7212 invoked from network); 25 Mar 2009 15:20:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Mar 2009 15:20:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Mar 2009 11:21:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS report Thread-Index: AcmtXWc7BKF7jvG0Q9+yZDZEhalS1A== From: "Carl Wallace" To: X-Mailman-Approved-At: Thu, 26 Mar 2009 08:42:15 -0700 Subject: [saag] LTANS report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:20:52 -0000 The LTANS working group did not meet this week. There are three active working group drafts: - draft-ietf-ltans-dssc-06 completed working group last call. A few minor changes resulted in draft-ietf-ltans-dssc-07 following last call. The draft has been submitted to the IESG. - draft-ietf-ltans-xmlers-03 will start working group last call soon. - draft-ietf-ltans-ltap-07 is in progress and will be completed following xmlers. Once these items are done, the working group will close. From turners@ieca.com Thu Mar 26 09:13:15 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9143A6BE5 for ; Thu, 26 Mar 2009 09:13: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 YTypxb4GLWRf for ; Thu, 26 Mar 2009 09:13:15 -0700 (PDT) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by core3.amsl.com (Postfix) with SMTP id 9628D3A6DFF for ; Thu, 26 Mar 2009 09:13:05 -0700 (PDT) Received: (qmail 25682 invoked from network); 26 Mar 2009 16:13:59 -0000 Received: from unknown (HELO sean-turners-macbook.local) (turners@66.114.246.39 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 26 Mar 2009 16:13:58 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: xlCOm3AVM1kW7xFPeG0vq815rpFcXG59thyIK1.1WEHcxQJxbaEK_3CXSoqa1Ij6VQ.UAYP_5lJ8KJL8x5hLJCCAxVoEmX5DtIoCQJC8Jm0OwuLzeU.0wJtrVFZs_Rzg.3ktq4gWQ0OVeCcSA2fuXp3p2eAOdgKx4rSSs2JQz.6u1Fv2kESRBL43UWe7DPczAHH6a6Ypj4XOhBZUcx5zmTCf_gw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49CBA9C5.6050902@ieca.com> Date: Thu, 26 Mar 2009 09:13:57 -0700 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: saag@ietf.org References: <49CAE7C2.5080008@ieca.com> In-Reply-To: <49CAE7C2.5080008@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] SMIME report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:13:15 -0000 I should add the following people to the list of people I need to contact: Jeff Thompson Jeff Weinstein Anil Gangolli Piers Chivers spt Sean Turner wrote: > The SMIME WG did not meet (again) but we haven't closed (yet) so here's > a summary of what happened since last time: > > - draft-ietf-smime-sha2: entered the RFC editor's queue > - draft-ietf-smime-3850bis: addressing IESG DISCUSSES (all resolved, > in the eyes of the author, awaiting submission of new ID with > get-out-of-jail boiler plate text*) > - draft-ietf-smime-3851bis: addressing IESG DISCUSSES (all resolved > awaiting author submission of new ID, awaiting submission of new ID > with get-out-of-jail boiler plate text*) > - draft-ietf-smime-3278bis: WGLC issued/passed, RFC 4858 write-up > provided to AD, awaiting AD review and inclusion on IESG agenda > - draft-ietf-smime-new-asn1: WGLC issued, new version posted addressing > WGLC comments, awaiting RFC 4858 write-up (will be completed by the > end of the week), and passed to Tim > - draft-ietf-smime-cms-rsa-kem: STALLED!?! Text to address Steve Kent's > SECDIR review provided to authors, and we're awaiting a response. > > I have been approached about three new IDs. The proposed plan is for > each author to initially submit their ID as individual ID and then the > WG will consider adoption. > > Cheers, > > spt > > * If I can reach Steve Dusse, Laurence Lundblade, Lisa Repka, Bill > Flanigan, and Elliot Ginsberg then I won't have to include the text. If > somebody has contact info for any of these people please let me know. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From tlyu@MIT.EDU Thu Mar 26 09:33:47 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C3A73A67E3 for ; Thu, 26 Mar 2009 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 ysUZrXsp3q8z for ; Thu, 26 Mar 2009 09:33:46 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 69DAD3A67DD for ; Thu, 26 Mar 2009 09:33:46 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2QGYaPY016891 for ; Thu, 26 Mar 2009 12:34:37 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n2QGYZKF014602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Mar 2009 12:34:36 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n2QGYZh6008461; Thu, 26 Mar 2009 12:34:35 -0400 (EDT) To: saag@ietf.org From: Tom Yu Date: Thu, 26 Mar 2009 12:34:35 -0400 Message-ID: Lines: 48 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IETF74 SASL summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:33:47 -0000 Simple Authentication And Security Layer (SASL) IETF74, San Francisco, CA Tuesday, March 24, 2009 at 0900-1130 ==================================== Chairs: Tom Yu Kurt Zeilenga Scribe: Cyrus Daboo ==================== * draft-melnikov-sasl-scram-ldap-01 * draft-newman-auth-scram-11 - near consensus * draft-newman-auth-scram-gs2-01 - fold into SCRAM * draft-ietf-sasl-4422bis-00 - needs refresh * draft-ietf-sasl-crammd5-10 - expired; consensus call in-progress * draft-ietf-sasl-digest-to-historic-00 - needs refresh; to IESG with SCRAM * draft-ietf-sasl-gs2-11 - near consensus * draft-zeilenga-sasl-crammd5-00 - SCRAM - PBKDF2 iteration count: Pasi suggests using largest count that allows an acceptable user experience. SCRAM - open question on including "service name" URI to avoid a "bad" server proxying to a "good" server and thus gaining access to the "good" server as the user. No clear consensus. New GS2 approach, very text-oriented. Considered acceptable for SCRAM. Distinguish channel-binding vs not by using a suffix on mechanism name. GS2, SCRAM edits done by end of month. CRAM-MD5 - ongoing consensus call. So far, general agreement about abandoning work, etc. as in Tom's statements in the consensus call, except for the adoption of SCRAM as the replacement for CRAM-MD5. Milestones: Mar 09 GS2 WGLC Mar 09 SCRAM WGLC Apr 09 decide CRAM-MD5 approach Jun 09 4422bis I-D and implementation report Oct 09 4422bis WGLC From lha@kth.se Thu Mar 26 09:54:23 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1EA3A6A7F for ; Thu, 26 Mar 2009 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 sUjzouVHY0yR for ; Thu, 26 Mar 2009 09:54:23 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id EA1243A67DD for ; Thu, 26 Mar 2009 09:54:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 81C4E14DC8B for ; Thu, 26 Mar 2009 17:54:45 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eTSbFmIFolRq for ; Thu, 26 Mar 2009 17:54:25 +0100 (CET) Received: from [IPv6:2001:df8::16:21e:c2ff:fec5:249f] (unknown [IPv6:2001:df8:0:16:21e:c2ff:fec5:249f]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 09FB814DC83 for ; Thu, 26 Mar 2009 17:52:52 +0100 (CET) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Message-Id: <45551366-14DD-44FA-8A99-17BE35B58980@kth.se> Date: Thu, 26 Mar 2009 09:52:52 -0700 Mime-Version: 1.0 (Apple Message framework v1051) To: saag@ietf.org X-Mailer: Apple Mail (2.1051) Subject: [saag] btns - status update X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:54:23 -0000 Hello, The BTNS WG did not meet this IETF. Here's however some status update I think is worth to mention: Since last IETF draft-ietf-btns-connection-latching have a couple of DISCUSSes that are addressed, back in AD Follow up. draft-ietf-btns-c-api, draft-ietf-btns-abstract-api, There are been some progress (new draft) on the API document based on feedback on the list. Love From jsalowey@cisco.com Thu Mar 26 10:44:01 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025C23A684B for ; Thu, 26 Mar 2009 10:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 1vuvmWyPWC0B for ; Thu, 26 Mar 2009 10:44:00 -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 31F913A67E7 for ; Thu, 26 Mar 2009 10:44:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,426,1233532800"; d="scan'208";a="147171772" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2009 17:44:53 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2QHir91003964 for ; Thu, 26 Mar 2009 10:44:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2QHirgk024434 for ; Thu, 26 Mar 2009 17:44:53 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.1830); Thu, 26 Mar 2009 10:44:53 -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, 26 Mar 2009 10:44:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Working Group Summary Thread-Index: AcmuOpE+vfs3BnuGQB68w9cAMtEH/A== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 26 Mar 2009 17:44:53.0871 (UTC) FILETIME=[92113FF0:01C9AE3A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=405; t=1238089494; x=1238953494; 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:=20EMU=20Working=20Group=20Summary |Sender:=20; bh=xZk/ciOW3Israi1RKh8GZPbDDHcT1jB01C6TwlkvmX0=; b=BkCyl3SxsCY9FKTmWh5WuWGzH5yEBqOqq7QeoGoqsG2VWVFfqRMhk04KL/ AK4wRBeJyZWpXl5ZgZ9j79vMMJwp+GTvUsdSYSMTMwbUZTOC2iG2QhoxpGWM RYIhr7D6tz; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [saag] EMU Working Group Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:44:01 -0000 EMU met Wednesday afternoon. EAP-GPSK has been published as RFC 5433. Tunnel method requirements draft is just about done, pending some additional review promised during the meeting. EAP channel bindings draft will go to working group last call sometime in the next few weeks. We had a presentation on an EKE EAP method, which generated some interest in the working group. We finished early. =20 From bew@cisco.com Thu Mar 26 10:54:10 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41B23A6E18 for ; Thu, 26 Mar 2009 10:54:10 -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 62vsz2C58Zvs for ; Thu, 26 Mar 2009 10:54:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1B9193A6E00 for ; Thu, 26 Mar 2009 10:54:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,427,1233532800"; d="scan'208";a="147114211" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 26 Mar 2009 17:55:03 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2QHt3fl023159 for ; Thu, 26 Mar 2009 10:55:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2QHt34J005896 for ; Thu, 26 Mar 2009 17:55:03 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 10:55:03 -0700 Received: from dhcp-168a.meeting.ietf.org ([10.21.89.78]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 10:55:03 -0700 Message-Id: <393D2494-AD9E-4A8F-A3FA-20D43B51CD95@cisco.com> From: Brian Weis To: saag@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 10:55:02 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Mar 2009 17:55:03.0701 (UTC) FILETIME=[FD8DEC50:01C9AE3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1653; t=1238090103; x=1238954103; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20MSEC=20report |Sender:=20; bh=0mV7Q84TsBhjldEWoEpdrAwMOZfLH3Tyu5PLflmaWGg=; b=A8qsIZ5oE7QcB9cQpr+NUrDDkJOxA3whXbhKNfTRdZ+Xk5dJTWT8br3kgQ uSoyE/5rUvBdkR7adYPZcqMF/V/T9bODhOW29BvBtErip+V5JPvGzwuRyydp 2uiY48BXSV; Authentication-Results: sj-dkim-4; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [saag] MSEC report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:54:10 -0000 The MSEC WG met for about an 1.5 hours on Wednesday morning. It was noted that we are coming to the end of our active work items, and that it was time to consider whether to take on new work or shut down. Sheela Rowles presented changes made to the GDOI Update draft (updates to RFC 3547). This I-D describes clarifications to the GDOI protocol based on implementation experience, and also adds a few new attributes to harmonize with other recent WG work items. It is ready for WG last call. We had two proposals for new work items. Sheela stated the need for a GDOI MIB. Tim Polk cautioned against taking on MIB work unless there is a substantial number of participation from the WG. We'll take that to the mailing list. Seokung Yoon presented a draft that adds support for the SEED cipher to MIKEY. After discussion, it was determined that the WG did not object to its publication, but it was complete enough that there was no need for the WG to adopt it. Tim agreed to sponsor it as an individual contribution. We concluded with a discussion of Gregory Lebovitz' KMART Roadmap I-D. It was pointed out that a number of the routing protocols mentioned in the I-D make use of group security in some or all use cases. A number of presentations introducing methods of providing automated key management for these routing protocols have been made in past MSEC WG meetings. A suggestion was made that since the WG was coming to the end of its current work items, it should consider re-chartering to allow us to address automated key management which could be used by those protocols. From lzhu@windows.microsoft.com Thu Mar 26 12:58:14 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209F13A69F7 for ; Thu, 26 Mar 2009 12:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.959 X-Spam-Level: X-Spam-Status: No, score=-106.959 tagged_above=-999 required=5 tests=[AWL=3.640, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 FFIGq6OovY3b for ; Thu, 26 Mar 2009 12:58:13 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 643B93A6955 for ; Thu, 26 Mar 2009 12:57:54 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 26 Mar 2009 12:58:48 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Thu, 26 Mar 2009 12:58:47 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Thu, 26 Mar 2009 12:58:46 -0700 From: Larry Zhu To: "saag@ietf.org" , "ietf-krb-wg@anl.gov" Date: Thu, 26 Mar 2009 12:58:46 -0700 Thread-Topic: krb-wg report Thread-Index: AcmuTUXIWv7mlqGaTfCfal0noKcm4A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AB1E5627D2489D45BD01B84BD5B9004614F5954BA3NAEXMSGW601wi_" MIME-Version: 1.0 Subject: [saag] krb-wg report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:58:14 -0000 --_000_AB1E5627D2489D45BD01B84BD5B9004614F5954BA3NAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Krb-wg met Tuesday afternoon. Chair: Jeffrey Hutzelman and Larry Zhu Scribe: Shawn Emery AD: Tim Polk We reviewed the changes in our current Internet Drafts. We discussed issue= s raised in list discussions and consensus calls. There are two outstanding= issues for draft-josefsson-kerberos5-starttls, namely KDC-certificate vali= dation and channel bindings. It is noted that current starttls implementat= ions can only handle pre-shared certificates. We decided that starttls shou= ld require certificate validation using pre-shared certificates. There is n= o consensus how the certificates can be verified otherwise with alternative= options involving various EKUs and SANs proposed. The lack of channel bin= dings will be handled in a separate document. Due to these limitations, the= starttls document should be published as is as informational, except to up= date it to reflect the certificate validation decision. The channel binding= document krb5starttls-bootstrap is adopted as a working group item. These = decisions are to be verified on the list. We then discussed an issue involving the RFC3961 PRF for AES. We found that= all current implementations truncate the output to multiple of AES cipher = block size 16 bytes while the specification in RFC3961 does not truncate. W= e decided to adopt the PRF with truncation as the official PRF but we are t= o find out what is the right process to do this and we will involve the doc= ument author Ken and security AD Tim Polk. The decision is to be verified o= n the list. After the PRF discussion, we turned our attention to two issues in the prea= uth document. Sam made the presentation. One is how to detect thus prevent = the FAST padata from being stripped by active attackers. An AD element will= be used to indicate FAST padata is used to mitigate the threat. Another is= sue is that TLS-finished style checksum adds some complexity to implementer= s but no significant benefits. We will remove the finished checksum in the = next revision. We also have the following additional action items and decisions: 1) Updates to the data model document have been made based on WGLC comments= . We will start another WGLC. Follow up: jhutz and Leif. 2) Anonymity document has one new open issue regard to exported names. Larr= y Zhu is going to propose a solution and go through the list. We have good = and healthy discussions. Followup: Larry 3) Love proposed an alternative proposal to use the server nonce to allow b= oth the client and the KDC contribute the ticket Session key. Larry Zhu and= /love will write up the idea and propose it to the list. Followup: Larry an= d Love. 4) IAKERB WGLC is concluded. One comment is to be addressed by adding appro= priate text to the security considerations section. Followup: Larry to upda= te, and Jhutz to forward it to IESG 5) Ticket extensions adopted as work group item. Followup: jhutz 6) DHCP options to be added to allow KDC discovery, adopted as working grou= p item, and to update the krb-wg charter. Followup: jhutz 7) The preauth ID to be updated and start WGLC. Followup: Sam Hartman to pu= blish -11 based on the group decisions, 3 designated volunteer reviewers to= complete review in the next weeks timeframe: Cliff Newman, Love, and Nicol= as Williams --_000_AB1E5627D2489D45BD01B84BD5B9004614F5954BA3NAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Krb-wg met Tuesday afternoon.

 

Chair: Jeffrey Hutzelman and Larry Zhu

Scribe: Shawn Emery

AD: Tim Polk

 

We reviewed the changes in our current Internet Dra= fts.  We discussed issues raised in list discussions and consensus calls. There a= re two outstanding issues for draft-josefsson-kerberos5-starttls, namely KDC-certificate validation and channel bindings.  It is noted that cur= rent starttls implementations can only handle pre-shared certificates. We decide= d that starttls should require certificate validation using pre-shared certificates. There is no consensus how the certificates can be verified otherwise with alternative options involving various EKUs and SANs proposed= .  The lack of channel bindings will be handled in a separate document. Due to these limitations, the starttls document should be published as is as informational, except to update it to reflect the certificate validation decision. The channel binding document krb5starttls-bootstrap is adopted as= a working group item. These decisions are to be verified on the list.

 

We then discussed an issue involving the RFC3961 PR= F for AES. We found that all current implementations truncate the output to multi= ple of AES cipher block size 16 bytes while the specification in RFC3961 does n= ot truncate. We decided to adopt the PRF with truncation as the official PRF b= ut we are to find out what is the right process to do this and we will involve= the document author Ken and security AD Tim Polk. The decision is to be verifie= d on the list.

 

 

After the PRF discussion, we turned our attention t= o two issues in the preauth document. Sam made the presentation. One is how to de= tect thus prevent the FAST padata from being stripped by active attackers. An AD element will be used to indicate FAST padata is used to mitigate the threat= . Another issue is that TLS-finished style checksum adds some complexity to implementers but no significant benefits. We will remove the finished check= sum in the next revision.

 

We also have the following additional action items = and decisions:

 

1) Updates to the data model document have been mad= e based on WGLC comments. We will start another WGLC. Follow up: jhutz and Le= if.

 

2) Anonymity document has one new open issue regard= to exported names. Larry Zhu is going to propose a solution and go through the list. We have good and healthy discussions. Followup: Larry

 

3) Love proposed an alternative proposal to use the server nonce to allow both the client and the KDC contribute the ticket Ses= sion key. Larry Zhu and/love will write up the idea and propose it to the list. Followup: Larry and Love.

 

4) IAKERB WGLC is concluded. One comment is to be addressed by adding appropriate text to the security considerations section= . Followup: Larry to update, and Jhutz to forward it to IESG

 

5) Ticket extensions adopted as work group item. Followup: jhutz

 

6) DHCP options to be added to allow KDC discovery, adopted as working group item, and to update the krb-wg charter. Followup: jhutz

 

7) The preauth ID to be updated and start WGLC. Fol= lowup: Sam Hartman to publish -11 based on the group decisions, 3 designated volun= teer reviewers to complete review in the next weeks timeframe: Cliff Newman, Lov= e, and Nicolas Williams

 

 

--_000_AB1E5627D2489D45BD01B84BD5B9004614F5954BA3NAEXMSGW601wi_-- From ietfdbh@comcast.net Thu Mar 26 13:04:24 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A133A6A15 for ; Thu, 26 Mar 2009 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.96 X-Spam-Level: * X-Spam-Status: No, score=1.96 tagged_above=-999 required=5 tests=[AWL=-4.559, BAYES_50=0.001, MANGLED_WATING=2.3, MIME_ASCII0=1.5, MIME_BAD_LINEBREAK=0.5, TVD_SPACE_RATIO=2.219] 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 6XTd6G9ugnyX for ; Thu, 26 Mar 2009 13:04:24 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id AA4F83A698F for ; Thu, 26 Mar 2009 13:04:23 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id XsX21b00F0b6N64ACw5JBx; Thu, 26 Mar 2009 20:05:18 +0000 Received: from Harrington73653 ([130.129.18.98]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Xw591b00S26xVzW8Pw5CsS; Thu, 26 Mar 2009 20:05:16 +0000 From: "David Harrington" To: Date: Thu, 26 Mar 2009 13:05:10 -0700 Message-ID: <015101c9ae4e$2e6dce00$f4438182@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0152_01C9AE13.820EF600" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmuTipGTIF+45S2SAGT1j+4i3tppw== Subject: [saag] syslog status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:04:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0152_01C9AE13.820EF600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0152_01C9AE13.820EF600 Content-Type: text/plain; name="syslogReport.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="syslogReport.txt" //5TAHkAcwBsAG8AZwAgAFcARwAgAFIAZQBwAG8AcgB0AA0ACgBjAGgAYQBpAHIAcwA6ACAAQwBo AHIAaQBzACAATABvAG4AdgBpAGMAawAsACAARABhAHYAZQAgAEgAYQByAHIAaQBuAGcAdABvAG4A DQAKAA0ACgBzAHkAcwBsAG8AZwAtAHAAcgBvAHQAbwBjAG8AbAAgAHAAdQBiAGwAaQBzAGgAZQBk ACAAYQBzACAAUgBGAEMADQAKAHMAeQBzAGwAbwBnAC0AdABsAHMAIABwAHUAYgBsAGkAcwBoAGUA ZAAgAGEAcwAgAFIARgBDAA0ACgBzAHkAcwBsAG8AZwAtAHUAZABwACAAcAB1AGIAbABpAHMAaABl AGQAIABhAHMAIABSAEYAQwANAAoAcwB5AHMAbABvAGcALQB0AGMALQBtAGkAYgAgAFIARgBDACAA RQBkACAAUQB1AGUAdQBlACwAIABhAHcAYQBpAHQAaQBuAGcAIAB1AHAAZABhAHQAZQAgAG8AZgAg AE0ASQBCACAAYwBvAHAAeQByAGkAZwBoAHQAIABiAG8AaQBsAGUAcgBwAGwAYQB0AGUALgANAAoA cwB5AHMAbABvAGcALQBzAGkAZwBuACAAQQBEACAARQB2AGEAbAB1AGEAdABpAG8AbgAvAFIAZQB2 AGkAcwBlAGQAIABJAEQAIABOAGUAZQBkAGUAZAANAAoADQAKAGQAaQBzAGMAdQBzAHMAaQBvAG4A IABvAG4AZwBvAGkAbgBnACAAYQBiAG8AdQB0ACAAdwBoAGUAdABoAGUAcgAgAHQAbwAgAHIAZQBj AGgAYQByAHQAZQByACAAaQBuACAAUwBlAGMAdQByAGkAdAB5ACAAQQByAGUAYQAsACAAbwByACAA DQAKAHIAZQBjAGgAYQByAHQAZQByACAAaQBuACAATwBQAFMAIABhAHIAZQBhACwAIABvAHIAIABj AGwAbwBzAGUALgAgAE0AbwBzAHQAIABwAHIAbwBwAG8AcwBlAGQAIAB0AG8AcABpAGMAcwAgAGEA cgBlACAAbgBvAHQAIABzAGUAYwB1AHIAaQB0AHkALQBzAHAAZQBjAGkAZgBpAGMALgAgAA0ACgBN AG8AcwB0ACAAcAByAG8AcABvAHMAYQBsAHMAIABhAHIAZQAgAGQAYQB0AGEAIABtAG8AZABlAGwA aQBuAGcAIABTAEQARQBzACwAIABvAHIAIAB0AHIAYQBuAHMAbABhAHQAaQBvAG4AIABiAGUAdAB3 AGUAZQBuACAAcwB5AHMAbABvAGcAIABhAG4AZAAgAA0ACgBvAHQAaABlAHIAIABOAE0AIABwAHIA bwB0AG8AYwBvAGwAcwAgACgAZQAuAGcALgAsACAAUwBOAE0AUAApAA0ACgA= ------=_NextPart_000_0152_01C9AE13.820EF600-- From jsalowey@cisco.com Thu Mar 26 13:13:04 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CDC3A69F7 for ; Thu, 26 Mar 2009 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 AKEh-WYsQ-h2 for ; Thu, 26 Mar 2009 13:13:04 -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 F15EA3A695C for ; Thu, 26 Mar 2009 13:12:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="147255911" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 26 Mar 2009 20:13:48 +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 n2QKDm4U021915 for ; Thu, 26 Mar 2009 13:13: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.13.8) with ESMTP id n2QKDmK8013988 for ; Thu, 26 Mar 2009 20:13: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.1830); Thu, 26 Mar 2009 13:13: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, 26 Mar 2009 13:13:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS WG Report Thread-Index: AcmuTaEFlhJN4i5eRNKxKKosohhfFwAAa4Pw From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 26 Mar 2009 20:13:48.0040 (UTC) FILETIME=[5F3F4080:01C9AE4F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=855; t=1238098428; x=1238962428; 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:=20FW=3A=20TLS=20WG=20Report |Sender:=20; bh=9Z1Tb7naovP4TwT2FdvESUiIhYFn3Yt16L3zQzcWBkg=; b=O0leq4lV/p+pmnzhg12fhYOPr0z2JtBGtqmrDdFVWO6EueeOkxnOlsPOa4 b9uOyhPI5X8quLFYu1pi9fEJie8UAz/QKJNvIfvOAsX5XEsDAnf9AkuuJcWh g7tp+WgHsS; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [saag] FW: TLS WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:13:05 -0000 The TLS WG met at 9 AM on Thu March 26 We have three documents in various stages of being almost finished: TLS Exporters: finished WGLC. Only editorial comments. Needs a new draft and then can go to the IESG. TLS Extensions: needs a new straightforward revision and then WGLC. DTLS 1.2: ready for WGLC We had a presentation from Stefan Santesson about a protocol for caching server information on the client to reduce handshake size (this is a modification of the old Fast Track concept). The WG decided to take on this work. We also had a presentation from Michael Williams about DTLS MOBI-D, an application mobility solution for DTLS. There was some enthusiasm for this work, but we recognize that it is substantial work and impacts areas outside of TLS. The Chairs will work with the ADs to work out how best to proceed. -Ekr From lzhu@windows.microsoft.com Thu Mar 26 15:34:41 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F653A6887 for ; Thu, 26 Mar 2009 15:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.152 X-Spam-Level: X-Spam-Status: No, score=-107.152 tagged_above=-999 required=5 tests=[AWL=3.447, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XHvGsVQ-uhFq for ; Thu, 26 Mar 2009 15:34:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 020493A6452 for ; Thu, 26 Mar 2009 15:34:40 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 26 Mar 2009 15:35:33 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Thu, 26 Mar 2009 15:35:32 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Thu, 26 Mar 2009 15:35:32 -0700 From: Larry Zhu To: "saag@ietf.org" , "ietf-krb-wg@anl.gov" Date: Thu, 26 Mar 2009 15:35:14 -0700 Thread-Topic: krb-wg report Thread-Index: AcmuTUXIWv7mlqGaTfCfal0noKcm4AAFVjdA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] krb-wg report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:34:41 -0000 This is a correction to the first paragraph in the Krb-wg report. Jeff and I discussed this, and have come to the conclusion that the posted summary suggests that decisions on starttls were made in the working group meeting on issues which were not decided. This is due in part to incorporating discussions which occurred in the Jabber room but not in the meeting proper. It was also partly due to my interpretation of certain discussions as reaching a decision, during a portion of the meeting I was not running. I did send the summary to Jeff before posting and I somehow missed out the points where Jeff brought these up in his response. With that I would like to retract the paragraph on starttls status and clarify as follows: - we did not come to a conclusion on certificate valildation, which is a discussion still ongoing on the krb-wg mailing list, but which the chairs hope will be resolved soon. - we did not come to a conclusion on the question of whether to adopt the krb5starttls-bootstrap document or on the separation of features between core starttls and -bootstrap. However, we did collect some input which we hope will help us to make a useful proposal for moving forward. - The intended status of the starttls document was also not decided and it= was only discussed briefly in the jabber room. Thanks, --larry From: Larry Zhu Sent: Thursday, March 26, 2009 12:59 PM To: saag@ietf.org; ietf-krb-wg@anl.gov Subject: krb-wg report Krb-wg met Tuesday afternoon. Chair: Jeffrey Hutzelman and Larry Zhu Scribe: Shawn Emery AD: Tim Polk We reviewed the changes in our current Internet Drafts. We discussed issue= s raised in list discussions and consensus calls. There are two outstanding issues for draft-josefsson-kerberos5-starttls, namely KDC-certificate validation and channel bindings. It is noted that current starttls implementations can only handle pre-shared certificates. We decided that starttls should require certificate validation using pre-shared certificate= s. There is no consensus how the certificates can be verified otherwise with alternative options involving various EKUs and SANs proposed. The lack of channel bindings will be handled in a separate document. Due to these limitations, the starttls document should be published as is as information= al, except to update it to reflect the certificate validation decision. The cha= nnel binding document krb5starttls-bootstrap is adopted as a working group item. These decisions are to be verified on the list. We then discussed an issue involving the RFC3961 PRF for AES. We found that all current implementations truncate the output to multiple of AES cipher block size 16 bytes while the specification in RFC3961 does not truncate. W= e decided to adopt the PRF with truncation as the official PRF but we are to find out what is the right process to do this and we will involve the docum= ent author Ken and security AD Tim Polk. The decision is to be verified on the = list. After the PRF discussion, we turned our attention to two issues in the prea= uth document. Sam made the presentation. One is how to detect thus prevent the = FAST padata from being stripped by active attackers. An AD element will be used = to indicate FAST padata is used to mitigate the threat. Another issue is that TLS-finished style checksum adds some complexity to implementers but no significant benefits. We will remove the finished checksum in the next revi= sion. We also have the following additional action items and decisions: 1) Updates to the data model document have been made based on WGLC comments= . We will start another WGLC. Follow up: jhutz and Leif. 2) Anonymity document has one new open issue regard to exported names. Larr= y Zhu is going to propose a solution and go through the list. We have good and he= althy discussions. Followup: Larry 3) Love proposed an alternative proposal to use the server nonce to allow b= oth the client and the KDC contribute the ticket Session key. Larry Zhu and/love wi= ll write up the idea and propose it to the list. Followup: Larry and Love. 4) IAKERB WGLC is concluded. One comment is to be addressed by adding appro= priate text to the security considerations section. Followup: Larry to update, and= Jhutz to forward it to IESG 5) Ticket extensions adopted as work group item. Followup: jhutz 6) DHCP options to be added to allow KDC discovery, adopted as working grou= p item, and to update the krb-wg charter. Followup: jhutz 7) The preauth ID to be updated and start WGLC. Followup: Sam Hartman to pu= blish -11 based on the group decisions, 3 designated volunteer reviewers to= complete review in the next weeks timeframe: Cliff Newman, Love, and Nicol= as Williams From ekr@rtfm.com Thu Mar 26 12:56:22 2009 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E9A3A67E6 for ; Thu, 26 Mar 2009 12:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-1.244, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] 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 IkE9ncV0MULu for ; Thu, 26 Mar 2009 12:56:21 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 9FC1228C0DE for ; Thu, 26 Mar 2009 12:56:21 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so713931qwb.31 for ; Thu, 26 Mar 2009 12:57:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.73.6 with SMTP id o6mr446636vcj.49.1238097434851; Thu, 26 Mar 2009 12:57:14 -0700 (PDT) Date: Thu, 26 Mar 2009 12:57:14 -0700 Message-ID: From: Eric Rescorla To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Mar 2009 08:08:21 -0700 Subject: [saag] TLS WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:56:22 -0000 The TLS WG met at 9 AM on Thu March 26 We have three documents in various stages of being almost finished: TLS Exporters: finished WGLC. Only editorial comments. Needs a new draft and then can go to the IESG. TLS Extensions: needs a new straightforward revision and then WGLC. DTLS 1.2: ready for WGLC We had a presentation from Stefan Santesson about a protocol for caching server information on the client to reduce handshake size (this is a modification of the old Fast Track concept). The WG decided to take on this work. We also had a presentation from Michael Williams about DTLS MOBI-D, an application mobility solution for DTLS. There was some enthusiasm for this work, but we recognize that it is substantial work and impacts areas outside of TLS. The Chairs will work with the ADs to work out how best to proceed. -Ekr