Bear in mind that what we (or at least I) want out of not publishing a spec is that this technology not be present by default in TLS implementations. If someone wants to maintain a set of patches, there's not much we can do about it, and I don't honestly care *because* there isn't much that we can do about it. What I do not want to see is *the IETF* recommending this solution.
It would be very nice if the people who are hot on a solution to this problem were willing to do the work to do the three-way protocol. But the purpose of pointing out that that is the right solution is to say "if you want to solve this problem in the IETF, here is what we could do that might get IETF consensus." On Wed, Jul 19, 2017 at 3:51 PM, Kyle Rose <kr...@krose.org> wrote: > On Wed, Jul 19, 2017 at 3:43 PM, Ted Lemon <mel...@fugue.com> 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. > > 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. 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. > > Kyle > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
