Re: [saag] should we revise rfc 3365?

[Stephen Farrell <[e-mail]>]

On 05/24/2012 08:47 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi Stephen, 
> 
> This is a good discussion question.

But isn't lighting up the list. That's ok. If folks don't
find this pressing, then I guess we continue as usual.

> 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

Right. I ended up in the rough there but of course still
think I was right and the WG were wrong:-)

> 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. 

So are you arguing that we ought stage "compliance" with
3365 somehow? Even for standards track specs? I think I'd
push back against that on the basis that it'd be hard to
believe a load of WGs would properly consider security
but not produce the goods until after their main work is
done. It'd also be bolt-on security as well I guess, which
often turns out badly. (Though fictional security is also
maybe just as bad.)

> 
> 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. 

Nice! I may use that quote later, when you're not
expecting it:-)

S

> 
> 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
> 
>