Subject: [Bimi] comments sections 1-4 re: draft-brotman-ietf-bimi-guidance-00

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

Thanks to Alex and Terry for efforts to get this first draft together.  

Comments: 

* Title: currently says "Branded Indicators for Message Identifcation" - suggest we unify the expasion of the acronym to "Brand Indicators..."  (Brand not Branded) - matches "draft-blank" 

* Introduction: 
  * First sentence.  Change wording when mentioning DMARC to decouple the logo fetching of BIMI from DMARC or other crypto methods.  The way it is written suggests that DMARC is required (in addition crypto methods), when in fact DMARC-improved SPF and DKIM are examples of ways for receivers to assess authentic identity, and they are not actually required by the BIMI spec.  Practically of course, they will be required.  

Suggest instead we say BIMI enable distribution of identity logos; then mention that given that showing logos without using reliable (but separate) established authentication tech would be an invitation to fraud, say that something for authentication must be in place.  Maybe "BIMI does not require any specific authentication technology; however, given that BIMI-sourced logos can and are intended to be used to represent sender identity, a reliable and sufficent means of verifying identity is very important" 

* add langauge in the introduction to describe what is in the document.  "This document assumes that some receivers will want to implement BIMI.  The purpose of this document is to highlight challenges, discuss best practices, and give consideration to the complex task of supporting it in practice and at scale.  "  (not married to this language, but this is the gist) 

* Overall, the intro should probably have these elements at the high level: 
  * what is BIMI in two sentences, and a reference to the Assertion Record spec
  * what the purpose of this document is, how it relate to BIMI 
  * recap the major sections and their content 

* Section 2: Goals for BIMI.  This is good background material, though I wonder if it should either be moved to the Assertion Record spec intro material.  Overall, a question to the group is - where in the set of IETF docs is languge of this nature go (motivations, anticipated beneficial side effects, etc).  Can we / should we consolidate this material, or should we sprinkle a well-honed rendition in each of the docs?  

Secetion 3.1 Sentence 2, beginning with BIMI, restates the value prop and says BIMI requires DMARC.  Probably should be removed.  

To the question of "If your site satisfies the requirements, this is likely a yes" - should we have some basic yes/no questions here, both 'requirements' and or pre-existing features of a receiver platform?  Examples: 

" 
* does your email platform today have a UI that shows attached images or renders those in HTML-based email? 
* Do you have or want to support users reading their email from a mobile email app?  
* Do you currently have support for one or more email authentication standards, such as SPF, DKIM, or S/MIME?  
* Do you support DMARC-based identity evaluation and reporting? 

If you answered yes to these, or you are planning to soon, you already have much of what is needed, and your end users are used to seeing graphical identities today"  

Suggest Terminology goes into its own section; right now it looks like it is in Section 3 (might be a typo)? 

Section 4: Site implementation.  First sentence as it is ("In order for a site to correctly implement BIMI, the receiver must be
   able to perform the following: " seems to imply that SPF, DKIM, and DMARC are all required.  Maybe we again say "pick the authetication technology you feel good about, provided that it is sufficient".  Then we say, "most receivers already support SPF, DKIM, DMARC, S/MIME". If you are using these, then here's here's what you systems would perform ... blah blah blah.  

Here's a stab at the first "As decribed in [Assertion Record Spec] BIMI-based logos are published via a purpose-specific DNS TXT record in direct association with the publisher's DNS domain name.  Implementors should be prepared to verify the authenticity of a message's sender, at least at the level/specificity of the DNS domain level.  This enables the recommended practice of only showing BIMI-obtained logos when the identity of the sender can be reasonably assured.  Existing technologies such as DKIM and SPF are good potential choices, particularly if your platform already supports their use.  "  

Maybe 'publisher' in the above should be MAE, for Mark Asserting Entity, and we'll want this in the glossary.  

For the bullet on IMAP, suggest we shorten the bullet for the list, then pull the addtional explantion to a second para below.  Then have a forward reference to a future IMAP doc?  

Another thought - should we have a protocol mention-free overview of the steps, in the context of a message?  E.G.: 

1) receive message
2) confirm authenticity of sender's identity (obtain authenticated DNS domain name) 
3) obtain BIMI-published logo 
4) perform validation/authenticity of published logo 
5) optionally signal to mail store
5) arrange for the display of logo in visual association with orginal message in the UI

Perhaps after, go on to the specific protocols matching these steps?  

General questions: 

1) Have a separate glossary in this doc, or leverage one in [Assertion Record Spec]?  

2) Do we have enough of an IMAP doc to also make it an Internet Draft?  Would be a great way to engage the IETF IMAP people.  

Thede

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