On Sat, Oct 17, 2015 at 07:25:46PM -0400, Sean Turner wrote: > On Oct 17, 2015, at 08:30, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > > Okay, did a review of draft-ietf-tls-curve25519 (since it still > > doesn't seem to have been WGLC'd): > > Note that draft-ietf-tls-curve25519 is getting merged into > draft-ietf-tls-rfc4492bis.
Do we also intend to put CFRG signatures work into that? Might be a good idea to merge the CFRG work already. The DHFs are stable. The characteristics of the signature scheme are known well- enough to already put the needed stuff in (if this is to be done), even if CFRG draft is still under work. My thoughts on how CFRG sigs are to be put in: - Reuse the ECDSA ciphersuites. - New signature algorithm EdDSA. - The hash algorithm is always 0 (None), even for Ed25519ph/ Ed448ph. - Two new curves, Ed25519 and Ed448, distinct from X25519 and X448. - If new hashes for existing curves are ever defined, those will get their own NamedCurve value. - Reference document specifying new algorithm for putting EdDSA public keys into PKIX SPKI. - All keys and signatures are octet strings with no internal structure when handled outside the signing and verification functions. - Don't use Ed25519 keys as Ed25519ph keys (and similarly for Ed448/Ed448ph). The CFRG spec specifically warns about this. And how the existing Curve25519 ECDH draft did things: - Reuse the ECDHE ciphersuites. - The X25519/X448 native point format is interpretted as "uncompressed". - Two new curves, X25519 and X448 (different names in that draft tho). - All keys are handled as octet strings with no internal structure outside the DHF. - There are no prefix bytes, so all fields containg public keys (ECPoint.point) and the ECDH result Z are both always 32 or 56 octets. Also, on reading the document, in numerious place it places the restriction that RSA end-entity certificate MUST be signed with RSA and ECDSA end-entity certificate MUST be signed with ECDSA. Why is this? To me, that kind of thing sounds like a leftover from TLS 1.1 days, when signature negotiation was a lot less flexible. It also seems like a special case where uniform handling would work just fine. Also, I think it explicitly contradicts TLS 1.2 RFC, which states that TLS 1.1 did have that restriction and then notes it is lifted (it also updates RFC4492). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
