Subject: [saag] should we revise rfc 3365?

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 May 2012 23:53:44 +0100

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

---

From: Mouse <[email-masked]>
Date: Wed, 23 May 2012 19:51:01 -0400 (EDT)

> Short version: go read [RFC 3365] and say if you think it needs an
> update.

Yes, but I believe it's not one you're willing to accept.

> "MUST implement strong security in all protocols"

I believe this is too dogmatic a position, and will simply lead to IETF
process being ignored in those cases where strong security is
unnecessary or undeisrable.  Consider, for example, the number of
useful protocols we have today that could not be standardized under
this policy: whois, SMTP, and DHCP come to mind.  Based on a quick skim
of the specs, NFS is another one (even v4 doesn't seem to have MTI
security, only an MTI framework within which security can optionally be
done - but that's just a quick skim; I could easily have missed
something).

I know that, as an occasional protocol designer, if I believe a
protocol has no need for security, I would sooner ignore the IETF than
I would bother with shoehorning enough security to satisfy the IETF
into it.

Aside from this excessively (I believe) dogmatic position, I see
nothing wrong with 3365.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 23 May 2012 20:08:47 -0400

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:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 May 2012 17:56:29 -0700

>> "MUST implement strong security in all protocols"

To open a can of worms, this would also be a good doc in which to 
discuss the need for secure ports, and whether (or not) to ever assign 
meaning to the difference between system and user ports...

I was hoping to potentially open those discussions on TSVWG regarding 
the user-ports draft, but it might also be relevant here. I'm not sure 
if either will come to conclusion, but a round of discussion seems in order.

Joe

---

From: Mouse <[email-masked]>
Date: Wed, 23 May 2012 23:39:43 -0400 (EDT)

>> [RFC 3365]
> discuss the need for secure ports, and whether (or not) to ever
> assign meaning to the difference between system and user ports...

I submit that attempting to make such a distinction is effectively
meaningless, and has been ever since single-user machines - machines
owned personally by individuals who are their administrators - became
even moderately common.  It meant something (though even then not much)
in the days of large multi-user machines whose administrators could
reasonably be treated by the rest of the net as more trusted than the
bulk of their users.  Those days are long past; between personal
machines and pwn3d windows boxen, I think it is now pointless.

To look at it another way, there can be no distinction between system
and user ports from the point of view of network-observable behaviour,
since the "system"-vs-"user" distinction, to the extent that it exists
at all, is entirely private to each host; it is, therefore, pointless
to try to mandate any such difference.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 May 2012 10:25:09 +0300

Hi, 

I see this argument quite often that we should not impose strong
security requirements on protocols because there may be this use case
where no security is needed. 

I am wondering what protocols you are thinking about that need no
security. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> ext Mouse
> Sent: Thursday, May 24, 2012 6:40 AM
> To: [email-masked]
> Subject: Re: [saag] should we revise rfc 3365?
> 
> >> [RFC 3365]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 24 May 2012 10:47:03 +0300

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

Of
> ext Stephen Farrell
> Sent: Thursday, May 24, 2012 1:54 AM
> To: [email-masked]
> Subject: [saag] should we revise rfc 3365?
> 
> 
> Hi all,
> 
> [6]
https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/

---

From: Mouse <[email-masked]>
Date: Thu, 24 May 2012 09:16:29 -0400 (EDT)

>>> [...] the difference between system and user ports...
>> meaningless, and has been ever since [...]

That wasn't my argument here.  My argument is that "system port" versus
"user port" is not a useful distinction.  This is not to say that
security is unnecessary or a bad idea, just that as far as I can see
privileged ports are not a useful way to get any security for
general-purpose use, neither today nor in the foreseeable future.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 May 2012 09:12:34 -0500

I think we should say "should specify a MTI security feature" with
guidance as to when not to make it MTI or when not to bother
specifying the thing at all.  I-D authors should be required to
address this in the security considerations section.  Perhaps we
should stop at "tell us what you're doing about security and the
rationale for having or not having an MTI security feature".  The IETF
and IESG can review this and decide whether to insist that a protocol
have/not have a security feature.

Then DHCP could lack an explicit security feature on account of DHCP
being best secured by the link layer (the router/switch).  And so on.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 May 2012 16:30:47 +0100

Hiya,

> Aside from this excessively (I believe) dogmatic position, I see

So how would you phrase it so that we do get security
mechanisms defined in most all cases but not when they're
really really not needed (or fictional)?

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 May 2012 16:44:52 +0100

> security spec there is "buy a switch that blocks rogue DHCP

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 May 2012 16:50:51 +0100

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

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

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

> isn't a lot of harm after all. 

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

S

---

From: Mouse <[email-masked]>
Date: Tue, 29 May 2012 12:13:54 -0400 (EDT)

>> I believe this is too dogmatic a position, and will simply lead to
>> IETF process being ignored in [some cases].
> So how would you phrase it so that we do get security mechanisms
> defined in most all cases but not when they're really really not
> needed (or fictional)?

I don't think that can be done by drawing a hard line in the sand, as
3365 tries to do, regardless of where that line is drawn.  Whether
strong security is appropriate is a judgement call, as is how much
security constitutes `strong' for a particular purpose.  And judgement
calls have this annoying property that they require, well, judgement,
that they can't be made by unambiguous algorithms.

It's possible I'm just missing something, but I can't see any way to do
this that doesn't mean involving real humans.  3365 appears to be
trying to do it in a way that avoids needing to involve humans; I
believe that's possible only with a relatively high error rate.  In the
case of 3365, the errors take the form of imposing strong security on
protocols that don't need/want it; drawing the line other places will
distribute the errors differently, but I doubt it's possible to
eliminate them.

If this just resulted in unnecessary security, it wouldn't be so bad.
But I suspect it will, instead, result in IETF process being ignored
and protocols defined by rough consensus and running code _without_
IETF oversight, until/unless the IETF is more or less forced to either
violate its own process and standardize a protocol in its
widely-deployed form or blatantly ignore a popular and useful protocol
because it doesn't wear 3365's (or 3365bis's) straitjacket.

Of course, this is all my opinions and guesses.  I could be wrong.
Wouldn't be the first time, nor the last....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 29 May 2012 19:37:30 +0300

Hi Peter, 

when we develop protocols in the IETF they are meant to be used for the
Internet and you have to make the design according to the toughest
requirements and not the simplest. In many cases, protocol designers do
not really know how exactly their protocols will be used and so you
cannot just make some simplifying assumptions. 

For smart objects (you call them low-power devices) the approach is
still to provide security or otherwise not connect them to the Internet.

I think that this approach of providing a version of the protocol that
is completely insecure (in case we have a really convenient deployment
environment is really dangerous) as the usage of the protocol can
quickly be used in different contexts and then the user is in trouble. 

So, I think you are on the wrong track. 

Ciao
Hannes

> From: ext Peter Gutmann [mailto:[email-masked]]
> Sent: Saturday, May 26, 2012 3:18 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked];
> [email-masked]
> "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
writes:
> security
> >requirements on protocols because there may be this use case where no
> >security is needed.
> >
> It's not protocols that may or may not require security, it's uses of
> protocols.  Something on an internal LAN probably doesn't require it.
> Something on a CAN (where 'C' is for 'controller') almost certainly
> doesn't
> require it.  Low-power embedded devices (where the options are no-so-
> strong
> security or none at all) don't require it.  Systems where throughput
> and/or
> low latency are critical and you "secure" them by running a cable from
> box A
> to box B don't need it.  And so on and so on.
> 
> It's fair enough to say "if you require strong security then you can
do
> X",
> but saying "the protocol MUST include X" is inappropriate.
> 
> Peter.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 29 May 2012 19:50:00 +0300

I have a few clarifying questions regarding your mail. 

> that they can't be made by unambiguous algorithms.

I wonder whether you could provide some specific examples of where the
IETF provided too strong security solutions for a protocol. 

> distribute the errors differently, but I doubt it's possible to

Could you point to specific parts in RFC 3365 since it mentions users a
couple of times (with different meaning) and I did not see an obvious
problem with it.
> because it doesn't wear 3365's (or 3365bis's) straitjacket.

Are you saying that people ignore IETF security recommendations or that
the entire protocols are being ignored or what?

I think we have to pick specific cases to provide enough context. In the
abstract such a discussion quickly becomes meaningless. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 29 May 2012 19:53:59 +0300

Regarding the text below I believe I am suggesting to investigate the
cases where the security deployment did not happen as planned. We are
jumping to conclusions far too quickly and the reasons for why things
did not work out as planned may have many reasons - many of them may not
be so obvious. For some reason we often believe another document will
fix the problem.

In the IAB, for example, we did some reviews of protocols (with respect
to privacy) and got some interesting insights as to what the problems
were with the way we approached privacy in the past. I would be
surprised if nobody had ever looked at the details of how the work on
security evolved for specific protocols.

---

From: Mouse <[email-masked]>
Date: Tue, 29 May 2012 14:08:09 -0400 (EDT)

> I wonder whether you could provide some specific examples of where
> the IETF provided too strong security solutions for a protocol.

Where a protocol was standardized with more security than appropriate?
No specific examples come to mind.  But, upthread, I cited three (four,
I think) examples of protocols which are useful in their current form,
but that current form could not be standardized under 3365's
restrictions: whois, SMTP, DHCP, and (I think - see below) NFS.

>> 3365 appears to be trying to do it in a way that avoids needing to
>> involve humans; [...]
> Could you point to specific parts in RFC 3365 since it mentions users
> a couple of times (with different meaning) and I did not see an
> obvious problem with it.

No, the humans I was talking about are not users of protocols, not the
users 3365 speaks of.  The sense in which I see 3365 as trying to avoid
involving humans is that it appears to be trying to lay out a policy
that can be applied by anyone without requiring any judgement calls.

>> I suspect it will [...] result in IETF process being ignored and
>> protocols defined by rough consensus and running code _without_ IETF
>> oversight, [...]
> Are you saying that people ignore IETF security recommendations or
> that the entire protocols are being ignored or what?

What I suspect will happen - and this is just a guess - is that people
designing new protocols will look at 3365 (or 3365bis) and effectively
say "if the IETF requires that we put strong security in this protocol
then we'll just build it the way we want it and the IETF can go hang".

If I'm right, and such a protocol becomes popular, this will put the
IETF in the uncomfortable position of having to either (a) ignore a
popular protocol because it doesn't fit the IETF's policy dogma or (b)
ignore its own process and standardize a protocol that doesn't fit the
dogma.

I could be wrong.  But I've seen protocols developed independent of the
IETF adopted into the IETF framework (NFS is an example) often enough
that I think it's reasonably likely.  (Note that, unless I missed
something in my skim of the spec, NFS is also an example of a protocol
that violates 3365 - even in v4, it has m-t-i security infrastructure
but I didn't see any m-t-i use of it.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Mouse <[email-masked]>
Date: Tue, 29 May 2012 14:12:54 -0400 (EDT)

> still to provide security or otherwise not connect them to the

That may be the approach the IETF would prefer, but the IETF is not in
a position to do that, to prevent people from connecting devices to the
Internet based on whether they speak protocols the IETF doesn't like.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign