Martin Thomson <martin.thom...@gmail.com> writes: >On 17 March 2017 at 10:45, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: >> In which case it might be time to update the RFC, since there's no obvious >> reason why you can't send it from the server. Can any of the original >> authors >> provide a reason why it shouldn't be done by the server? > >Most clients will explode if the server sends an extension that the client >didn't offer.
Is that from actually trying it with clients, or just assuming that implementations will do what the spec says? It's another one of those bits of TLS 1.2 that make no sense, so I've ignored the requirement in my code, you have to add a whole pile of code to perform the check (more attack surface) and the best possible outcome is that it has no effect, while the worst is that it breaks things if a buggy server drops in an extension the client wasn't expecting. In other words implementing it has negative utility. There's also the escape hatch of "server-oriented extensions", all you'd need to do is define one that tells the server that the client will accept any extensions the server cares to send, thus negating the "no server extensions" requirement. Given that this looks like an embedded-only sort of thing, I could even add it to -LTS, since a primary target of that is embdded/SCADA/etc. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
