Subject: [art] Alissa Cooper's No Objection on draft-ietf-appsawg-mdn-3798bis-15: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 30 Nov 2016 07:22:44 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-appsawg-mdn-3798bis-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the good work to improve the privacy properties here.

= Section 6.2 =

"Disposition mode (Section 3.2.6.1) can leak information about
   recipient's MUA configuration, in particular whether MDNs are
   acknowledged manually or automatically.  If this is a concern, MUAs
   can return "manual-action/MDN-sent-manually" disposition mode in
   generated MDNs."

I see why this is here, but doesn't recommending falsifying these fields
put their integrity in question whenever they are set to manual? I mean,
why would recipients trust this information if the RFC actually suggests
sending a field that lies about an MDN being automatically acknowledged?

= Section 6.2.2 =

"The "Reporting-UA" field (Section 3.2.1) might contain enough
   information to uniquely identify a specific device, usually when
   combined with other characteristics, particularly if the user agent
   sends excessive details about the user's system or extensions.
   However, the source of unique information that is least expected by
   users is proactive negotiation, including the Accept-Language header
   fields."

I think the use of "However" is tripping me up here. Earlier in the
document you have good recommendations about how to mitigate the risk of
fingerprinting based on the Reporting-UA field. That guidance is valid
regardless of whether other header fields might also contribute to
fingerprinting or whether users would expect that (frankly, I don't see
how user expectations are relevant here, since most users don't
understand fingerprinting anyway). I think something along the following
lines to replace the last sentence above would be more accurate: "Even
when the guidance in Section 3.2.1 is followed to avoid fingerprinting,
other sources of unique information may still be present, including the
Accept-Language header fields."

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Nov 2016 11:34:16 -0500

> sending a field that lies about an MDN being automatically acknowledged?

This comes from my pushing on the point, and is the only reasonable
mediation we could come up with.  Here's the summary of the
discussion:

- I don't see any use in having this field at all.  There's nothing
useful the MDN recipient's mail system can do with it, and it only
serves to expose information about the MDN sender's configuration
unnecessarily.  I'd rather see it removed entirely.

- That said, it's been required from the beginning, so (1) all
existing implementations send it, (2) existing implementations expect
to receive it, and are likely to consider the MDN invalid if it's not
present, and (3) implementations are not expected to be reworked to
match this spec if we should change that now.

- Because of (2) above, we can't just recommend not sending it.
Further, the field wasn't designed to be extensible, so we can't use
some value such as "unknown" -- that would most likely have the same
effect as in (2), that implementations would consider those to be
invalid MDNs.

- The only thing that leaves is recommending a "standard" value to
send if you don't want to expose the real information.  That value has
to be one of the two defined values, and "manual" is the less bad
option (as opposed to telling the recipient's system that you're
configured to automatically send MDNs).

- And because of the first bullet above (that there's nothing useful
to be done with this information anyway), lying about it doesn't hurt
anything.

It's a bad, but usable solution to an unfortunate problem.

Barry

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 30 Nov 2016 13:03:04 -0500

> On Nov 30, 2016, at 11:34 AM, Barry Leiba <[email-masked]> wrote:
> 
>> = Section 6.2 =
>> 

Got it, thanks for the explanation.

Alissa