I’m not even sure what my position is on this. Specifying the use of a
context here goes against the recommendation in the CFRG draft:
Contexts SHOULD NOT be used opportunistically, as that kind of use
is very error-prone. If contexts are used, one SHOULD require all
signature schemes available for use in that purpose support
contexts.
If someone knows why this recommendation was made, that would be great.
Basically, then those other methods would be a weak point for attack.
But we are trying to migrate away from the old methods, into the new
methods. The fewer servers use the old methods, the better off we are,
right? So we expect the attack surface to gradually be reduced over the
coming years.
Then there's the serious deployment problems with contexts, as those
don't fit into any standard notion of signature various libraries have.
These are new algorithms that are still not widely deployed. The fact
that several open source libraries (still) don't support a certain
function parameter is not a very strong reason not to require it.
Thanks,
Yaron
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
