Re: [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 3

[Ned Freed <[e-mail]>]

>    "Protocols/APIs used to retrieve/verify external list membership MUST
>    provide at least the same level of confidentiality as protocols/APIs
>    used to retrieve Sieve scripts.  For example, if Sieve scripts are
>    retrieved using LDAP secured with Transport Layer Security (TLS)
>    encryption, then the protocol used to retrieve external list
>    membership must use a comparable mechanism for providing connection
>    confidentiality.  In particular, the protocol used to retrieve
>    external list membership must not be lacking encryption."

> Use Case One: Public FOAF

> how does banning access to public resources improve security?

> Use Case Two: Web Services

> how should an implementation judge whether a web service discovered
> over UDDI (say) is more or less confidential than script storage in
> LDAP (say)?

Complete agreement on all points. There are going to be all kinds of external
lists where the degree of confidentiality provided is an intrinsic
characteristic of the list itself and  isn't under the control of the Sieve
implementation. There are also going to be cases where the Sieve
implementation is accessing the list through an intermediary and has no
way of determining what security, if any, is being employed in accessing
the list. 

Specific examples of the latter would be a list provided by an LDAP proxy
server or a list provided by an LDAP server where the underlying attributes are
virtual and are resolved through some form of callout. Such setups are quite
common in practice.

The entire notion of there being a confidentiality requirement for
external lists independent of the list in question is completely silly.
Let's change this to say that both list content as well as the query stream
against the list MAY be confidential in nature and appopriate security
measures MUST be employed when they are.

				Ned