On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario <[email protected]> wrote:
> On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario <[email protected]> wrote: > > > > So no, we should not assume well-meaning actors, and we should be > > > > > > explicit > > > > > > > about what the "intention" of the RFCs is, and whether they actually > > > > achieve that. > > > > > > but we should achieve that by saying "do this", not "don't do this", > > > enumerating badness doesn't work - ask firewall people if you don't > > > believe > > > me. > > > > > > Or did we add to policy that keys revoked because they may haven been > > > compromised (heartbleed) can't be reused? Ever? Even by a different CA? > > > > You've completely misframed my proposal. I'm enumerating a specific > > whitelist of what is permitted. Every other option, unless otherwise > > permitted, is restricted. I'm even going to the level of proposing a > > byte-for-byte comparison function such that there's not even a prosaic > > whitelist - it's such that the policy is black and white and transcends > > language barriers by expressing directly in the technology. > > > > You're enumerating a blacklist - saying that all of the flexibility of > 4055 > > is permitted (except for these specific combinations), but propose to > > enforce neither of those through code or policy. > > where did I do that? > > it's the second time you're putting words in my mouth, I really do not > appreciate that. Hubert, while it's certainly not my intent to misrepresent your position, I think it's worth remarking that in your reply immediately prior, you highlighted that "but we should achieve that by saying 'Do this', not "don't do this", enumerating badness doesn't work". This was similarly putting words in my mouth - but, as I highlighted, it was a misunderstanding, and tried to clarify. To your question, the following statements were made earlier in the thread: "" - issuing certificates may include RSA-PSS parameters in the Public Key Info Algorithm Identifier, it's recommended that the hash selected matches the security of the key - signature hash and the hash used for mask generation must be the same both in public key parameters in certificate and in signature parameters - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64 bytes for SHA-512"" And yet, in a follow-up, you replied ""that would require hardcoding salt lengths, given their meaning in subjectPublicKeyInfo, I wouldn't be too happy about it looking at OpenSSL behaviour, it would likely render all past signatures invalid and making signatures with already released software unnecessarily complex (OpenSSL defaults to as large salt as possible)" I hope you can see how these two are in conflict - on the one hand, you suggest the policy should require X, but then suggest the implementation should not enforce X, because it would invalidate OpenSSL signatures. Similarly, with respect to the differences in our approaches, the framing you put forward is: ""for X.509 only DER is allowed, if the tags or values are not encoded with minimal number of bytes necessary, or with indeterminate length, it's not DER it's BER and that's strictly forbidden"" However, despite it being forbidden, the code contributed to NSS (and mentioned in your original post - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844) does not actually enforce this. The fact that this new NSS implementation does not properly validate the well-formedness of these signatures is somewhat in conflict with your statement: ""it turned out to be a problem because a). it was the 90's, b). everybody did it like that, c). everybody assumed (not test) that security software was written, well, securely...""" So are we to conclude that this is still a problem because everybody assumes, but does not test, that NSS is written, well, securely? This is similarly an example of a policy 'requiring' X, but this is not required through code or, with your proposed policy, required through policy. When I offered suggestions of how to avoid this, you seemingly rejected them (when taking the message as a whole), with your suggestion being: ""or provide examples of specific encodings with explanations what can change and to what degree..."" Which is to afford the flexibility of 4055 by encoding a variety of parameters - yet still in seeming direct conflict with the policy proposal you yourself made. These examples of internal inconsistencies are instead why I tried to focus on first principles, and would like to revisit them. Framed differently: 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and RSA-PSS signatures with the same key? 2) Do you believe it represents a security risk to mix hash algorithms within RSA-PSS signatures with the same key? These questions are, perhaps, the crux of our disagreement. They should be answered 'yes/no'. If they're yes, we should take specific steps to ensure that risk is minimized. If that answer is no, we should avoid adding complexity to the ecosystem. Hopefully that makes it a clear position. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
