Hiya, On 16/07/17 05:41, Colm MacCárthaigh wrote: > On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > >> On 15/07/17 23:55, Colm MacCárthaigh wrote: >>> So far responses on the mailing list have been saying "Don't use >>> pcap, instead run proxies". >> Sorry, but that is incorrect. Some list participants have said "we >> need pcap" and others have said that "no, we do not need to use >> packet capture." And others, myself included, consider that there >> is dearth of evidence. >> > > Can you be more clear what is lacking in evidence?
Sure, sorry for the late-night terseness:-) In this debate, there is a fairly complete lack of evidence being offered as to: - the (in)effectiveness of proxies or key-leaking vs. one another and vs. not doing either - the precise scenarios in which pcap+key-leaking is the only possible (*) answer, and how commonly those scenarios occur (*) I am not asking that people tell me that "pcap+key-leaking" might work, but for them to describe when that works but nothing else works. And that has to include the details of what it is they can only find in the recovered cleartext that cannot be detected without access to cleartext using this particular method. > Are you skeptical that existing network operators don't do this kind > of decryption? I believe that people do this kind of key-leak+pcap decryption. People do all sorts of other unwise things too (myself included, and fairly frequently;-), that is not a reason to encourage more of "it" for any "it." > There's support for it in tools like Wireshark. Is that sufficient > evidence? Yes and no. That is sufficient in that yes it says that people can use this tool. It is nowhere near sufficient evidence that the IETF should standardise (an API for) such a tool. The existence of a wireshrark dissector for a protocol is also fairly weak evidence as to the importance of such a dissector - it seems to be fairly common for folks to write those for lots of other reasons, e.g. during protocol development, as student projects that require no thought from the prof etc:-) > Are you skeptical that there's no evidence that using proxies > instead would be a burdensome change? No. All changes are burdensome, and it's clear that that one would be. (My own belief is that adding proxies solely to help with possible network debugging would be dim anyway - I'd argue there ought to be a functional reason for each proxy added.) I would also note that the "use a proxy" argument seems to me to mostly be offered as a strawman counter-argument by folks who would like to break TLS via static DH, and doesn't seem to be a common argument offered by those against breaking TLS. (Adding proxies is of course another way to break TLS, depending on how and where it's done.) > I'm not skeptical of that at all, but would be interested in what > acceptable evidence would look like. I'm not sure of the phrase "acceptable evidence" but regardless of that: TLS is an important protocol, extremely widely used. For any attempt to weaken or break TLS, I think the onus is on the proponents of the break-TLS proposal to produce convincing evidence that their scheme will at least be a net positive, considering the entire ecosystem that is dependent on TLS. And even if there is evidence that a scheme would be a net positive, it may still be a bad idea, if the negative aspects of the scheme have serious enough impacts in some use-cases for TLS. That's a pretty high bar, yes. And so it should be. I'm not at all clear it can be cleared, ever. > Though I'll point out again: TLS 1.3 is the new thing that we want > to gain adoption, so really we should be looking for evidence that > it's /not/ a burdensome change. Sure, that is another fine thing to do. It'd be helped along if we had evidence about the precise scenarios in which the pcap+key-leak wiretapping is the only possible usable approach. That hasn't been described on the list. (It has been asserted that such scenarios exist, and it has been claimed that we should all know and accept all this already, but those were TBBA non-arguments.) Cheers, S.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
