Andreas Walz <andreas.w...@hs-offenburg.de> writes: >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly >addresses this in the Presentation Language section: > > "Peers which receive a message which cannot be parsed according to the > syntax (e.g., have a length extending beyond the message boundary or > contain an out-of-range length) MUST terminate the connection with a > "decoding_error" alert."
And how many implementations are going to do this? Consider the error-message litmus test I proposed earlier, reasons for failing to connect to (say) amazon.com: Error: Couldn't connect to Amazon because its certificate isn't valid. Error: Couldn't connect to Amazon because no suitable encryption was available. Error: Couldn't connect to Amazon because <explanation for decoding_error alert>. What would you put for the explanation for this case? And if you say "decode error" the user's response will be to switch to some less buggy software that doesn't have problems connecting. If you're writing a strict validating protocol parser than disconnecting in this case is a valid response, but if it's software that will be used by actual humans then failing a connect based on something like this makes no sense. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
