On Tue, Dec 22, 2015 at 11:59 AM, Adam Langley <a...@imperialviolet.org> wrote:
> You're correct, but I'm trying to say that the CFRG document defines a > function that operates on bytestrings so that higher-level protocols > don't have to worry about things like this. I think TLS should handle > the byte strings opaquely so that we have uniform behaviour for > X25519/X448 and only a single place where it needs to be tested. The > behaviour of X25519/X448 for non-reduced values is also specified in > the CFRG document. > I agree with all of that in principle. In fact, I think that most of section 2.3 should be removed in deference to the CFRG document, and only TLS-specific concerns should be given. I still think there is value in requiring senders to send their public value in the "normalized" form and for allowing (if not requiring) receivers to reject, at least, public values >= q, for the reasons I gave in my previous email. Ideally that would happen in the CFRG document. But, what is the status of the CFRG document? I've heard that it's past the point where changes will be accepted. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
