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

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

From: Johnathan Nightingale <johnath@mozilla.com>
Date: Fri, 2 Nov 2007 11:52:12 -0400
Message-Id: <9D2F5C43-1419-484F-8870-3B0336862DDF@mozilla.com>
Cc: "W3C WSC Public" <public-wsc-wg@w3.org>
To: "Luis Barriga" <luis.barriga@ericsson.com>

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 15:52:30 GMT

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