Re: [Anima] Pinning of raw public keys in Constrained Vouchers

[Michael Richardson <[e-mail]>]

Jim Schaad <[e-mail]> wrote:
    >> new element in the constrained voucher.  This I've given the mouthful name
    >> of:  proximity-registrar-sha256-of-subject-public-key-info
    >> and: pinned-sha256-of-subject-public-key-info
    >> (knowing that the YANG->SID process will turn this into a small integer).

    jim> Fixing on a single hash function would probably be frowned upon by the IESG.
    jim> The lack of algorithm flexibility would be an issue.

So extending to other hash functions is just a question of amending the YANG.
There aren't hundreds of hash functions, and SID values should provide space
for at least 30 code points here.   Perhaps explaining how the algorithms can
be agile in the Security Considerations.

    >> A sha256 hash is 32-bytes in size.
    >> A 256-bit ECDSA key is about 32-bytes in size.
    >> An equivalent 2048-bit RSA key is 256 bytes in size.
    >> So the hash only wins if we use bigger ECDSA keys, or if we use RSA.
    >> (okay, so there are a few bytes for the subject-public-key-info (SPKI)
    >> wrapping, which also provides algorithm agility)
    >>
    >> We could truncate the hash if we felt this was still secure enough We
    >> could
    >> add the length of the thing (the RPK) being hashed if that would help with
    >> pre-image attacks, but that's mostly already there in the SPKI encoding,
    >> but I
    >> suppose an attacker might find a way to prepad with nonsense DER.

    jim> As I remember things:

    jim> * Adding the random value would make the collision resistance attack simpler
    jim> for the registrar.  It has some random bytes that do not have to have any
    jim> structure to create two different public keys with the same hash
    jim> value.

Sorry, do you mean, simpler for an attack on the registrar?

I'm saying that the subject-public-key-info starts with an
AlgorithmIdentifier, which is a sequence.  An attacker could add additional
items to the sequence in order to make a second pre-image attack (usually
that requires additional bytes, changing the length of the item).
This depends upon the victim verifier ignoring the extra bytes somehow; a
Postel Principle parser might do that, and if I were building a pull-parser
for this, I might do that.

In practice, most constrained implementations avoid DER parsing by accepting
a known sequence of bytes for the subject-public-key-info and use memcmp().
I.e. they are extremely conservative in what they accept, to the point of
violating the specification one could argue.

    jim> * Adding the random value might make a second pre-image attack more
    jim> difficult, but I doubt it.  You have more bytes as input, but that is
    jim> generally not the biggest issue for finding a second pre-image
    jim> collision.

    jim> * You don't care about pre-image resistance if you are making the input
    jim> public.

What do you mean by the part about public?
Yes, in DTLS 1.2, the certificates are visible, and an active attacker can
see them.

    jim> I cannot speak to the level of security that is required for your solution.
    jim> However, strength is directly related to the size of the hash value.

We make certificates by doing sha256 hashes of the subject-public-key-info
and other names, and having the CA sign that.  I think that it makes no sense
to truncate the hash going into a 256-bit sized signature, since ECDSA signs
256-bit values.   I am not sure how to evaluate the strengh required here.
It's a CBOR value, so it has a length, and I suppose we could define a way to
truncate the value in a standard direction, and then decide later.

I think that a non-truncated hash ought to be as strong as sending the key
itself, and having two code paths is not a win here.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-