David A. Cooper <david.cooper=40nist....@dmarc.ietf.org> writes:
>what bugs would still remain that TLS-LTS fixes?
This is another thing that's already answered in the draft, for example:
In particular, this document takes inspiration from numerous
published analyses of TLS [TLS-Analysis-1] [TLS-Analysis-2]
[TLS-Analysis-3] [TLS-Analysis-4] [TLS-Analysis-5] [TLS-Analysis-6]
[TLS-Analysis-7] [TLS-Analysis-8] [TLS-Analysis-9] [TLS-Analysis-10]
[TLS-Analysis-11] [TLS-Analysis-12] [TLS-Analysis-13]
[TLS-Analysis-14] [TLS-Analysis-15] [TLS-Analysis-16]
[TLS-Analysis-17] [TLS-Analysis-18] along with two decades of
implementation and deployment experience to select a standard
interoperable feature set that provides the best chance of long-term
stability and resistance to attack, as well as guidance on
implementing this feature set in a sound manner.
Actually I'd end up quoting most of the doc which answers the above question,
but for one example:
TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
not p and g only, PKCS #3 style. This allows verification of the DH
parameters, which the current format doesn't allow:
[...]
* The domain parameters MUST either be compared for equivalence to a
set of known-good parameters provided by an appropriate standards
body or they MUST be verified as specified in FIPS 186 [FIPS-186].
Examples of the former may be found in RFC 3526 [RFC3526].
Peter.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
