On Mon, Jul 4, 2011 at 6:28 PM, Sampo Syreeni <de...@iki.fi> wrote: > Personally I've slowly come to believe that options within crypto protocols > are a *very* bad idea. Overall. I mean, it seems that pretty much all of the > effective, real-life security breaches over the past decade have come from > protocol failings, if not trivial password ones. Not from anything that has > to do with hard crypto per se. > > So why don't we make our crypto protocols and encodings *very* simple, so as > to resist protocol attacks? [...]
What did you mean by "options"? Did you mean optional elements and negotiations? Or were you referring specifically to encoding issues? Regarding the latter: BER and friends are dangerous because they result in much redundancy in encodings. Regarding the former: it's generally best to push any negotiations to one level (more on that below) and to avoid any two-level negotiation like the plague. Consider an IMAP application that allows the negotiation and use of one of various SASL mechanisms, including GSS-SPNEGO, and through it NTLM, Kerberos, and maybe others. Such an application has up to three levels of negotiation! One for selecting a SASL mechanism, and if GSS-SPNEGO is selected, then a negotiation in SPNEGO, and if Kerberos is selected, then a negotiation for a Kerberos "enctype" (i.e., cipher suite). Three levels of negotiation makes negotiation unpredictable and makes it difficult to put enough control over negotiation choices in the hands of the application. Thus one of the worst API elements is the Cyrus SASL "security strength factor", which is intended to allow sorting of mechanisms by cryptographic strength, and which always assigns a value of "56" to Kerberos, as if 1-DES were the only cipher Kerberos supports! But "SSF" is bad primarily because it's too rough and subjective a measure of cryptographic strength. Instead we could have named "profiles" which applications tell the cryptosystem must be met, leaving it to the security mechanisms to enforce the profiles. (The SASL community has decided to avoid the two-level negotiation problem in the future by insisting that new mechanisms have all cipher suite choices baked in. If you want to add a new cipher suite to a mechanism you just add a new *name* for that mechanism and use the negotiation of mechanisms to embody the negotiation of cipher suites.) Can we get rid of all options? Hardly. First, we need at least one level of negotiation so we can have some degree of cipher suite agility. Second, I've a hard time imagining how we might avoid all other optionality in crypto protocol designs. Extensibility has been a good thing. We could extend things by abandoning old protocols and replacing them with extended versions, but even if we accepted all the resulting garbage we'd still have a need for optionality in many cases. I can imagine a world that relies on relying-party only certificates, which require nothing more than a public key and public key algorithm identifier, and DNSSEC as the only PKI. That would mean we could say goodbye to all of the complexity of PKIX, but we'd still have extensibility via algorithm IDs and DNS, such as via new RR types. But I can't imagine a world in which relying parties don't have to obtain "authorization data" regarding their peers in order to perform authorization, and there's lots of options that people want regarding authorization... Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
