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