RE: ISSUE-127: Safe Form Bar: Separate MITM handling? [Techniques]

I think the browser hook is the major missing infrastructure bit.

For example, assume the browser can be configured with a URL identifying the notification service. If the user clicks the "report problem" button, the browser posts all the relevant certificate chains to the notification service. In an enterprise, browsers would be configured to notify the IT department of misconfigured servers. For home users, the browser manufacturer may offer a default notification service that makes a best effort attempt to notify the sysadmin for the server, and otherwise just keeps the information in a publicly accessible database that sysadmins can check. I'm sure people will want to criticize this particular design and perhaps offer alternatives. The important point is to put the hook in the browser to enable these kinds of services. It is a good thing to quickly identify and resolve spurious MITM-like attacks. They provide noise in which the attacker can hide.

--Tyler

________________________________
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On Behalf Of Mary Ellen Zurko
Sent: Tuesday, January 08, 2008 9:23 AM
To: Close, Tyler J.
Cc: public-wsc-wg@w3.org
Subject: RE: ISSUE-127: Safe Form Bar: Separate MITM handling? [Techniques]


It's working through viable deployable patterns for the infrastructure behind it that has me doubtful (not the coding in the user agent, which, as you rightly point out, is quite modest).

Is there enough infrastructure bits lying about for this? Is there place to put a mailto: url that could be used, for example? Just what would it be associated with?

          Mez




From:   "Close, Tyler J." <tyler.close@hp.com>
To:     Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
Cc:     "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
Date:   01/07/2008 06:36 PM
Subject:        RE: ISSUE-127: Safe Form Bar: Separate MITM handling? [Techniques]

________________________________


There's a chicken and egg problem here. If the browser  provides the hook, then maybe the service will be developed. If the browser  doesn't provide the hook, then we're stuck with the pitiful options we have now.  It's not like it's such an incredible implementation burden, that we need to  ensure a browser can be "conditionally compliant" without it. It's one  configuration option and another button in a rarely seen dialog if the  option is set.

--Tyler
________________________________


From: Mary Ellen Zurko  [mailto:Mary_Ellen_Zurko@notesdev.ibm.com]
Sent: Monday, January  07, 2008 3:17 PM
To: Close, Tyler J.
Cc: public-wsc-wg@w3.org
Subject: RE: ISSUE-127: Safe Form Bar: Separate  MITM handling? [Techniques]


>From my point of view, because we  don't have an alert service that's useful. That's why I was OK with MAY. I get  that it would be a nice thing to have. But the infrastructure doesn't exist to  make it work often enough for a SHOULD.

          Mez




From:   "Close, Tyler J."  <tyler.close@hp.com>
To:     Mary Ellen Zurko  <Mary_Ellen_Zurko@notesdev.ibm.com>, "public-wsc-wg@w3.org"  <public-wsc-wg@w3.org>
Date:   01/07/2008 06:11 PM
Subject:        RE: ISSUE-127: Safe Form Bar: Separate  MITM handling? [Techniques]

________________________________




The text of ISSUE-160 includes the  statement:

"I'm still not buying the  notification stuff. MAY at best."

I  understand there are other points bundled up in ISSUE-160, but I'ld like to  get some more details on this particular point. Why exactly is offering  notification a problem?

I actually had a  whole series of relevant experiences with the internal intranet at work this  morning. Here's a story for ISSUE-160. I clicked a hyperlink to an intranet  web service I use once in a while. It's certificate chain is rooted at one of  the custom CAs used here. Normally, these custom CA certificates are  auto-magically distributed to our desktops by the same software that does  security updates. For some reason, this web service has changed certificate  chains and is now using a CA cert that I don't yet have. I don't want to click  through the cert warning to the service because that will reveal my  username/password, which are kept in a cookie. So I can't find out who to  complain to by looking at the hosted web pages. Wouldn't it be nice if the  software which updates my browser's CA list could also configure a URL to be  pinged when I encounter such a potential MITM attack. That way the dialog  shown by the browser could offer me a nice button to click: "get someone else  to deal with this problem". Instead, the button it offers me is "click here to  ignore this MITM attack and turn over your password to some random computer on  the intranet".

--Tyler

--
[1] "Web Security  Context: Experience, Indicators, and Trust"
<http://www.w3.org/2006/WSC/drafts/rec/#safebar-mitm>

________________________________

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]  On Behalf Of Mary Ellen Zurko
Sent: Friday, January 04, 2008 6:59 AM
To:  public-wsc-wg@w3.org
Subject: Re: ISSUE-127: Safe Form Bar: Separate MITM  handling? [Techniques]



ISSUE-160  makes the same basic proposal, perhaps for the same basic reasons, but I'm  leaving both open and cross referenced, in case the resolutions of the  underlying issues turn out to be different.

I agree that there should be only one place this is discussed. And from  the logic of the document, it is in other places. If there is something in  section 7 that should inform those other places, proposals for changes to  those other places should be made. I'll give other folks a little more time on  this issue to discuss, then do a straw poll of any concrete proposals on the  table (so far there is one, to remove 7.9, but I'm certain there could be  others that respond to the issues raised).

http://www.w3.org/2006/WSC/track/issues/127<http://www.w3.org/2006/WSC/track/issues/127>
http://www.w3.org/2006/WSC/track/issues/160<http://www.w3.org/2006/WSC/track/issues/160>

Mez