>>> 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. >> Beyond that, the best we can really do is ask implementors to be polite and >> intentionally >> make their implementations not interoperate silently with TLS 1.3. I agree.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
