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

[Stephen Farrell <[e-mail]>]

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
>