Re: [apps-discuss] Alissa Cooper's Discuss on draft-ietf-appsawg-sieve-duplicate-07: (with DISCUSS and COMMENT)

[Ned Freed <[e-mail]>]

> > I would still be interested in discussing this bit of my DISCUSS:
> >
> > o Section 6:
> > Sieve scripts that include duplicate tests contain potentially sensitive
> > information (e.g., subject or body strings).

> Actually, no more so than any Sieve script.  Filtering on patterns is
> reasonably common, and I don't think duplicate detection will increase
> that.

Probably less so. Consider:

# Banking rule autogenerated based on user preference settings
if address :domain "from" "bankofamerica.com" {
  fileinto "Banking";
}

provides a much bigger set of clues for spear phishing than any previous
examples given in this thread.

if address "from" "[e-mail]" {
  fileinto "stupidstuff";
}

is not something you want your boss to see.

if address :detail "pager" {
  redirect "[e-mail]";
}

creates a subaddress you probably don't want just anyone to use.

And on and on and on.

> > So it seems like the scripts
> > should be confidentiality protected in transit. I checked with Barry and he
> > said that there is no RFC that specifies if/when scripts should be
> > protected in
> > transit, and I understand that this document is probably not the right
> > place to
> > specify required behavior there, but I'd like to discuss (more with the ADs
> > than the authors) if there is some plan for specifying that behavior
> > somewhere.

> As I said when you checked with me, this is entirely out of scope for
> this document.  If someone should want to do an update to ManageSieve
> or some such, that'd be fine, but it's got nothing to do with this
> extension.

Indeed. It may even be out of scope of the core Sieve specifications, since
user preferences and addressbooks are even more likely to provide a basis
for unwelcome privacy intrusions. If this is going to be addressed in
an IETF specification it probably needs to be done in as general a way
as possible.

Address books in particular have been widely exploited; there's nothing
at all theoretical about the attack surface they present.

				Ned