Michael Thomas wrote:
Robert Sayre wrote:
Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."
I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies. [...]
On the other hand, I've seen with SIP where forcing the working
group to do this has been extremely counter productive. The reason
is that since it was backend loaded, ramming in S/MIME and TLS
was rife with mistakes and in the case of S/MIME was a solution in
search of a problem. Since we're talking about how things actually
turn out from process, it would be good to acknowledge that the
process in this particular case was ultimately counter productive:
instead of taking the time to get security right, we institutionalized
incorrect/non-interoperable behavior.
I seriously doubt that SIP is the only offender here as general clue
as to how to do this right is still arguably lacking, and it most
certainly doesn't get done in a fevered month before last call. IMO,
the process needs to take into account the reality of when we are
trying to graft security protocols onto implemented/deployed
protocols like SIP, SMTP... It's an effort unto itself and needs
to be carefully considered, and hopefully by a group of people
whose goal is to make something that's _useful_ and _interoperable_
rather than just squeaking through the IESG mandated process.
As another data point, in the Jabber/XMPP community our experience with
TLS has been quite positive, probably because we were already using SSL
for channel encryption before we formalized the "XMPP 0.9" protocols in
the XMPP WG. So the switch from SSL on a dedicated port to TLS upgrade
over the registered XMPP port was relatively painless.
Unfortunately, our experience with S/MIME has been less positive (and
yes I even use S/MIME for email). In part, that's because it was grafted
on in a way that was unpalatable to the XMPP developer community, with
the result that the relevant specification (RFC 3923) is unimplemented
as far as I know. Perhaps more important, the effort to add end-to-end
encryption proceeded in a way that did not reflect a serious effort to
define security requirements before deciding on a technology. And as is
often the case, deciding on a technology without first defining the
requirements can lead one astray.
I agree that we need to "take the time to get security right"; but I'm
afraid that the time to do so may be measured in years...
Peter
--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf