Re: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00

["Brotman, Alexander" <[e-mail]>]

I'm going to put aside the word-smithing from this and your prior message for the moment.  I agree with most of them, and I'll get those changes incorporated.

As for the reliance on DMARC, contained within section 2 of [draft-blank-ietf-bimi-00]:

   2.  Then, for any message received by a Mail Receiver:

       a.  Receivers authenticate the messages using [DMARC] and
       whatever other authentication mechanisms they wish to apply.

       b.  The receiver queries the DNS for a corresponding BIMI record
       and proof of indicator validation.

       c.  If both the email and the logo authenticate, then the
       receiver adds a header to the message, which can be used by the
       MUA to determine the Domain Owner's preferred brand indicator.

That, to me, indicates a dependency on DMARC and its associated mechanisms, but does not limit authentication to solely DMARC, allowing for additional methods.  Also, note 8.3 which seems to indicate the same.  This seems to be related to the majority of your comments.  If this is not the case, we'll need to reword both drafts appropriately.  If that is the case, I'll get to work with the other rewordings you've suggested (and I assume you'll have more for the rest of the document on the way).

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

-----Original Message-----
From: bimi <[e-mail]> On Behalf Of Thede Loder
Sent: Friday, February 8, 2019 4:08 PM
To: [e-mail]
Subject: [Bimi] Sec. 5-6 draft-brotman-ietf-bimi-guidance-00


Hi all, 

Here are some comments, ideas, concerns for draft-brotman, Sections 5-6: 

Overall: 
======

* A key "theme" for the document should be to underscore/highlight that assuring authenticity of a message sender's identity and the authenticity of corresponding BIMI-sourced logos is paramount for a receiver's safe implementation and support of BIMI-based logo display.  Ensuring that the outcomes from analysis reach the MUA in some usable way is a big part of what a receiver will have to do

* illustrate/recommend procedures a receiver can undertake to reach a reasonable level of assurance that messages are authentic, and include both general guidelines that are standard-independent and specific examples that are standard-specific (to "make it real" to people who will natually think about concrete examples of the technology.  E.g. SPF, DKIM, S/MIME)  

* I do not believe it is right to say that DMARC is required; authentication of messages should be a receiver's choice.  Currently the draft says DMARC is required in several places.  


Comments by sections. 
=======

Recomend we change the title of section 5.  Possible new one: "Assuring Sufficient Authenticity of Messages".  

Suggest spliting the contents of 5.1, as it seems to fit into two buckets: 
1) minimum recommended procedures and requirements and 
2) optional, additional requirements (content here is already good and can be extended).  

Might be best to merge in some of the content from the previous section 4. 

So, 5.1 "Minimum Recommend Requirements" 
and 5.2 "Additional Requirements for Consideration" 

on existing content: 

Section 5.1 First sentence: " In the BIMI specification, a message MUST be authenticated via DMARC."  We should probably  strike or re-word, unless we intend to have BIMI require DMARC.  In reality for receiver organizations and readers of this ID, "aligned SPF" and "aligned DKIM" are the only games in town, unless there's support for S/MIME.  But we should welcome alternative methods as they are developed, provided they are up to the task. 

Maybe the intro to the section says that "authenticity should be sufficiently confirmed, and should pass a security review with a receiver's experts.  For many mature email receiving platforms, passing DMARC-compliant authenticity checks might be considered as sufficient.  However, it is there responsibility of the receiver / email platform operator to weigh the risks involved, and ensure that authenticity can be assured at appropriate levels.  Assuming that aligned-SPF or aligned-DKIM analysis, suffient to pass DMARC authentication are sufficient, the following example illustrates the steps involved..." 


The passage: 

"Upon receipt of an email, a receiver that implements BIMI should
   remove or rename any previously existing BIMI-* headers other than
   BIMI-Selector, as they may have come from an attacker (as long as the
   BIMI-Selector is covered by the DKIM signature; if not, it should be
   removed, renamed, or ignored)." 

.... is a little awkward around when to remove and inclusion of the selector in the signature.  Here's a reworded version: 

"Upon receipt of an email, a receiver that implements BIMI should remove (strip out) any and all BIMI-* headers, as they may have come from an attacker.  The exception to this is the "BIMI-Selector" field which should be retained if and only if it is included within a valid DKIM signature having i=domain aligned with the message's From Header Domain".  


For this bullet (end of section 5): 

"It is useful for a site that has not implemented BIMI to remove
      those headers so that an MUA that does make use of those headers
      would not accidentally display a BIMI image when the message has
      not been properly authenticated by the email receiver (even though
      an MUA should not make use of BIMI headers and instead rely upon
      settings from the mailstore, it is possible that some MUAs will
      nevertheless use headers without taking appropriate precautions)."  

We could in theory put this into a new section which contains recommendations for MTAs, receivers, and relays which do not directly support the display of BIMI logos on their own platforms, but do relay email after verifying and confirming authenticity.  Not clear anyone would want to take on 'partial' support in this way, but maybe some will.  

For the current Section 5.2, what we might say here is (outline)

* it's important to verify authenticity of BIMI-sourced logos, just as it is to assess the authenticity of corresponding messages
* receivers should consider support for multiple methods (depending upon what is outlined in the Assertion Record Spec, if we extend the a= tag beyond pointing to a VM Cert), 
* Verified Mark Certificates are an option [forward reference to VMC documents] of assuring a logo is authentically attributable to a domain registrant

and we need to change the name from BIMI Certificates to Verified Mark Certificates where references appear.  


Section 6: 

This section could benefit from some introductory language to set the context.  How about: 

"There are a variety of architectures receivers have implemented and these determine the path messages take once received by their gateway MTAs and how they are made available to an MUA.  For strategies which entail assessments of authenticity of messages and or BIMI-sourced logos ahead of placement in a mailbox (expected to be commonplace), receivers will need to consider how MUAs can be passed explicit assurances that a receiver performed checks and the results of those checks.  Further, the "mailbox access protocol" (examples IMAP or JMAP) may need to be utilized used to convey them.  It is assumed here that MUAs will rarely be tasked with performing all or even a subset of the recommended steps involved, and so effective means of coordination is required "upstream" of the MUA in the mail flow. " 

It is expected that the burden of analysis and role of recommending to the MUA that it show a BIMI logo (or not) for a specific message is on the receiver infrastructure.  This approach has the benefit of reducing the implementation burden for MUAs, likely to facilitate adoption of support"  

One recommended way for receivers to communicate to the MUAs is as follows: ..." 


Section 6.1: 
Maybe we specifically mention the l=tag and the a=tag as sources of logo media? 

And, possible lead in for the caching strategy suggestion: 

"to eliminate unnecessary costs of a fetch-and-validate-per-individual-message strategy, receivers should consider caching authenticated BIMI-sourced logos in ways where they can be redistributed safely within their infrastructure as needed and retrived by the associated domain or domains on demand"  

While email message bodies could in principle be amended to embed a BIMI-sourced logo, receivers can make use of the "BIMI-Location" header to enable supporting MTAs to obtain the logo media from a protected location"  


Section 6.3.  
Layout nit.  Looks like there's a formatting problem after the first sentence.  Is the next sentence in a new paragraph, or the same as the first? 

This section 6.3 is pretty important - me wonders if we should also copy it or re-cap it in the BIMI Assertion Record spec?  

Content wise, a consideration and implication of CT logging associated with Verified Mark Certificates is that receivers can obtain a copy of each cert (and associated set of FQDNs) directly from the CT logs.  It may be a common strategy for larger platforms to run a duplicate log locally.  This would prevent disclosure to senders (and surveilance advertising systems) through monitoring of DNS queries related to the logo fetching.  

Another thought: how many selectors per domain or subdomain should a receiver be prepared to support?  If it's 50 or less, information disclosure through the DNS query channel or l=tag value is going to be much less of an issue.  


What's the best relationship/setup between the content in Section 4 and that in Section 6.4 - can they be unified?  This on-the-fly example is really at the heart of the matter - and is good material for FAQ / intro to BIMI overall.  

Re: 6.4 bullet one.  We might want to mention the term 'root program' in reference to the activity of obtain certs and vetting cert issuers, e.g. MVAs/CAs.  

The mail servers are unlikely to be where the set of trusted root keys live; instead, receivers will want to have a 'centralized' Verified Mark Certificate vetting system, and the MTAs and or Mailstore will want to call out to it once authenticity of a message is established.  The query would bascially say: "I have an authentic message from example.com; do we have in our repository a VM Cert and logo for example.com from a CA we trust?  (If so, I'll set a flag on this message for MUA or mailstore consumption/use so that the MUA can fetch the trusted logo at the right time)"   


Overall, there's a heap of great material in the document as it is, and this doc 'pulls it all together'  - again big thanks to Alex and Terry!  

Thede


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



-- 
bimi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bimi