On Tue, September 22, 2015 3:13 pm, Kathleen Wilson wrote: > == Arguments against removing the Email trust bit == <snip>
> Based on the information I currently have, and the discussion so far, I > think we should keep the Email trust bit. For a future version of the > policy, we can consider separating out the policy that is specific to > the Email trust bit into its own section. > > Did I miss anything? > > Is there any other input/feedback we should consider? Hi Kathleen, I think I'd disagree with a lot of the arguments against, in that they seem to be operating from either flawed assumptions or inconsistent statements. Intermingled in the arguments for the S/MIME trust bit is a defense of S/MIME, but that's not entirely relevant to the topic at hand I don't think. This isn't an discussion about whether or not Mozilla should come against S/MIME, or whether S/MIME is technically sound, but what are the implications to Mozilla - and potential downstream consumers. If I might try to summarize: == Arguments For == - We've heard from some Thunderbird developers that they rely on the NSS trust store to determine authenticity of S/MIME messages, and so that it's important for NSS trust store to support the e-mail trust bit for their needs. - Previously, we heard from some Red Hat employees (conspicuously silent in this discussion) that they rely on the NSS trust store as well to determine the authenticity of S/MIME messages, and so that it is important for the NSS trust store to support the e-mail trust bit for their needs. - We've heard arguments that the current Mozilla policy, as lax and liberal as it is with respect to S/MIME, is reasonable. - Related, we've heard arguments that starting a new S/MIME root program would be difficult, therefore it benefits the community to reuse the existing Mozilla processes and procedures. These are concrete items of feedback that are actionable. Arguments such as "The Internet has two killer applications" is not a reasonable or sound technical argument, because it's no different than if I were to advance the argument that "The Internet has two killer applications, virtual reality and food synthesis". That is, the proof is in the proverbial pudding, and we need consumers of NSS (such as Joshua from Thunderbird or, in the past, Bob Relyea of Red Hat) to chime in and contribute, otherwise we're talking about the world as we wish it was, rather than the world that is. We've also heard arguments for removing, for which the only 'weak' argument in that list that I would suggest is the discussion of alternatives, as that's a discussion related to S/MIME, not to the Mozilla store. I do want to echo many of the concerns Brian raised: - Reviewing S/MIME applications distracts from my own ability to review TLS applications or deal with improving TLS security. - I do not believe NSS implements correct, safe, or secure behaviours for S/MIME. Because I do not use S/MIME, I'm not motivated to fix these, nor apparently are other NSS or Thunderbird contributors. This can be empirically validated using public bugs Brian has mentioned or the private, unfixed security bugs within NSS. - In the past five years, I have trouble recalling a single incident, effort, or contribution by the community to improve S/MIME handling, with respect to policy or industry efforts. While I have no doubt that to some people it's "important", the lack of contribution suggests that the community is not actively engaged in dealing with security issues related to policy or implementation, suggesting it's "abandoned". - Simultaneously, the argument has been put forth that it's too much work for some other organization to take on, yet not a burden for Mozilla to take on. This logically appears inconsistent and is largely presented without evidence of the complexities or why obvious solutions such as "Do what Mozilla does" are not viable, unless the reality is that it is a burden on Mozilla to do so. One of the challenges in evaluating this proposal is the quality asymmetry between the Website Trust Bit and the Email Trust Bit. The Website trust bit is actively curated and reviewed, undergoes wide industry participation (via the CA/Browser Forum), is actively being policed and monitored (as recently demonstrated by Google's detection of a misissued Symantec certificate), and has active contributions to the codebase to improve support and consistency. The Email trust bit, however, is simply information gathering - by yourself. It does not undergo thorough community review, it is not being actively monitored for misissuance, and has zero industry efforts in the past decade to improve the issuance. Further, as Brian mentioned, the code itself is problematic for support, and the S/MIME support within NSS is a veritable font of bugs, as S/MIME relies on BER for interoperability, which adds a significant complexity footprint to the NSS codebase. Without active investment of Mozilla, these issues won't get fixed, nor would the ecosystem itself be improved if Mozilla is not an active participant - both the realities today. Finally, by having a single store represent these two trust bits, it incentivizes CAs to have a single issuance hierarchy responsible for both website and s/mime issuance, two very different types of certificates, and which regularly leads to questionable practices (as demonstrated by my recent CP/CPS reviews and the risks between personal certificates versus server certificates). How do we communicate this to consumers of the NSS root store? That one is "caveat emptor", and the other is "all hands on deck, always vigilant"? I believe the appropriate way to do that would be to remove the S/MIME trust bit. If the work to manage an S/MIME trust bit is 'not major' (I believe this is your position with respect to the impact to you), then it obviates the argument that it's difficult for someone else to do it. All the other externalities - code contributions, community participation, review - remain the same, but it's a clearer message where Mozilla and the NSS root store stand. Consumers, such as Thunderbird or Red Hat, can collaborate to establish policies and contribute time and resources to implementing and reviewing those. If that's too onerous to ask of them, why is it any less onerous to ask that of Mozilla? There's not really any economies of scale here that make it somehow 'better' for Mozilla to do it. Such arguments generally focus on the difficulty of setting up the 'how' to maintain it (e.g. "It would be too hard to set up Salesforce like Mozilla did"), except that's an intrinsic necessity, as shown by the many years you ran the program without Salesforce. Regardless of the counter arguments and the glowing endorsement of S/MIME, I think there's strong technical arguments being made for the removal, based on code health and fitness, suitability for purpose, and overall cleanliness. It may be that it's not much 'direct' work to support, but it continues an indirect endorsement that S/MIME is as first-class a citizen as TLS servers, when the clear and proven history of the past 5 years of contributions are that it is not, has not been, nor will it be. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
