On 10/22/2015 06:29 AM, Eric Rescorla wrote:
From an implementation perspective, I wouldn't be surprised if client implementations choked on the server sending this. I had to check to see if NSS would do so. It doesn't, but given the way the codeis written, it wouldn't have surprised me if it checked that all extensionswere handled and choked otherwise.
Yeah, NSS was implemented under the old 'be graceful in what you accept' with the 'be a bit paranoid when security is on the line'.
That being said, in the early days of SSL3, unknown extensions were explicitly allowed, mostly so you could handle new protocols against old servers.
In practice this failed miserably because many server implementations followed the standard security paranoia of 'it's there and I don't undertand it, fail'. This is why we have/had TLS intolerance issues.
Anyway NSS is purposefully tolerant of well formed unknown extensions, as well as typically accepting new extensions on older versions of the protocol (like accepting ECC operations even though you negotiated SSL3).
bob
-Ekr
-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
