[saag] should we revise rfc 3365?

[Stephen Farrell <[e-mail]>]

Hi all,

Short version: go read the RFC and say if you think
it needs an update.

Long version:

We've been talking about RFC 3261 but Sean and I
have independently been thinking about whether
there's work to be done on RFC 3365 [1] from
2002 which is the one that basically says you
"MUST implement strong security in all protocols"
and for very good reasons.

First, we are *not* proposing to back off from that
general position. (We'll say that again in a
minute in case you missed it:-)

Since 2002 however, we've seen some cases where
this might end up being a bit counter-productive
or where its not clear if or how 3365 applies.

DHCP AUTH [2] is frequently cited in DHCP
security considerations. However, this is pure
fiction, nobody uses it at all, and I'm not
sure if anybody even implements it.

SIP e2e security [3] is well defined and has
been implemented, but is ubiquitously unused,
even though other SIP specifications tend(ed)
to refer to it as if it solves their problems.

FLUTE [4] is a uni-directional protocol, that
RECOMMENDS transport mode ESP, but where its not
clear that you could sensibly do automated key
management, if you really only have one-way
connectivity. (Just including this one to show
not all of 'em are as obvious as the above.)

In the purely fictional cases, there is a cost
for developers clearly, but also a potential
security downside, if there's a bunch of relatively
untested code being deployed, or if some but not
all people know which things are fictional and
which not.

In these cases the trade-off seems to be between
specifying MTI security vs. truth-in-advertising.
Some of these are easy, (dhcp maybe), others are
less easy (flute).

Truth-in-advertising seems like its a good thing,
but its hard to see how to get that without also
creating a future where lots of drafts say "we
don't do security because nobody would use it."

I'm sure there are more existing cases along
those lines.


Separately, we're seeing a number of cases where
something that is like, but is not, e2e security is
being proposed. For example, for inserting adverts
in IPTV [5], for supporting SSL accelerators [6]
and perhaps in the near future, for so-called
"tusted proxies" in HTTP/2.0 [7].

Again, there are probably more cases of this, but
here the trade-off seems mainly to be between what
are real use cases (sometimes already widely
deployed) and e2e security.


Our question to you: is it time that we revised
RFC 3365 to say something about these issues, or
more generally?

If so, then how? (Bearing in mind that we are *not*
open to a revision that neuters the position taken
in 3365.)

If you think RFC 3365 is still just fine and we
should not try revise it, then saying that would
also be good.

If a substantive discussion emerges we'd hope to
talk about that in Vancouver in July, so nothing
precipitous will happen. If this is greeted by
silence, then we'll take it that you all like
RFC 3365 and don't want us to do anything (except
keep on pushing back when people don't specify
mandatory-to-implement security:-) but that
will continue to be problematic in cases like those
mentioned above, so we may not be getting the
best outcomes at the moment in such cases.

Thanks,
Stephen and Sean.

[1] http://tools.ietf.org/html/bcp61
[2] http://tools.ietf.org/html/rfc3118
[3] http://tools.ietf.org/html/rfc3261
[4] https://datatracker.ietf.org/doc/draft-ietf-rmt-flute-revised/
[5] https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/
[6] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/
[7] http://lists.w3.org/Archives/Public/ietf-http-wg/2012AprJun/0085.html