headers
Thomas Roessler | 1 Mar 2009 16:47
Picon
Favicon

Fwd: FPWD Transition Announcement - XML Security Specifications

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 <at> w3.org>







Begin forwarded message:

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

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 <at> w3.org .  If possible please indicate the document in the subject line. 
  
(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://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/



(7) XML Security Algorithm Cross-Reference

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 <at> w3.org .

Thank you

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG




<div>FYI, W3C has published initial working drafts for a number of documents related to XML Signature and Encryption:<div><br></div>
<div>1. Incremental revisions of XML Signature and Encryption. &nbsp;These revisions focus on adding markup and algorithm support for EC DSA (at the same time addressing some known issues with RFC 4050). &nbsp;We would appreciate early comment from the IETF community.<div><br></div>
<div>2. Markup for derived keys. &nbsp;This document, too, is one that could use review from the IETF community.</div>
<div><br></div>
<div>3. A requirements and design document for a possible version 2 of XML Signature. &nbsp;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.</div>
<div><br></div>
<div>The full list of drafts released is in the message quoted below.</div>
<div><br></div>
<div>If you have any questions, please feel free to contact Frederick or me.<br><div><br></div>
<div>Thanks,</div>
<div>
<div apple-content-edited="true"> <span class="Apple-style-span"><div><span class="Apple-style-span"><div><span class="Apple-style-span"><div>
<div>--</div>
<div>Thomas Roessler, W3C &nbsp;&lt;<a href="mailto:tlr <at> w3.org">tlr <at> w3.org</a>&gt;</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
</div></span></div></span></div></span><br class="Apple-interchange-newline">
</div>
<div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<div>From: Frederick Hirsch &lt;<a href="mailto:frederick.hirsch <at> nokia.com">frederick.hirsch <at> nokia.com</a>&gt;</div>
<div>Date: 26 February 2009 12:09:26 GMT-06:00</div>
<div>To: <a href="mailto:chairs <at> w3.org">chairs <at> w3.org</a>, XMLSec WG Public List &lt;<a href="mailto:public-xmlsec <at> w3.org">public-xmlsec <at> w3.org</a>&gt;</div>
<div>Cc: Frederick Hirsch &lt;<a href="mailto:Frederick.Hirsch <at> nokia.com">Frederick.Hirsch <at> nokia.com</a>&gt;</div>
<div>Subject: FPWD Transition Announcement -<span class="Apple-converted-space">&nbsp; </span>XML Security Specifications</div>
<div>Archived-At: &lt;<a href="http://www.w3.org/mid/52EDBA7C-232C-47FF-B906-184206F8E312 <at> nokia.com">http://www.w3.org/mid/52EDBA7C-232C-47FF-B906-184206F8E312 <at> nokia.com</a>&gt;</div>
<div><br></div> </div>
<div>
<div apple-content-edited="true"><div>
<div>This is a First Public Working Draft transition announcement from the XML Security WG.</div>
<div><br></div>
<div>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&nbsp;<a href="mailto:public-xmlsec-comments <at> w3.org">public-xmlsec-comments <at> w3.org</a> . &nbsp;If possible please indicate the document in the subject line.&nbsp;</div>
<div>
<div>&nbsp;&nbsp;</div>
<div>(1) XML Signature Syntax and Processing Version 1.1</div>
<div><a href="http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/">http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/</a></div>
</div>
<div>
<blockquote type="cite"></blockquote>
<br>(2) XML Encryption Syntax and Processing Version 1.1<br>&nbsp;<a href="http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/">http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/</a><br>
</div>
<div><br></div>
<div>(3)&nbsp;XML Signature Transform Simplification: Requirements and Design<br><a href="http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/">http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/</a>
</div>
<div><br></div>
<div>(4) XML Security Use Cases and Requirements<br><a href="http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/">http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/</a><br>
</div>
<div><br></div>
<div>(5) XML Security Derived Keys<br><a href="http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/">http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/</a>
</div>
<div><br></div>
<div>(6) XML Signature Properties<br><a href="http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/">http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/</a>
</div>
<div><br></div>
<div>(7) XML Security Algorithm Cross-Reference</div>
<div><a href="http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/">http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/</a></div>
<div><br></div>
<div>These were included in the following transition request:</div>
<div><a href="http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html">http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html</a></div>
</div></div>
<div><br></div>
<div>The Working Group has also published an updated working draft of Best Practices:</div>
<div><br></div>
<div>(8) XML Signature Best Practices W3C Working Draft 26 February 2009<br><a href="http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/">http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/</a><br><div><br class="webkit-block-placeholder"></div>
<div>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&nbsp;<a href="mailto:public-xmlsec-comments <at> w3.org">public-xmlsec-comments <at> w3.org</a> .</div>
<div><br></div>
<div>Thank you</div>
<div><br></div>
<div> <div>
<div>regards, Frederick</div>
<div><br></div>
<div>Frederick Hirsch, Nokia</div>
<div>Chair XML Security WG</div>
<br>
</div>
<br>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Nicolas Williams | 2 Mar 2009 17:00
Picon

Re: Channel binding is great but not a silver bullet

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
--

--
Permalink | Reply | 2 comments |
headers
Nicolas Williams | 2 Mar 2009 17:11
Picon

Re: SHA-1 to SHA-n transition

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
--

--
Permalink | Reply | 11 comments |
headers
Eric Rescorla | 2 Mar 2009 18:21

Re: SHA-1 to SHA-n transition

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.
Permalink | Reply | 10 comments |
headers
Jeffrey Hutzelman | 2 Mar 2009 18:08
Picon
Favicon

Re: Channel binding is great but not a silver bullet

--On Monday, March 02, 2009 10:00:36 AM -0600 Nicolas Williams 
<Nicolas.Williams <at> sun.com> 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
Permalink | Reply | 6 comments |
headers
Nicolas Williams | 2 Mar 2009 18:11
Picon

Re: SHA-1 to SHA-n transition

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
--

--
Permalink | Reply | 9 comments |
headers
Nicolas Williams | 2 Mar 2009 18:16
Picon

Re: SHA-1 to SHA-n transition

On Fri, Feb 27, 2009 at 07:56:12PM +1300, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams <at> sun.com> 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
--

--
Permalink | Reply | 2 comments |
headers
Nicolas Williams | 2 Mar 2009 18:26
Picon

Re: Channel binding is great but not a silver bullet

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 
> <Nicolas.Williams <at> sun.com> 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
--

--
Permalink | Reply | 4 comments |
headers
Eric Rescorla | 2 Mar 2009 19:11

Re: SHA-1 to SHA-n transition

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.
Permalink | Reply | 8 comments |
headers
Alan DeKok | 2 Mar 2009 18:57
Favicon
Gravatar

Re: Channel binding is great but not a silver bullet

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.
Permalink | Reply | 3 comments |

Gmane