On 7/7/07, Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> 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.
note that it is not necessary to have at least one
mandatory-to-implement strong security mechanism to guarantee
interoperability.
This response sounds suspiciously similar to responses from defenders
of technology and procedures that don't work. That is, the response
assumes that the questioner doesn't understand the finer points of the
system. I'm sure there are details and strategies I don't know about,
but the point about shifting implementation burden is usually one of
the first qualifiers to get dragged out in these arguments. Amusingly,
it sounds pretty pointless in the context of the qualifier that
usually follows: "mandatory-to-implement does not mean
mandatory-to-deploy". This distinction might make sense when
classifying routers and things, but there's no way to tell the
difference for application protocols.
I'm interested in MTI success stories in application protocols.
Anything related to HTTP is right out, because that stuff doesn't
work. Peter mentioned a small success in XMPP, where implementors were
convinced to allow switching from SSL to TLS.
I'm also interested in the reasoning behind the IESG's decision to
allow Atompub to avoid requiring a specific TLS version. That
certainly allows for incompatible conformant implementations. I don't
understand why WGs are not permitted to make similar judgments
regarding other security mechanisms--they usually know more about
their market than the IESG does.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf