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

• From: Ian Fette <ifette@google.com>
• Date: Mon, 7 Jan 2008 15:35:19 -0800
• To: "Close, Tyler J." <tyler.close@hp.com>
• Cc: "Mary Ellen Zurko" <Mary_Ellen_Zurko@notesdev.ibm.com>, "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
• Message-ID: <bbeaa26f0801071535l531d6ff7qb1535da0eb1e9cdd@mail.gmail.com>

Less of chx-egg than w/ anti-malware ;-)
On Jan 7, 2008 3:28 PM, Close, Tyler J. <tyler.close@hp.com> wrote:
>
>
> 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"
> <https://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).
>
> https://www.w3.org/2006/WSC/track/issues/127
> <https://www.w3.org/2006/WSC/track/issues/127>
> https://www.w3.org/2006/WSC/track/issues/160
> <https://www.w3.org/2006/WSC/track/issues/160>
>
> Mez
>
>
>
>
>
>
>
>

Received on Monday, 7 January 2008 23:35:33 UTC