> -----Original Message-----
> From: Michael Richardson <[email protected]>
> Sent: Sunday, May 26, 2019 7:51 PM
> To: [email protected]
> Cc: Esko Dijk <[email protected]>; Jim Schaad
> <[email protected]>; Göran Selander <[email protected]>
> Subject: Pinning of raw public keys in Constrained Vouchers
>
>
> I've been trying to improve the text to better explain pinning of
registrar
> keys (rather than certificates), in order to resolve
> https://github.com/anima-wg/constrained-voucher/issues/18
>
> and also to remove as many bytes on the wire required to do constrained
> enrollment, the question came up. The registrar identity crosses the wire
> three times!
>
> 1) the registrar sends it's identity (whether raw public key or
> certificate) during the DTLS or EDHOC handshake,
>
> 2) the pledge sends the registrar's identity in the voucher-request
(signed),
>
> 3) then the MASA sends the registrar's identity in the voucher (signed).
>
> Couldn't we send a hash of identity in (2) and (3), and to do this we need
a
> 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).
Fixing on a single hash function would probably be frowned upon by the IESG.
The lack of algorithm flexibility would be an issue.
>
> 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.
As I remember things:
* Adding the random value would make the collision resistance attack simpler
for the registrar. It has some random bytes that do not have to have any
structure to create two different public keys with the same hash value.
* Adding the random value might make a second pre-image attack more
difficult, but I doubt it. You have more bytes as input, but that is
generally not the biggest issue for finding a second pre-image collision.
* You don't care about pre-image resistance if you are making the input
public.
Generally, one would want to person doing the signing to add the random
bytes to make the collision resistance attack harder. However, as one would
need to transport the random bytes this would not make things better.
I cannot speak to the level of security that is required for your solution.
However, strength is directly related to the size of the hash value.
Jim
>
> Please help me decide if this is a useful thing to do.
> If it's useful, is it useful enough to drop the
pinned-domain-subject-key-info?
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
