On 3/12/13 10:43 PM, Tobias Gondrom wrote:
regarding: SHA-1/SHA-256: please consider that we should have hash agility whenever possible. There will be SHA-3 and future ones....
Hi Tobias.I agree with Chris that we should not specify weak algorithms in new specs. If we had a bunch of deployed HPKP headers with SHA-1, that would be different.
Having just SHA2-256 as MTI is fine, while leaving the door open for other algorithms. SHA2-384 and SHA2-512 and even SHA2-512/256 are pretty easy.
SHA-3 is different, because for efficiency, NIST intends to use different tuning parameters for different uses. So we might end up with one SHA3-256 for MACs in TLS and IPsec, and a totally different SHA3-256 in certificate signatures, and yet a third one used for HASH-DRBG. That means you can't just label something "pin-sha3-256" and expect all implementations to inter-operate. You'd need to write an RFC "The SHA-3 algorithm and its use in key pinning", where you'd specify the parameters for SHA3 in this context.
But really, SHA2-256 is an excellent MTI - it performs OK, it's considered secure against second pre-image, and there are no current indications that compromise is coming.
If somebody wants to later do this, they can create the directive registry then.
Yoav
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
