I'd like to circle back to this conversation.

I don't think there seemed to be any clear winners on the technical
front.

As a comment to Luke, in your comment that RFC 3961 implies a hash
function with the mandatory to implement checksum, that's not really
true. It happens to be true for the existing enctypes we care
about. However an enctype could use a CBC-MAC (or other modern
crypto-based MAC) which cannot work at all without a key and for which
you cannot perform the iteration prior to the key.
So, if we go with the just use a hash option, we do need to negotiate it
in our OID at least sometimes.

The one option I don't have a good understanding of is the option where
we expect extensions to offer a MIC themselves.
In this option, each extension token needs to provide any needed
protection itself. There is no protection for the conversation as an
aggregate; only its parts.
This can provide the same level of security; it just makes our job in
the IETF harder in terms of doing security review.

I'd like to ask some questions:

1) Are we willing to tightly control what extension tokens their are?
I.E. do we think standards action or IETF review  are appropriate
registration policies for extensions?

2) What extensions needing MICs have we identified?
Is the mutual flag the only one?
We'd presumably also need protection of removed extensions; we could MIC
a list of token types sent.

--Sam

3) It's my belief that if we protect against removed extension tokens,
we can add a conversation level finish message later if we wish. If we
chose to do so in a backward compatible way, then we would not be able
to have a hash function identifier in the OID.
We could have a hash function in the extension token identifier though.
Can I get people who understand the technical details in sufficient
detail to sanity check me here and confirm that we could add
conversation-level protection later if we chose?

Thanks,

--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to