Re: [lamps] Fwd: [Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt

[Stephen Farrell <[e-mail]>]

On 09/02/2019 19:05, Wei Chuang wrote:
> It is intended to support privacy, 

"In its most basic setup, a BIMI-capable MUA could retrieve that
 image file directly from the site specified in the BIMI record."

It could well be that if various actors all do the right thing,
that bimi might not be privacy invasive. If however, any of the
relevant actors aren't careful, this becomes a tracking device,
as per the quoted text above. There are enough of those in mail
bodies already and we shouldn't be standardising such tracking
schemes in headers IMO.

I see no merit in bimi myself, only downsides.

S.


> though it is up to email providers and
> clients to do the right thing.  It uses certificates that carry the logo
> (and other identity information) and assert 3rd party validation without
> interacting with another server.  Our intent is that these certificates are
> meant to be fetched at delivery and stored by email provider for the
> client, though such a fetch could be done by the client at use.  Along
> those lines, for revocation checks, the guidelines requires that CAs to
> provide CRLs though OCSPs are allowed.
> 
> -Wei
> 
> On Sat, Feb 9, 2019 at 8:53 AM Stephen Farrell <[e-mail]>
> wrote:
> 
>>
>> I've not yet subscribed to that bimi list but...
>>
>> As a user of email I do not want more crap in messages that
>> user agents might de-reference thereby increasing how much
>> I am tracked and my devices' attack surfaces. So my starting
>> position is that I need to be convinced bimi is not just a
>> bad idea.
>>
>> S.
>>
>> On 09/02/2019 16:36, Wei Chuang wrote:
>>> Hi all,
>>>
>>> I'm cross posting to the LAMPS mailing list for visibility, that there
>> is a
>>> new mailing list for Brand Indicators for Message Identification (BIMI)
>>> which allows for logos to be displayed by an email recipient. This is of
>>> interest to LAMPS since a secured part of the specification uses
>> X.509/PKIX
>>> certificates to carry these logos and assert a 3rd party validation.  A
>>> while back, I posted here a draft requesting a new certificate Extended
>> Key
>>> Usage value to distinguish these logo carrying certificate which linked
>>> below.  Also described below is the validation procedure for the
>>> certificate based on web Extended Validation (EV) but built upon to
>> handle
>>> the logo validation.  I also have a security justification document that
>> I
>>> hope to turn into an IETF informational draft that will help justify the
>>> security of the logo and other information carried in the certificate.
>> We
>>> look forward to your comments and questions on the BIMI list.
>>> https://www.ietf.org/mailman/listinfo/bimi
>>>
>>> -Wei
>>>
>>> ---------- Forwarded message ---------
>>> From: Seth Blank <[e-mail]>
>>> Date: Wed, Feb 6, 2019 at 12:11 PM
>>> Subject: [Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt
>>> To: <[e-mail]>
>>>
>>>
>>> I've uploaded two documents as I-Ds to kick off IETF discussions around
>>> BIMI. Both these documents need a good deal of work, but are ready for
>>> public discussion.
>>>
>>> For BIMI publishing and usage:
>>> - https://tools.ietf.org/html/draft-blank-ietf-bimi-00
>>> - https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-00
>>>
>>> For logo validation:
>>> - https://tools.ietf.org/html/draft-chuang-bimi-certificate-00
>>> -
>>>
>> https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing
>>>
>>> At a high level, these documents have several issues to be worked
>> through:
>>>
>>> 1) The intent is for this to be globally accessible to any domain owner,
>>> but the current mechanisms are more approachable to larger organizations
>> in
>>> first world countries
>>>    a) We need a discussion of what other validation mechanisms could work
>>> at scale (our expectation is to have several, signposted weakly in the
>>> draft)
>>>    b) We need a way to properly reflect this in the proposed a= tag
>>>
>>> 2) BIMI is NOT a new authentication mechanism, nor does it make ANY
>> claims
>>> about user security or trust in the inbox. However, in places this draft
>>> may be unclear. How do we make this clearer while still explaining why
>>> standardizing this process is important, without crossing the line into
>> UX
>>> or trust, of which BIMI is neither?
>>>
>>> 3) Right now, security surrounding logos is limited to SVGs per
>>> https://tools.ietf.org/html/rfc6170#section-5.2. There's clearly more
>>> that's needed here, especially against attacks that rely on steganography
>>> or resizing vectors, etc.
>>>
>>> 4) Other nits for draft-blank-ietf-bimi:
>>>
>>>    a) The structure needs work, as do the Introduction and Overview
>>>    b) Some of the technical construction feels like it could be
>>> dramatically simplified
>>>    c) Section 8.2 mentions hashes with no definition or clarity
>>>    d) The uses of MTA, MUA, and Mail Receiver feel like they overlap each
>>> other left and right
>>>        i) And the document is heavily focused on larger receivers where
>>> this distinction is clear, but doesn't give any thought to other
>> receiving
>>> architectures at all, especially mail clients that are the entire stack
>>>
>>> Several authors of these documents will be in Prague, we're looking
>> forward
>>> to the conversations over the next few weeks and face to face!
>>>
>>> Seth
>>>
>>> ---------- Forwarded message ---------
>>> From: <[e-mail]>
>>> Date: Wed, Feb 6, 2019 at 11:11 AM
>>> Subject: New Version Notification for draft-blank-ietf-bimi-00.txt
>>>
>>>
>>> A new version of I-D, draft-blank-ietf-bimi-00.txt
>>> has been successfully submitted by Seth Blank and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-blank-ietf-bimi
>>> Revision:       00
>>> Title:          Brand Indicators for Message Identification (BIMI)
>>> Document date:  2019-02-06
>>> Group:          Individual Submission
>>> Pages:          26
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/
>>> Htmlized:       https://tools.ietf.org/html/draft-blank-ietf-bimi-00
>>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi
>>>
>>>
>>> Abstract:
>>>    Brand Indicators for Message Identification (BIMI) permits Domain
>>>    Owners to coordinate with Mail User Agents (MUAs) to display brand-
>>>    specific Indicators next to properly authenticated messages.  There
>>>    are two aspects of BIMI coordination: a scalable mechanism for Domain
>>>    Owners to publish their desired indicators, and a mechanism for Mail
>>>    Transfer Agents (MTAs) to verify the authenticity of the indicator.
>>>    This document specifies how Domain Owners communicate their desired
>>>    indicators through the BIMI assertion record in DNS and how that
>>>    record is to be handled by MTAs and MUAs.  The domain verification
>>>    mechanism and extensions for other mail protocols (IMAP, etc.) are
>>>    specified in separate documents.  MUAs and mail-receiving
>>>    organizations are free to define their own policies for indicator
>>>    display that makes use or not of BIMI data as they see fit.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spasm
>>>
>>
> 
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>