David Benjamin <david...@chromium.org> wrote: > (Whether such certificates exist on the web is probably answerable via CT > logs, but I haven't checked.) >
Me neither, and I think that's the key thing that would need to be checked to see if my suggestion is viable. 3. You get better interoperability with TLS 1.2's NSA Suite B profile [1]. >> (I don't have any particular affinity for that profile other than it seems >> to have made choices that have historically been shown to be above average, >> and it might be a good idea to avoid interop failure with other >> implementations that might have a special affinity for it.) >> > > What interop faliures are you worried about here? > The way I proposed things to work for TLS 1.3 is what the Suite B profile does for TLS 1.2. A Suite B client cannot describe the Suite B profile policy with the signature_algorithms extension as-is, so in theory if a Suite B profile client even exists, it would work better if servers assumed that ecdsa_sha256 implies P-256 and ecdsa_sha384 implies P-384. I don't know if any such "Suite B client" actually exists, though. > I don't think it makes sense to strategically assign the second byte for > new numbers. Either we believe TLS 1.2 implementations are unlikely to > react to 0x0703 and not worry about it, or we believe they will and we > reserve all numbers ending in 00-03. (Or we decide that this (u8, u8) to > u16 hack is too silly and don't do it at all.) > I would bet there will be some logic like "Is sha-256 mentioned at all in the signature_algorithms extension" and/or "is ecdsa mentioned at all in the signature_algorithms" extension that is used by some servers to decide whether to use a SHA-1 cert and/or whether to use an ECDSA cert, so I think it would be worth the effort at least when the effort is minimal. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
