Randy Bush wrote:
Scott O Bradner wrote:
2804 does not say not to talk about such things - or that such
documents should not be published as RFCs - 2804 says that the
IETF will not do standards work in this area
for those of us who are easily confused, could you differentiate between
working on douments and publishing them as rfcs from doing standards
work?
I can not answer this on Scott's behalf, but my interpretation of
this paragraph of 2804:
- The IETF, an international standards body, believes itself to be
the wrong forum for designing protocol or equipment features that
address needs arising from the laws of individual countries,
because these laws vary widely across the areas that IETF standards
are deployed in. Bodies whose scope of authority correspond to a
single regime of jurisdiction are more appropriate for this task.
means that while publishing information as independent submission
as RFCs would be OK, and talking about the technology or its consequences
for IETF protocols and standardization work is OK
(that is primarily a matter of free speech).
Discussion within the IETF on wiretapping technology, with the purpose
of changing either the wiretapping technology prior to publishing
it as RFC, or with the purpose of changing IETF protocols to facilitate
wiretapping technology is _not_ OK, independent of whether the document
is published on standards track or informational / experimental.
But it is really difficult to stay out of that rathole.
There is a wiretapping technology in use that is completely subverting
the security of "TLS" (Transport Layer Security), in form of transparent
intercepting SSL/TLS proxies, that impersonate the real communication
peers by forging themselves certificates on the fly, and by coercing
TLS clients, such as Web-Browsers through organizational authority,
to blindly trust and silently accept the certs that are forged by the
intercepting SSL/TLS proxies.
Such technology kills other protocol features of TLS besides integrity
and confidentiality protection along with it, such as client certificate
support and channel bindings.
It is not easy to decide what kind of discussion about such gear and
possible TLS extensions to facilitate such gear are OK, and which are
in conflict with rfc2804.
With DANE (DNSSEC-protected DNS "TLSA" records) conveying additional
information for verification the correctness of a TLS Server's
presented certificate (chain), silently intercepting TLS-protected
traffic will become _much_ harder for those intercepting SSL/TLS proxies.
-Martin