On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote: > [Changing subject since the other thread is about something else.] > > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist > in 1.2 because we're not touching the 1.2 registries. But this should be > clarified in the spec. I would actually prefer they stay 1.3-only. I > personally could live with either, but that's because we've backported the > 1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some > minor weirdness). I did intentionally mean for the scheme to be > backportable, but I do not think it should be mandated that implementations > do so.
If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better be able to gracefully deal with server picking on the offer, even after downnegotiation. Anything else, and you risk interop failures. Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older (no problems there: The server won't be able to pick on the offer). > 1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a > hash function and a signature algorithm which takes a pre-hashed value. A > 1.3 signature scheme is a function that takes a message. This means that, > to backport to TLS 1.2, implementations must remove all pre-hash steps and: The current signature algorithm numbers are messed up. I would have assigned 0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA. (That way the signature algorithms have proper hash designations, and yes 0x00 is hash designation for "unhashed"). > 1. For ServerKeyExchange, assemble the client_random || server_random || > ServerKeyExchange payload and then pass it into the signature scheme. > Current logic probably hashes and then feeds the hash in. If one has proper signature primitive, it takes a message and internally hashes it the way needed. > 2. Client CertificateVerify in TLS 1.2 messed up. We sign the full > handshake transcript, so there's interactions with the PRF. I've seen > implementations which require signing hash match the PRF hash, sometimes > with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a > mess. I've also seen implementations which decouple them, at the cost of > maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting > forces the second choice. By the time CertificateRequest is sent, the server knows the final protocol, so it can omit algorithms it knows it can't handle. Also, the client picks the actual algorithm, so it too can avoid algorithms it can't handle. So client auth isn't the interop hazard server auth is. > Notably, if backporting EdDSA, there is no rolling hash one can maintain > for CertificateVerify anyway. EdDSA is inherently message-based, which > motivated the 1.3 change. (That and simpler interfaces.) Well, proper crypto libs only have message-based signature APIs anyway (because hash-based ones are trouble). > There is a middle ground: we backport RSA-PSS (then we should assign it in > the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA. > I intentionally did not do this. I did not want, many years down the line > when EdDSA certificates actually exist, for implementations to discover the > message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style > so any questions about the new scheme would be resolved early. Well, RFC4492bis is likely have EdDSA, in way that is compatible with TLS 1.3... > (We've implemented the message-based scheme and it seems to be just fine. > If you're willing to pay the cost of the backport to all versions, it > actually ends up quite tidy.) Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but there either side can decide just not to support it. No such luck with clients that implement the algorithm for server certificates in any version. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
