Re: [saag] should we revise rfc 3365?

[Stephen Farrell <[e-mail]>]

On 05/24/2012 01:08 AM, Steven Bellovin wrote:
> 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)."

Agreed. Hard to figure how to state that well though in
the general case.

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

I can well imagine that happening and tend to agree
that e2e security for VoIP signalling really should be
well defined.

But, if it is needed in a hurry, I'd wonder if its likely
they could do it well based on their current specs. I
guess the s/mime-like approach they have might not be
so easy to deploy in a rush given that they have no
real experience of its use.

Perhaps that implies that for protocols where the
proponents don't want to bother with e2e security we
ought push back on them, but put more focus on
getting them to adopt something easy to deploy if
needed, rather than focusing on the high-security
aspect?

Again, even if that's correct (and I'm not sure it
is), I don't know how to state a general principle.

Maybe something like "even if (you claim) you really
don't need to use e2e security now, you still need to
define something equivalent to an SSH leap-of-faith
as a way to enable e2e security for your protocol,
just in case you need it later in a hurry"?

I guess that might be seen as a conflict with
BCP107 though?

Cheers,
S.

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