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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf