On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. > Right, there is a risk of interop failures if two implementations disagree on whether the algorithms exist in 1.2. Since getting these algorithms into 1.2 is not that important, I want everyone to standardize on the easier option (that is, they do *not* exist in 1.2). Otherwise we risk some implementations backporting (because the spec says to) and some not (because it is easier not to). > 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"). > TLS 1.3 SignatureScheme intentionally does away with the decomposition. It thinks of a "signature algorithm" at the level of messages, which means implementations shouldn't care about this. This also gives us more breathing room to allocate ed25519-style IDs (which I would like to be the norm, rather than parametrizing everything). We get most of our 2^16 space rather than just 2^8. > > 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. > Yup, that's why TLS 1.3's version looks the way it does. But if one has such a primitive, one shouldn't care about how the numbers are decomped (above). :-) > > 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. > When we first added TLS 1.2 to Chrome via NSS, we hit exactly that interop hazard. Clients don't know a priori which hash functions the server will accept and may be using some crappy smartcard. The original implementation only accepted the PRF hash (SHA-256) and we ran into both servers and client smartcards that could only sign SHA-1. As a result, NSS maintains a rolling SHA-1 "backup hash" here. (The failure mode was, of course, everyone's favorite TLS version fallback.) I am sure that, were we still using NSS when we added AES_256_GCM (SHA-384 PRF), we would have hit more problems with smartcards that can only sign SHA-256. But this is all sort of beside the point. The way to avoid this interop hazard is to maintain the full handshake buffer which is also how you backport. :-) I'm more worried about implementations which don't do the backport because it's more work or they don't want to pay the handshake buffer. > > 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... > (s/TLS 1.3/TLS 1.2/?) Yeah, I don't think defining it for 1.2 makes much sense. I expect 1.3 will get deployed much faster than EdDSA PKIs. > > (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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
