W3C home > Mailing lists > Public > public-wsc-wg@w3.org > November 2007

Re: ISSUE-130 (Trust Anchors): Trust Anchor Consistency Across Devices? [Techniques]

From: Ian Fette <ifette@google.com>
Date: Fri, 2 Nov 2007 09:12:06 -0700
Message-ID: <bbeaa26f0711020912l1ff27611i1897aa1e9100c5be@mail.gmail.com>
To: "Johnathan Nightingale" <johnath@mozilla.com>
Cc: "Luis Barriga" <luis.barriga@ericsson.com>, "W3C WSC Public" <public-wsc-wg@w3.org>

I always have an opinion ;-)

My personal opinion would still be to say nothing. The webmasters
reading this W3C spec are likely an infinitesimal minority, and they
are probably the ones who are already aware of CA issues, if that
applies to them. I also don't want to say "Use a popular CA" for the
exact reasons brought up earlier. As for browser vendors, I think they
are aware of what their platform limitations are, and beyond that, I
think it's their choice what roots they feel comfortable including.
I'm just not clear exactly what we want to get out of this.

What I read is that people are concerned that having disparate sets of
trust-anchors across devices is a problem. I'm not sure if it is or
not, since I rarely (except for Google) visit the same sites on my
phone as I visit on my desktop. On my desktop, i visit www.nwa.com, on
my mobile phone I visit mobile.nwa.com. Maybe it's fine that there's
different trust anchors for these different sites, as long as they
work on the intended platform. Either way, I'm just not sure what the
useful message is that we could send out. Saying something to the
webmasters reading this is either going to be viewed as
anti-competitive pro-establishment, or preaching to the choir, or
both. As for the browser vendors, they clearly already have an
incentive to support the majority of the CAs in wide distribution
(otherwise their browser appears broken), but they need to be
comfortable extending trust to that CA, and on mobile, may have other
limitations. What would we say that would actually change anything?

On Nov 2, 2007 8:52 AM, Johnathan Nightingale <johnath@mozilla.com> wrote:
>
> Other than some wordsmithing (I don't know if even well-meaning site
> admins will know who a "trust anchor provider" is - would "hardware
> vendors" be appropriate?) I think your proposed text still reflects
> my sentiments.
>
> I wonder if Ian or Thomas has an opinion on whether this is more or
> less useful than doing nothing?
>
> Cheers,
>
> J
>
>
> On 2-Nov-07, at 11:43 AM, Luis Barriga wrote:
>
> > The email discussions seemed to indicate the need for some sort of
> > non-normative recommendation. I'm afraid the we have discovered an
> > important issue that if dropped will remain unknown/unaddressed. The
> > least we could do is to raise it.
> >
> > So, I agree with your proposed text raises the issue and encourages
> > some
> > good practice. I would slightly rephrase it while keeping the essence:
> >
> >> Web site owners operating https sites should anticipate the use of
> >> those sites from mobile platforms
> >
> > We should also cover not only desktop vs phone, but even phone vs.
> > Phone, i.e. Web site owners operating mobile-adapted https sites.
> >
> >>> which may have reduced cryptography abilities
> >                           ^^^^^^^^^^^^
> > [luis] it's more that crypto abilities, e.g. memory >> device
> > capabilities
> >
> >> These limitations can usually be addressed in ways that
> >> preserve security without hurting the user experience on either
> >> platform.  Web site owners should test the security features of their
> >> site on mobile platforms, and work with their certificate provider to
> >                                                 ^^^^^^^^^^^^^^^^^^^^
> >
> > [luis] It could more than one certificate providers and
> >        probably even trust anchor providers
> >
> >> implement solutions to any problems, rather than reverting to an
> >> insecure state, or blocking mobile access.
> >
> > [luis] The situation today is that the user has to make the trust
> > decisions.
> >
> > Thus, the reformulated text would be
> >
> >> Web site owners operating TLS-protected sites should anticipate the
> > use of
> >> those sites from mobile devices which may have contrained
> > capabilities.
> >> Even mobile-adapted TLS-protected sites can be accessed from a wide
> > range
> >> of mobile devices with differing device capabilities.
> >> These limitations can usually be addressed in ways that
> >> preserve security without hurting the user experience on either
> >> device. Web site owners should test the TLS security and trust
> > features of
> >> their site on mobile devices, and work with their certificate and
> > trust anchor
> >> providers to implement solutions to any problems, rather than
> > reverting to an
> >> insecure state, blocking mobile access, or leaving trust decisions to
> > the user.
> >
> >
> > -----Original Message-----
> > From: Johnathan Nightingale [mailto:johnath@mozilla.com]
> > Sent: den 2 november 2007 15:17
> > To: W3C WSC Public; Luis Barriga
> > Subject: Re: ISSUE-130 (Trust Anchors): Trust Anchor Consistency
> > Across
> > Devices? [Techniques]
> >
> > On 31-Oct-07, at 11:55 AM, Luis Barriga wrote:
> >
> >> Here is a summary of the discussions
> >>
> >> Issues:
> >> - Disjoint browsers' trust anchors in across devices
> >> - Non TLS-consistency mobile and desktop versions of the same web
> >> site
> >>
> >> Possible reasons
> >> - Memory limitatios in handled devices
> >> - Policy made by whoeever decide on trust anchors
> >> - Regional policies - some CA's are better trusted in some countries
> >>
> >> Discussed so far
> >> - Common set of anchors is a panacea
> >> - Most agree that recommendation makes sense but not normative
> >> - Need to agree what the recommendation would be and for whom
> >
> > Thank you for the summary Luis, I think it captures things nicely.
> >
> > I would point out that there are other limitations at work, notably
> > crypto stacks on mobile devices which don't support certain PKI
> > complexities (e.g. multiple signing chains, large key sizes).
> > Combined with the memory limitations you mention, they do seem to
> > argue
> > that a complete cross-platform solution is out of reach at the moment.
> >
> >> Proposal for recommendation
> >
> > I don't want to speak in negatives, but I do have concerns with us
> > recommending some of these things.  I'll answer point-by-point:
> >
> >> For Web Owners
> >> - Ensure that cert is signed by CA with wide coverage (?)
> >> - TLS consistency across handled and desktop versions
> >
> > The good news is that I think web owners already have strong
> > incentives
> > (stronger even than standards compliance! :) to use broadly
> > deployed CAs
> > if they want their user experience to not be beset by nag dialogs or
> > error pages in modern (desktop) browsers.
> >
> > Recommending that, though, seems sort of contrary to w3c principles
> > about openness, since it seems like a recommendation to go with
> > entrenched players, or at least a recommendation *against* any grass
> > roots "we're all going to use cacert.org until the browsers are forced
> > to let them in!" style web activism.  I don't know if that's a
> > realistic
> > scenario or not, but I do feel that we should be careful if we seem to
> > be recommending against decentralized "innovation at the edges."
> >
> > Consistency across handheld and desktop versions can bite you too -
> > maybe the best way to eliminate dialog fatigue and provide a secure
> > interaction for users is to deliberately diverge - to use a
> > stronger key
> > or more modern protocol enhancements (e.g. OCSP with stapling) on
> > platforms that can handle it, but fall back to something passably good
> > (e.g. a vanilla, 1024-bit CA-signed key without active revocation
> > checking) on mobile.  Does recommending TLS consistency help here,
> > or am
> > I misunderstanding the point?
> >
> >> For standards org
> >> - Need for a protocol to manage trust anchors. Could be IETF, XKMS
> >> ....
> >
> > I don't think we include recommendations for other standards bodies as
> > part of our official work, but I might be mistaken, and certainly have
> > no objection to someone like the IETF working on a way to facilitate
> > TA-management.
> >
> >> For Handled vendors
> >> - Allow adding trust-anchor online
> >> - ???
> >
> > s/Handled/Handheld/?  In either event - desktop user agents do
> > currently
> > support adding trust anchors but, if anything, I think we make it too
> > easy - point at a CA-cert url, click away some dialog boxes and you're
> > done.
> >
> > I see from the minutes that there were a couple people proposing that
> > this recommendation be dropped.  If there were a way to write these
> > recommendations to expressly address the problem of dialog-fatigue, of
> > mixed messages, I think some aspect could be a reasonable
> > recommendation.  Maybe just a Web Author Best Practice that read
> > something like:
> >
> >> Web site owners operating https sites should anticipate the use of
> >> those sites from mobile platforms which may have reduced cryptography
> >> abilities.  These limitations can usually be addressed in ways that
> >> preserve security without hurting the user experience on either
> >> platform.  Web site owners should test the security features of their
> >> site on mobile platforms, and work with their certificate provider to
> >> implement solutions to any problems, rather than reverting to an
> >> insecure state, or blocking mobile access.
> >
> > Is this too weak to be meaningful?  My hope is that most site
> > operators
> > are not actively mobile-hostile, they just don't consider it in
> > their QA
> > process, nor do they know how to cope with problems that may arise.  A
> > diligent admin (I think only the diligent ones would be reading our
> > recommendations anyhow) reading this might realize the oversight,
> > do the
> > testing and, in case of problems, have some option for mitigation.
> >
> > Cheers,
> >
> > Johnathan
> >
> > ---
> > Johnathan Nightingale
> > Human Shield
> > johnath@mozilla.com
> >
> >
> >
>
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
>
>
>
>
>
Received on Friday, 2 November 2007 16:12:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:53 GMT