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

[Alissa Cooper <[e-mail]>]

Hi Stephan, 

Thanks for your responses. My responses to some issues are below and the
rest are in my other note to Barry.

On 6/20/14, 12:51 AM, "Stephan Bosch" <[e-mail]> wrote:

>Hi Alissa,
>
>On 6/20/2014 2:40 AM, Alissa Cooper wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-appsawg-sieve-duplicate-07: Discuss
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> o Section 3.3: 
>> "A default expiration time of around 7 days is usually
>>    appropriate. ... If that limit is exceeded by the ":seconds"
>>argument,
>> the
>>    maximum value MUST silently be substituted"
>>
>> The suggested default seems really long, especially for the example use
>> case described in Section 1. On the other hand, it seems odd that the
>> user's choice would be overriden by the preset maximum. This would make
>> more sense to me if the default expiration were shorter and the user
>> could override it with a longer :seconds argument if he wanted. What is
>> the rationale for doing it the opposite way?
>
>The default was chosen in Sieve mailing list discussions, but in essence
>it is pretty arbitrary. It is mainly based on the period in which a
>series of duplicate messages may arrive with a margin of a few more days.

I find it a bit surprising that receipt of a duplicate multiple days after
the first message is received is that commonplace on today’s Internet. Is
there any data around to back that up?

>
>The rationale for a maximum is to prevent users from having the ability
>to create duplicate tracking list entries that linger indefinitely.

Well, “indefinitely” wouldn’t necessarily be possible, because if the user
specifies nothing then it’s the default, and otherwise he could be
required to specify _something_, correct? But I can appreciate that you
don’t want to impose a long, arbitrary retention requirement. Is the idea
that the maximum would be surfaced to the user if he’s using some GUI to
create a duplicate filter? It just seems odd that the user’s choice would
be silently overridden and he wouldn’t know until duplicate messages start
showing up sooner than expected.

Alissa

>
>> o Section 6: 
>> It seems like this section is missing a discussion of the privacy
>> considerations associated with enabling the duplicate test. In the case
>> where the Sieve filter is implemented server side, making use of the
>> duplicate test means that some record of the receipt of a particular
>> message will be persisted (for as long as specified by the logic in
>> Section 3.3) even if the user downloads his messages or deletes a
>> received message on the server that matches a test string in the
>> meantime. If I want to filter all messages with duplicate message IDs,
>> for example, this puts a
>> requirement on the server to maintain a list of the message IDs of all
>> messages I’ve received (for the amount of time specified by the timing
>> parameters). So if a third party wanted to find out that list, it could
>> go to the operator
>> of the server and ask for it. This introduces a privacy risk that is not
>> discussed in the document and is exacerbated by the long default
>> expiration time mentioned above. Tests that make use of the :header or
>> :uniqueid arguments are also potentially problematic since the list of
>> strings to match is kept on the server. It seems like these aspects
>> should at least be noted in the document for implementers to consider.
>>
>> o Section 6: 
>> Sieve scripts that include duplicate tests contain potentially sensitive
>> information (e.g., subject or body strings). 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.
>>
>> o Section 6: 
>> I think it would make sense to require that the tracked message list be
>> stored with an equivalent level of protection as the user's messages
>> themselves. E.g., if message headers and bodies are stored encrypted,
>> then the duplicate tracking list should be as well. And the duplicate
>> tracking list should be subject to the same access controls as the
>> mailbox (perhaps this is obvious but I'm not sure).
>
>This is a very interesting point of view. I had not thought of privacy
>concerns relating to the duplicate tracking list.
>
>Probably, the main reason we have not considered this is that the
>document states the following:
>
>   NOTE: The necessary mechanism to track duplicate messages is very
>   similar to the mechanism that is needed for tracking duplicate
>   responses for the "vacation" [VACATION
><http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-07#ref-VACA
>TION>] action. One way to implement
>   the necessary mechanism for the "duplicate" test is therefore to
>   store a hash of the tracked unique ID and, if provided, the ":handle"
>   argument.
>
>There is no tractable way to reverse a hash into its original string
>value, meaning that the entries in the duplicate tracking list would
>have very little value for an attacker.
>
>Of course, if implementations choose a different approach that uses
>entries that can yield the original string values, there would be a real
>concern. I propose adding a sentence or two pointing out that duplicate
>tracking list entries should not contain the plain user strings for
>privacy reasons, or, alternatively, that the tracked message list be
>stored with an equivalent level of protection as the user's messages
>themselves.
>
>The same considerations apply to the vacation extension (RFC 5230).
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> o Section 3.1:
>> "When the ":uniqueid" argument is used, such normalization
>>    concerns are the responsibility of the user."
>>
>> I don't quite get this. Do we expect users to, e.g., specify that
>> uniqueid strings should only be compared after conversion to UTF-8? That
>> would seem to rely on a level of technical sophistication that almost no
>> users actually have.
>
>I am not sure what exactly you mean here. The normalization concerns
>listed before that sentence all apply to header field content, something
>the author of a sieve script cannot control directly. With ":uniqueid"
>the script author is directly responsible for the composition of the
>unique ID value. As long as the encoding is chosen consistently, the
>encoding does not matter for successfully matching it to past values in
>the duplicate tracking list. It can also be some sort of binary value if
>appropriate; whatever the application demands. The quoted sentence
>mainly points to the fact that for some applications it can be useful to
>have such normalization for ":uniqueid" as well, e.g. to trim leading
>and trailing white space. However, the script author will have to
>implement this explicitly, since the duplicate test will not do this
>implicitly.
>
>> o Section 3.2:
>> "This means that it does not matter whether values are
>>     obtained from the message ID header, from an arbitrary header
>>     specified using the ":header" argument or explicitly from the
>>     ":uniqueid" argument.
>>
>> I had trouble understanding what "it does not matter" meant in this
>> sentence. I would suggest:
>>
>> "This means that the values in the duplicate list should be used for
>> duplicate testing regardless of whether they were
>>    obtained from the message ID header, from an arbitrary header
>>    specified using the ":header" argument or explicitly from the
>>    ":uniqueid" argument."
>
>Ok, works for me.
>
>Regards,
>
>Stephan.