On 20/07/17 18:08, Colm MacCárthaigh wrote: > On Thu, Jul 20, 2017 at 9:55 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> On 20/07/17 17:43, Colm MacCárthaigh wrote: >>> that's the term that people keep applying, >> >> That term was appropriate for draft-green as justified in [1] >> That's disputed by some folks but it's the correct term. >> > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I know you'll agree that's > not material. > > Claiming that current browsers "support" wiretapping is plain >> odd to me and not that useful for the discussion but isn't a >> TLS protocol issue as we don't currently have, and don't have >> a WG proposal for a draft-green like wiretapping API as part >> of the TLS WG set of RFCs. >> > > It is odd ... and I'm being deliberately provocative to get at the > doublethink. It is impossible to consider this mode wiretapping and not > claim the browsers support it today. Plainly, they do.
In what sense does a browser "support" a server leaking a private key via some proprietary interface? That makes zero sense to me and seems sheer hyperbole, as you said yourself. And not useful. > > We don't live in an abstract theoretical world in which this is not already More hyperbole is less useful. > happening, and is not already possible. When using crypto in a network protocol, it is impossible to know or not know that a peer is implementing crypto well or badly. > It will also continue to be > possible to MITM traffic, if you have the RSA key, and some dh-static > opponents even advocate for this. I have seen no intellectually consistent > explanation for why that is ok, I never said it was "ok." I said it wasn't part of the TLS RFCs. The point here is to not specify mechanisms that enable wiretapping to the extent that is feasible (you seem to assume that all uses of crypto "support" wiretapping, since it's always possible for an implementation to leak keys - that's gibberish IMO, but I'm using the term in your sense in this paragraph). > why that won't be abused by coercive > authorities, It could be. It'd still be abuse IMO. > and hence why it is not better to have something in between; "something in between" is just nonsense sorry. Your strawman proposition that we define all crypto as "supporting" wiretapping being nonsense, means that so is that bogus pseudo-compromise. But given that this aspect isn't really useful discussion, I hope we can leave it there. Cheers, S. > that gives providers what they claim to need, but not the coercers. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
