On Wed, 19 Aug 2020 18:45:44 +0000 Nancy Cam-Winget (ncamwing)" <ncamw...@cisco.com> wrote: > Section 4.2 Encrypted Server Certificate describes a practice > which is inherently unsound. Passive inspection of the Certificate > message from TLS 1.2 or earlier isn't a reliable source of > information because a passive eavesdropper isn't able to discern > whether the X.509 document presented corresponds to this server or > not. The Client can confirm this using the TLS protocol but an > eavesdropper can't. So the change in TLS 1.3 does not impact the > practical security policy available, only an appearance is altered. > [NCW] The document describes what is in practice today with TLS 1.2 > and 1.1 whether we believe it is unsound or otherwise, it is what is > done today.
It's not a problem for the document to describe today's practices but it's a mistake to label them "effective" if we know they are not. > Passive systems described throughout Section 5.1 fall to this same > error, using the phrase "reduced effectiveness" which the document > defines as not being "as effective on TLS 1.3 traffic" but in fact > since this practice didn't work, it will remain exactly as > effective (not at all) as before. > [NCW] Again, the document is describing what is in practice today. Describing something as "effective" when it is not effective isn't a matter of today's practice but of a misunderstanding of what's possible at all. > A related consequence passes into Section 5.2. Since the > Certificate message is only reliable for a Client, it has in fact > always been necessary to fully proxy the TLS session in order to rely > on this data, so this is not in fact an impact from TLS 1.3 but (if > it wasn't done previously for all versions) a vulnerability in such > products. [NCW] With TLS 1.2 the observer can see the handshake thru > completion with the Finished message before affecting a policy > decision. The passive eavesdropper can indeed see the handshake in TLS 1.2, but since they were not a participant they don't actually know what it means even though it wasn't encrypted. For example, suppose an RSA certificate is sent and the handshake seems to agree RSA key exchange and Client sends an EncryptedPreMasterSecret. The passive eavesdropper has no idea if that's actually encrypted to the RSA public key from the certificate, it's just an opaque blob. Thus it's easily possible for an eavesdropper to witness a handshake in which the eavesdropper believes what happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret to the local hospital both agreed this all worked fine and continue encrypted The eavesdropper's "Don't eavesdrop on people's medical stuff" policy kicks in and it allows the connection unmolested. Unfortunately what really happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret for the GRU data exfiltration server ignoring the bogus certificate $5Bn of stolen commercial documents are uploaded to the server Nick. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
