[Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt

[Seth Blank <[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