[cryptography] preventing protocol failings

Nico Williams nico at cryptonector.com
Mon Jul 4 23:15:00 EDT 2011


On Mon, Jul 4, 2011 at 6:28 PM, Sampo Syreeni <decoy at 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
--



More information about the cryptography mailing list