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

From: Seth Blank <[email-masked]>
Date: Wed, 6 Feb 2019 12:10:35 -0800

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: <[email-masked]>
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

---

From: Thede Loder <[email-masked]>
Date: Thu, 7 Feb 2019 15:48:39 -0500

Seth, thanks for getting this rolling here!  I will post comments on specific docs under different doc-specific threads where possible and suggest others do the same.  Generally agree on the highlights - lots to cover and improve. 

Thede

--
Thede Loder
Managing Director, Skye Logicworks LLC
E: [email-masked]
M: 415-420-8615

> On Feb 6, 2019, at 15:10, Seth Blank <[email-masked]> wrote:
> 
> 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.
> 
> - https://tools.ietf.org/html/draft-blank-ietf-bimi-00 <https://tools.ietf.org/html/draft-blank-ietf-bimi-00>
> - https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-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://tools.ietf.org/html/draft-chuang-bimi-certificate-00>
> - https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing <https://docs.google.com/document/d/10IzxkdrveDazBAvTvOUa9uCIDBwMkdmluwHEcbja42w/edit?usp=sharing>
> 
> 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)
> 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 <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.
> 
>    b) Some of the technical construction feels like it could be dramatically simplified
>    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
> 
> From: <[email-masked] <mailto:[email-masked]>>
> URL:            https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt <https://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/ <https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/>
> Htmlized:       https://tools.ietf.org/html/draft-blank-ietf-bimi-00 <https://tools.ietf.org/html/draft-blank-ietf-bimi-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi <https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> -- 
> bimi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bimi