Valery Smyslov <smyslov.i...@gmail.com> writes: >I would add that if a (D)TLS profile for HL7 is written, UTA can be a natural >home for this draft.
This seems to be like using an S-300 to take out a drone, to update the rabbits and cruise missiles analogy. The OP described the behaviour of a broken TLS implementation that opens a TCP connection and then waits hours before actually negotiating the TLS connection, which has nothing to do with HL7. I can't imagine any non-broken server that would allow this, since it's a trivial DoS enabler. So there's no need for a profile or RFC change or anything else to fix this vendor's buggy software. All that's required is perhaps some definitive statement from the list that this is broken behaviour and they need to fix their code. Failing that, run their software up in a VM, perform a PoC DoS that takes advantage of this bug, and then file a CVE against it. If they insist that it's OK to do this you can then state that you don't want to copy their security vulnerability across to your implementation. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
