On Sat, Jan 16, 2016 at 01:10:06AM +0000, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 7:08 PM Brian Smith <br...@briansmith.org> wrote:
>
> Hrm. That hadn't occurred to me, no. Fewer values sounds good, if we can
> lose them. I just wrote out all 9 without thinking about it much. Apart
> from "please don't cause me interop pain", I don't have strong opinions
> about how aggressively we prune the list.
Also, only the matching-size 3 of those 9 combinations tend to be
properly (as in, computing correct results most of the time)
implemented. Other 6 can easily be busted, especially the 3 where
hash is larger than curve, as that hits the hash truncation
special case.
> My main worry is, for better or worse (I realize this is a point of
> contention), some servers apply sigalgs to both CertificateVerify and
> certificates. If someone has an ECDSA-P384-SHA256 certificate, changing the
> definition of { ecdsa, sha256 } between TLS 1.2 and TLS 1.3 could be a
> nuisance.
I would think that any case where meanings are different (except for
case where use in TLS 1.3 is restricted) is a nuisance.
Avoiding these differences with restriction of server signatures to
RSA-PSS would imply that if client signals TLS 1.3 with only the only
RSA algorithms being the v1.5 ones, then server can't sign using RSA
if selecting TLS 1.3.
And it would also imply that if TLS 1.2 server gets TLS 1.3 client
hello with the new RSA-PSS algorithms, it can sign using RSA-PSS,
even after having downnegotiated TLS 1.2.
> Or maybe it won't? Such servers wouldn't be using TLS 1.3 right now. Though
> it would prevent them from adopting TLS 1.3 without switching certificates.
> Alternatively, if people decide that sigalgs and certificates officially
> have nothing to do with each other in TLS 1.3, then things are fine but we
> wouldn't have a way to negotiate such algorithms. I was hoping to avoid
> that issue for this proposal, but there is some interaction.
The ECDSA nasty case can only occur for certificate-to-certificate
linkages, since EE SPKI does not contain hash algorithm, and server is
always able to choose matching one.
Then TLS 1.3 AFAIK does not deprecate Brainpool, so Brainpool ECDSA can
also be seen...
Then RSA might be nastier: do normal RSA certificates work with RSA-
PSS? If not, then the TLS 1.3 servers can't use them.
> If changing the existing meaning is a nuisance, another option is to
> continue to allocate new values but only define ecdsa_p256_sha256,
> ecdsa_p384_sha384, and ecdsa_p521_sha512 (or whatever your favorite subset
> is) for TLS 1.3 and later.
If one does not want to change too much, then one would have to sup-
port those for TLS 1.2 as well (not breaking signature verification
if such algorithm is first advertised and then selected with connection
downnegotiated to TLS 1.2).
> > 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?
Things like: Trying to use ECDSA-P256-SHA384 and then one end not imp-
lementing it correctly (e.g. missing truncation).
Apparently ECDSA-P256-SHA384 failure rate is much higher than
ECDSA-P256-SHA256 and ECDSA-P384-SHA384.
> 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 think it is fairly unlikely that TLS 1.2 endpoints react to things
like 0x0703 or 0x0404. Since even known signature algorithms are un-
usable with unknown hashes, ServerKeyExchange is temporally localized
and CertificateRequest comes too late to be useful for filtering.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
