Re: [TLS] TLS 1.3 certificate delegation?

[[e-mail] (Martin Rex)]

Andy Lutomirski wrote:
> 
> FWIW, there's precedent for using new TLS versions to expand the set
> of allowable certificates.  If I"m reading it correctly, TLS 1.2
> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
> will reject those.

TLSv1.1 will certainly not reject those.
It is only rfc4492 that incorrectly alleges that those should be rejected.

And an implementation of TLSv1.2 client that would accept an ECDSA
EE server cert signed by an RSA cert when TLSv1.2 is negotiated,
but would reject the very same server certificate when TLSv1.1 is
negotiated (but would accept it with TLSv1.1 when a pure ECC
cert path is present) would yield "seriously broken" on my scorecard.

A number of TLS specs are plastered with rfc2119-violating
and therefore bogus and void requirements.

I somewhat optimistic that a number of implementations ignore
those bogus requirements already.  Fixing the remaining implementations
to ignore those bogus requirements might turn out to be easier than
fixing the documents, though...


What I find confusing about rfc4492 is how the hash for digitally-signed
is selected & signalled for TLSv1.0 and TLSv1.1--that seems somewhat
undefined in the document.


But then, using ECDSA with TLS would be pretty suicidal.  (EC)DSA are
an extremly brittle algorithms, i.e. "cryptoglycerin", and while
rfc6979 might help in producing k in constant time, the algorithm
for computing the inverse of k as specified in FIPS 186-4 Appendix C.1
is not a constant-time algorithm, and might leak sufficient "implicit hint"
about k that it makes the signing process "vulnerable to catastrophic
failures" when it is performed inband/online, such as in TLS, where
the server must sign each ServerKeyExchange handshake message inband.


-Martin