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

Received on Friday, 2 November 2007 14:17:14 UTC