Re: [saag] SHA-1 to SHA-n transition
"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 27 February 2009 13:40 UTC
Return-Path: <pbaker@verisign.com>
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 055D93A67A4 for <saag@core3.amsl.com>; Fri, 27 Feb 2009 05:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.101
X-Spam-Level:
X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.497, 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 ab5QpbdZFaGa for <saag@core3.amsl.com>; Fri, 27 Feb 2009 05:40:40 -0800 (PST)
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by core3.amsl.com (Postfix) with ESMTP id B20443A67D7 for <saag@ietf.org>; Fri, 27 Feb 2009 05:40:40 -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 n1RDf2NS027923; Fri, 27 Feb 2009 05:41:02 -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); Fri, 27 Feb 2009 05:41:03 -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_01C998E1.07127472"
Date: Fri, 27 Feb 2009 05:41:01 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155768B2DE@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] SHA-1 to SHA-n transition
Thread-Index: AcmYf0ZGufii+X0sR7maagS/QTBWEQAYQmXr
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>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Eric Rescorla <ekr@networkresonance.com>, Nicolas Williams <Nicolas.Williams@sun.com>
X-OriginalArrivalTime: 27 Feb 2009 13:41:03.0264 (UTC) FILETIME=[08648A00:01C998E1]
Cc: der Mouse <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 <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Feb 2009 13:40:42 -0000
EKR, I would like to dispute one small part of this. I think we do know something about UI. A UI works if the user has to do absolutely nothing to be secure. The more that a user is required to do, the less likely they are to do it correctly. Since we cannot expect the end user to know SHA1 or SHA2 from a potato we cannot present the typical user with any UI change whatsoever. End of story. We can put some options in for the expert user, but we probably don't want those to be too easy to get at. -----Original Message----- From: saag-bounces@ietf.org on behalf of Eric Rescorla Sent: Thu 2/26/2009 9:23 PM To: Nicolas Williams Cc: der Mouse; saag@ietf.org Subject: Re: [saag] SHA-1 to SHA-n transition At Thu, 26 Feb 2009 10:54:48 -0600, Nicolas Williams wrote: > > On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld wrote: > > IMHO we need a transition plan which allows websites to deploy with > > sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare > > mention it, we need to find some way to do this without making them pay > > a bunch of nuisance fees to CA operators). > > Indeed. And not having to pay "nuisance fees to CA operators" falls out > of not having a real PKI -- no real PKI, no real CAs to pay. > > 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). > > My proposal: > > 1) Add JavaScript interfaces to deal with DIGEST-MD5, successors, > GSS-API, ... > > These could be simple XmlHttpRequest object extensions, where > DIGEST-MD5 can already be used, and where HTTP/Nego and successors > could be used too. > > 2) Tie the above interfaces to the browser UI. > > Mark pages/windows/tabs with colors/text/sound/whatever appropriate > markers as: > > - plain (nothing is authenticated) > - weak server authentication (what we do today with HTTPS) > - mutually authenticated (DIGEST-MD5/something else was used through > the above mentioned interfaces, with credentials furnished through > the trusted path) > > Add markers for degree of security based on crypto algs used. > > Make it simple for users to see the authenticated identities. > > We'll also need a new flavor of cookies. We have "secure" and "not > secure" cookies now; we'll need "issued in mutually authenticated > context" -- call them "authenticated cookies." > > Prompting for DIGEST-MD5/whatever credentials needs to be done > securely. > > As with all UI design matters, it's important to find a way to > prevent attackers from emulating the UI with enough fidelity. (E.g., > don't allow full-screen apps.) > > 3) Teach users to look for the new markers. *This* is the hard part. > Education will always be the hard part. > > (Not that UI design isn't hard -- it is, and it is a requirement to > get the UI right if we're to educate users successfully.) 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. > 4) Federation/whatever fits into (2). We already have lots of > federation choices. The propblem is how federation fits in > generally. > > Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: it's > completely piecemeal, there's no CAs to shame into getting SHA-n support > because PKI gets cut out of the picture (even if server certs are still > used, they no longer matter for security). TLS would still be used, so > getting TLS implementations updated to 1.2 so that SHA-n would be a > requirement. As would be a successor to DIGEST-MD5. 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. -Ekr _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- [saag] SHA-1 to SHA-n transition Stephen Kent
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Hannes Tschofenig
- Re: [saag] SHA-1 to SHA-n transition Stephen Kent
- Re: [saag] SHA-1 to SHA-n transition Chandersekaran, Coimbatore S
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Yoav Nir
- Re: [saag] SHA-1 to SHA-n transition Pasi.Eronen
- Re: [saag] SHA-1 to SHA-n transition David McGrew
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Santosh Chokhani
- Re: [saag] SHA-1 to SHA-n transition der Mouse
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Paul Hoffman
- Re: [saag] SHA-1 to SHA-n transition David Harrington
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Michael O'Neill
- Re: [saag] SHA-1 to SHA-n transition Theodore Tso
- [saag] Deployment Deadlock Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Bill Sommerfeld
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- [saag] Channel binding is great but not a silver … Sam Hartman
- Re: [saag] Channel binding is great but not a sil… Nicolas Williams
- Re: [saag] Channel binding is great but not a sil… Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] Channel binding is great but not a sil… Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] Channel binding is great but not a sil… Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] Channel binding is great but not a sil… Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] Channel binding is great but not a sil… Alan DeKok
- Re: [saag] Channel binding is great but not a sil… Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] Channel binding is great but not a sil… Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] Channel binding is great but not a sil… Alan DeKok
- [saag] Or grow a real PKI (Re: SHA-1 to SHA-n tra… Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Stephen Kent
- Re: [saag] Channel binding is great but not a sil… Stephen Kent
- Re: [saag] Channel binding is great but not a sil… Stephen Kent
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Stephen Kent
- Re: [saag] Channel binding is great but not a sil… Nicolas Williams
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Nicolas Williams
- Re: [saag] Deployment Deadlock Pasi.Eronen
- Re: [saag] Deployment Deadlock Hallam-Baker, Phillip
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Nicolas Williams
- Re: [saag] SHA-1 to SHA-n transition Nicolas Williams
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Hallam-Baker, Phillip
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Stephen Kent
- Re: [saag] Or grow a real PKI (Re: SHA-1 to SHA-n… Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Eric Rescorla
- Re: [saag] SHA-1 to SHA-n transition Peter Gutmann
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Jeffrey Hutzelman
- Re: [saag] SHA-1 to SHA-n transition Theodore Tso
- Re: [saag] SHA-1 to SHA-n transition Hallam-Baker, Phillip
- Re: [saag] SHA-1 to SHA-n transition Bill Sommerfeld
- [saag] Credential portability RE: SHA-1 to SHA-n … Hallam-Baker, Phillip