Subject: [Ecrit] Holes and security

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 12 Mar 2010 07:59:31 +0800

The original holes draft had this for security considerations:

   This document does not introduce any security issues.

Which I still believe to be true.  But considering the wider implications, there might be something to add. 

Are there any objections to including the following text?

   Constraining the form of a polygon representation as described in
   this document does not introduce new security considerations.
   However, using polygons to describe LoST service boundaries can have
   the following concerns:
	
   o  Precise service boundaries with holes can have large numbers of
      points.  This results in LoST responses of significant size and
      complexity.

   o  A LoST server might not want to reveal service boundaries to
      clients.

   Both these cases can be addressed by providing smaller, simpler
   service boundary polygon in LoST responses.  This smaller polygon
   MUST fit within the actual service boundary.  This is possible
   because a LoST server is not required to provide a precise service
   boundary.  The service boundary need only indicate an area within
   which the service mapping does not change.

I didn't find anything of this sort in RFC5222, but I think that it's a worthwhile addition.

--Martin

---

From: Marc Linsner <[email-masked]>
Date: Fri, 12 Mar 2010 09:08:23 -0500

Martin,

My first take on this pertains to the scope of IETF document 'security'
sections.  It seems the proposed text is creeping outside the topic of
protocol security to application/implementation areas.  Wouldn't this be
better stated in a section of the document pertaining to 'implementation
issues'?

The analogy that comes to mind would lead to all IETF document security
sections will end up telling users the equivalent of, 'If you send your
password in the body of an email the recipient of the email will then have
your password.'

My take is the security section should deal with protocol security.

FWIW,

-Marc-

On 3/11/10 6:59 PM, "Thomson, Martin" <[email-masked]> wrote:

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 15 Mar 2010 08:42:05 +0800

Hi Marc,

> Wouldn't this be
> better stated in a section of the document pertaining to
> 'implementation issues'?

That's a good question.  To what extent does the possibility of receiving a large and complex response constitute a security concern?  As you say, you could say that it's not our problem and let the implementation deal with it.  However, reading 5491 and 5222, an LoST client implementer could easily make some very wrong assumptions about the nature of service boundaries and their size.

I can see how that might lead to a security problem, but will agree that this could be just an implementation concern.  On the other hand, the privacy aspect might warrant its mention in a security section.

I don't mind if this ends up being moved or not added at all.  

> password in the body of an email the recipient of the email will then
> have your password.'

I can see how inductive reasoning could be applied to reach this conclusion.  I don't think that it's necessary to follow every logical path to its extreme :)

> My take is the security section should deal with protocol security.

I'm not sure that this is entirely consistent with past practice.  We routinely discuss what implementations might like to do.  In GEOPRIV we routinely discuss privacy issues in the context of security.

--Martin

---

From: Marc Linsner <[email-masked]>
Date: Mon, 15 Mar 2010 13:31:04 -0400

Martin,

I'm certainly not going get worked up about these kinds of statements in the
security section.  ISTM a funny place to put it.

-Marc-

On 3/14/10 8:42 PM, "Thomson, Martin" <[email-masked]> wrote:

> That's a good question.  To what extent does the possibility of receiving a
> large and complex response constitute a security concern?  As you say, you
> could say that it's not our problem and let the implementation deal with it.
> However, reading 5491 and 5222, an LoST client implementer could easily make
> some very wrong assumptions about the nature of service boundaries and their
> size.
> 
> I can see how that might lead to a security problem, but will agree that this
> could be just an implementation concern.  On the other hand, the privacy
> aspect might warrant its mention in a security section.
> 
> I can see how inductive reasoning could be applied to reach this conclusion.
> I don't think that it's necessary to follow every logical path to its extreme
> :)
> 
> I'm not sure that this is entirely consistent with past practice.  We
> routinely discuss what implementations might like to do.  In GEOPRIV we
> routinely discuss privacy issues in the context of security.
> 
> --Martin