> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> > wrote: > >>>> This is exactly right. We have a real problem here. We should really >>>> solve it. >>>> We should do the math. :) >>> >>> Is there appetite to do this work? If we restrict this to two paths, one of >>> which is >>> spending years designing and implementing a new multi-party security >>> protocol, >>> the other of which is silently and undetectably (at least on private >>> networks) modifying >>> the standardized protocol for which lots of well-tested code already >>> exists... >>> my money is on the latter happening. >> >> There is a good chance that this "cheaper" solution is what will happen. > > Sure. The point is that IETF *must not* support such “undetectable > modifications of a standard protocol”. > The fact that crime invariably happens does not imply that we should become > criminals. ;-) > >> However the multi-party protocol may be a safer and better approach and may >> even >> forced in by some regulators when it exists as an implemented alternative. > > IETF is supposed to be about designing and (until a decade or so ago) > implementing the *right* solutions. In this case multi-party protocol > appears to be “it”. > > So let those who need this capability spearhead the design, with > cryptographers and academia helping that work or at least auditing the > results. > >>> In every decision we make with respect to the static DH approach, we have >>> to keep >>> in mind that this change can be implemented unilaterally, i.e., without any >>> modifications >>> for interop. Consequently, I think the work we really need to do is to >>> design and implement >>> a FS-breakage detector so we can at least tell when this is happening on >>> the public internet. > > I agree. Though I don’t know off-hand if this is technically possible. > Because as you pointed out, an end-point can always choose to leak its part > out-of-band, and there’s nothing his communicating peer can do about it > (AFAIK). (We can at least make sure that the official implementations such as > OpenSSL and GnuTLS do not include such “extensions”.) > > Still, a multi-party protocol that makes the presence or absence of such > monitoring explicit, would be the best option, IMHO.
At the very least, a standards-track multi-party protocol like that can be something that standards like PCI, HIPAA and others can latch on to and say “Do TLS 1.3 without backdoors unless you really need to and in that case use *this*”. That is better guidance than “Do TLS 1.3 without backdoors, unless you really need to and in that case do whatever works for you"
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
