The purpose of the IETF is to support USERS USERS !
Not designers. So the stated design goals have to be taken with a pinch of salt. They are almost always wrong. Presenting them as immutable statements of permanent truth is bogus. TLS and SSH are the only IETF security protocols thus far that have not turned out to be technical triumphs but deployment failures. It is really easy for someone to push for a technical perfection that makes the protocol undeployable or unusable. Here we are all agreed that it is generally a bad thing for there to be this particular hole. That is not the issue. The issue is whether ignoring the fact that there are regulatory requirements for this capability and not supporting them results in a better or a worse outcome for users. So far the evidence suggests that refusal to consider them has resulted in a worse outcome. On Thu, Feb 16, 2012 at 12:24 AM, Martin Rex <[email protected]> wrote: > Kyle, > > Kyle H wrote: >> >> We MUST permit every use of our protocols. We MUST describe the >> computational processes and we MUST define the intended semantics, >> but we MUST NOT try to sabotage anything that the standards' >> implementors or consumers try to do. If we do, we're overstepping >> the bounds of what authority we can legitimately claim as standards >> designers. > > We seem to be talking about completely different protocols. > > *I* am talking about TLS (any version), which has the clearly stated > design goal: > > http://tools.ietf.org/html/rfc2246 > > Abstract > > This document specifies Version 1.0 of the Transport Layer Security > (TLS) protocol. The TLS protocol provides communications privacy over > the Internet. The protocol allows client/server applications to > communicate in a way that is designed to prevent eavesdropping, > tampering, or message forgery. > > http://tools.ietf.org/html/rfc5246 > > Abstract > > This document specifies Version 1.2 of the Transport Layer Security > (TLS) protocol. The TLS protocol provides communications security > over the Internet. The protocol allows client/server applications to > communicate in a way that is designed to prevent eavesdropping, > tampering, or message forgery. > > > What these MITM proxies are doing is _completely_and_thoroughly_ > subverting the entire purpose of the TLS protocol. They're doing > it not by exploiting weaknesses in the TLS protocol itself > (at least prior to rfc5746), but instead, by exploiting a long-standing > fatal design flaw in the security in the existing TLS X.509 PKI trust model. > > Those who want a protocol for encrypted communication that can be > arbitrarily MITMed should design themselves such a protocol. > Expecting the IETF to support continued exploitation of a serious > weakness in a security architecture that is the exact opposite of > its stated design goal is inappropriate for the IETF. > > > -Martin > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
