CCC-Attestation / interoperable-ra-tls

Design documents and interoperability tests for Interoperable RA-TLS projects
Apache License 2.0
10 stars 3 forks source link

Specify the (minimal) set of required hash functions #6

Closed dimakuv closed 1 year ago

dimakuv commented 1 year ago

We state this: https://github.com/CCC-Attestation/interoperable-ra-tls/blob/a2c2323377007aa27b5ceb453a741a860e0245a0/docs/Interoperable-RA-TLS-cert-edvidence-formats.md?plain=1#L21

However, the hash-entry representation allows for multiple hash functions: https://www.iana.org/assignments/named-information/named-information.xhtml

But e.g. Gramine uses mbedTLS (currently v3.3.0), which doesn't have SHA-3. Also, there are some exotic hash functions like blake2s-256 which probably will never be supported by many crypto/TLS libraries.

So I think for better interoperability, the Interoperable RA-TLS standard must explicitly state the minimal/preferred set of hash functions supported by any compliant implementation. I suggest this subset:

shnwc commented 1 year ago

Thank you for the comment! I've created PR #7 that puts the proposed IDs in the supported list.

dimakuv commented 1 year ago

PR #7 looks good to me, I'm closing this issue.

(By the way, if you want the PR to auto-close the issue on GitHub, you should put Fixes #... in the PR description -- then GitHub will close the issue automatically once PR is merged.)

dimakuv commented 1 year ago

I would like to settle on one point that was missing in #7 (sorry, forgot about it).

Here is the exerpt from my proposal:

I suggest this subset:

  • ID=0, RESERVED -- defaults to sha-256

But #7 (and the current spec draft) doesn't mention this special case of ID=0. Can we assume anything about ID=0? Or should implementations error out when they receive ID=0?

@shnwc @KB5201314 @jiazhang0 @kailun-qin What do you think?

kailun-qin commented 1 year ago

I don't think it's a good idea to default the reserved ID=0 to a specific algo (and maybe even worse to default to sha-256) for the interoperable RA-TLS spec. Normally the reserved is designed for possible future use and making assumptions on ID=0 in interoperable RA-TLS may incur potential compatibility issues.

imlk0 commented 1 year ago

Agree with @kailun-qin, the reserved ID=0 should not be a vaild hash algo ID.

dimakuv commented 1 year ago

I will wait for opinions from others, but in the meantime, I removed this assumption "ID=0 is SHA256" from Gramine: https://github.com/gramineproject/gramine/pull/1039

shnwc commented 1 year ago

Agreed not to assign / redefine reserve ID=0 for sha256. Valid algorithm ID values must be used. As stated in IANA registry, value zero is "Reserved" and does not identify a hash algorithm.

dimakuv commented 1 year ago

Thanks, let me close this issue.