Hello Peter,
This doesn't really answer my question. I don't have time to read
through the 18 analysis papers. but [TLS-Analysis-14] describes the
Triple Handshake attack. Isn't that fixed by the extended_master_secret
extension (RFC 7627)? If so, then this could be addressed by a guidance
document that mandated support for extended_master_secret (as RFC 9325
does), and it wouldn't be an example of a bug that could only be fixed
by defining a new (tls_lts) extension.
TLS-LTS addresses an issue with DHE cipher suites by sending the full
set of DH parameters. Why couldn't the issue be addressed by mandating
that clients offer the supported groups extension with RFC 7919 groups
and mandating that servers only use those groups? (Another option would
be to disallow DHE cipher suites as
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
does.) I understand that draft-gutmann-tls-lts suggests a problem with
RFC 7919 in cases in which it is not supported by both the client and
the server, but I don't see how TLS-LTS solves that. What happens if the
client offers the TLS-TLS extension along with DHE cipher suites, the
server doesn't support TLS-LTS and selects a DHE cipher suite along with
the DH group that the client cannot verify? This isn't an issue if the
client knows the server supports TLS-LTS, but what's the problem with
using RFC 7919 groups if the client knows the server supports them?
A lot of what is in draft-gutmann-tls-lts is specifying a profile of TLS
1.2 (e.g., only use this limited set of cipher suites, only use this one
elliptic curve, etc.), or is specifying implementation requirements
(e.g., verify RSA signatures as encode-then-compare). So, most of what
is in the document is profiling existing capabilities, not describing
bugs that can only be addressed by defining a new extension.
On 11/26/24 6:20 PM, Peter Gutmann wrote:
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
