Martin Rex <[email protected]> writes: >The actual problem is the design flaw in TLS that availability of null >compression is not implied, but rather given a seperate codepoint, and the >server choosing null compression and continuing even when it is not >explicitly asserted by the client, is a server silently making up for that >design flaw in the TLS spec.
Yup, and I'd say it's perfectly valid behaviour. Compression is an optional extra, but you need to explicitly specify that you don't want it, something that's popular in the PKI world where you have a supposedly optional capability that isn't actually optional so you need to fill it with a dummy value to indicate that you don't care about it. >Up to TLSv1.2, TLS extensions were purely optional, so an implementation that >unconditionally ignores everything following compression methods is at least >fully conforming to SSLv3, TLSv1.0 and TLSv1.1. > >For an TLS implementation that parses TLS extensions, the behaviour of what >to do about trailing garbage is a different matter. Personally I prefer >aborting in case of garbage trailing TLS extensions. My code checks for extensions all the way down, but I could quite easily be persuaded that ignoring trailing garbage is OK too, based on what earlier versions of TLS did. Like RFC 3546 originally did for extensions, some future RFC might add a new field at the end, so not failing on finding more data may be a good thing. Or at least I can't see why it would be a bad thing. >What the server does in presence of multiple TLS extensions of the same type >is implementation defined. I think it would be extremely reasonable for a >server to perform a simple plausibility check on decode whether it is >decoding the same TLS extension more than once, and then abort with a >decode_error alert, in order to have ambiguities caught early. Recognizing >duplicate TLS extensions that the server does not support/implement does not >(yet) create ambiguities (for that server) and requires more complex code, so >I would not implement that check. +1. Remembering that you've already done a known extension is one thing, but having to track a potentially arbitrary number of extensions that you don't know what to do with anyway doesn't seem worthwhile. And then there's the same problem as with ignoring extra data at the end of the hello, at some point a future RFC may define an extension where having duplicate copies makes sense or is even required for things to work. So you don't really gain anything by ignoring duplicate unknown extensions, and will potentially break things in the future if you do reject them. Having said that, some extensions are purely signalling extensions, like EMS and EtM. I'm not sure if there's any problem with accepting doubles of those, it could just be the other side being emphatic. Consider how you'd need to report this to the user, "shut down the TLS connection because I saw two copies of some extension you've never heard of before", you can imagine what a user who sees that would think of the anal-retentive &^@#* who added special code to the handshake in order to reject it if this condition is encountered. Peter. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
