Re: [saag] should we revise rfc 3365?

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Stephen, 

This is a good discussion question.

On the MTI issue: As someone who had been arguing with you in OAuth
about the MTI topic I am obviously interested to get a resolution on
this one. 
For others who had skipped the discussions in OAuth here is a pointer to
my summary:
http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html

I also noticed that some protocols do not necessarily have a realistic
security solution. The reasons are, however, often complex. 

SIP, for example, has taken quite a different deployment route than many
of us had thought and consequently security had been impacted by this
development as well. I don't even know where to start when talking about
the challenges for SIP security. There is a huge mixture of business
models (e.g., SBCs, interconnection models), technical & user interface
challenges, the attempt to replicate the PSTN (with all it the features)
and the rise of the Web. 

It is difficult to say what the right time is to conclude that something
had gone wrong and needs to be fixed or whether the time for a specific
protocol just had not come yet. I have this discussions periodically
with the mobility guys (and there is plenty of exciting security work
had been done with essentially zero deployment). Mobile IP is a
particularly interesting case since the security components are the
heaviest part in the protocol and the question arises whether the choice
of security technology has actually lead to the lack of deployment. 

On DHCP security: I have myself used the pointer to the DHCP security
document knowing that it is not implemented nor deployed. The good thing
about many DHCP extensions is that they do not get deployed and so there
isn't a lot of harm after all. 

Ciao
Hannes

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> ext Stephen Farrell
> Sent: Thursday, May 24, 2012 1:54 AM
> To: [e-mail]
> Subject: [saag] should we revise rfc 3365?
> 
> 
> 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