Re: [saag] should we revise rfc 3365?

[Steven Bellovin <[e-mail]>]

I'm very much in favor of security realism.  If something
doesn't work, it doesn't work.  One reason I wrote RFC 5406
is that protocols were specifying it as their security solution,
when (a) it was never implemented, and (b) it probably couldn't
work anyway.  DHCP AUTH is a good example -- the whole point
is minimal or no configuration.  I suspect that the proper
security spec there is "buy a switch that blocks rogue DHCP
(and IPv6 RA) packets)."

The specific changes, though, are a lot more difficult.  For
example, I'd leave the SIP stuff alone; I think there's a
disaster there waiting to happen, and I suspect that we will
see security implemented and deployed in a very big hurry.


On May 23, 2012, at 6:53 44PM, Stephen Farrell wrote:

> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb