On Tuesday, 28 November 2017 17:09:03 CET Ryan Sleevi wrote: > On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario <hka...@redhat.com> wrote: > > On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario <hka...@redhat.com> 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.
I provided a statement of my opinion, I didn't claim in it what your position was. You provided a statement that read "You're [...] propose to enforce neither of those through code or policy". That's putting words in my mouth - words which are exact opposites of my stance on the issue. > 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. they're not in conflict, the use of "at least" was deliberate in the first quote > 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. then that's a bug that needs to be fixed. Ryan, I have at least half a dozen of bugs on my name in b.m.o complaining about wrong alert /descriptions/ being sent by NSS as response to malformed packets. You really think that I won't be so through with rsa-pss in certificates? I already have bugs filed complaining of NSS allowing SHA-1 in MGF1 when sha-1 is disabled through policy! > 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? I definitely do not assume that, I just do not consider the issues we suspect to be there and issues we know about (and plan to fix in near future) to be blockers for shipping it, because RSA-PSS is in its infancy on the public 'net. I do think that they need to be resolved before TLS 1.3 is in its final state though. > 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. requirement that the certificates be DER encoded is part of X.509 standard, it's implicit the policy doesn't state that the byte is 8 bits long or that 'a' is encoded using big endian octet of decimal value 97 either... > 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. Because I do not consider making the salt length rigid (one value allowed for every hash) to be of any value. If it is not rigid, it would be silly to provide a correct encoding for every single possible valid encoding. OTOH, for salt length of 32 there would be one single correct encoding for which we could "provide examples of" (as only SHA-256 is valid for such short salt) > These examples of internal inconsistencies are instead why I tried to focus > on first principles, and would like to revisit them. Framed differently: _perceived_ inconsistencies... > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and > RSA-PSS signatures with the same key? depends on the circumstances I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5. So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase the security of the system, but it doesn't decrease it either. if one does use rsa-pss only (or has such intention), then use of pkcs#1 v1.5 with such key would lower the security of the system. > 2) Do you believe it represents a security risk to mix hash algorithms > within RSA-PSS signatures with the same key? like I said before, the problem is not that the key can be used with sha-384 and sha-512 at the same time - that I don't see as a risk, at least not now Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I don't think this should be allowed. Now, one may expect that SHA-256 will go the way of SHA-1, then having ability say "I won't use SHA-256", even when it is allowed by both policy and code is a value-add. > These questions are, perhaps, the crux of our disagreement. They should be > answered 'yes/no'. to paraphrase a great writer "Insufficient data for a 'yes/no' answer" -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
