pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
Eric Rescorla <ekr(_at_)networkresonance(_dot_)com> writes:
So, what's the right answer here?
Read the OID and hash value, toss the rest. Doing anything else is just
asking for trouble.
(There's really no question here: There are two ways to do this, knowing in
advance what you'll encounter in the field isn't possible, so the only
workable solution is to not compare the encoded value, or if you must,
compare two pre-encoded alternatives for each possible hash algorithm. This
still breaks though if someone gets the encoding slightly wrong... comparing
a pre-built value is just asking for trouble).
That approach, to not validate the parameters field, is what led to
the variant of Bleichenbacher's attack in several TLS implementations.
I'm strongly opposed to permit this in conforming implementations.
Even if we restrict it to either absent parameters or NULL parameters,
that would enable a side-channel: you can "leak" one bit of
information by deciding which of NULL or absent you use. It is not
clear to me how important that threat is. There are other ways to
leak information in the TLS protocol (packet ordering, random values,
etc). However, there may be some value in not expanding the ways to
leak information further.
I could live with MUST generate NULL parameters fields on encoding,
and MUST accept both NULL and absent fields on decoding.
/Simon