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

From: Wei Chuang <[email-masked]>
Date: Sat, 9 Feb 2019 08:36:13 -0800

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 <[email-masked]>
Date: Wed, Feb 6, 2019 at 12:11 PM
Subject: [Bimi] New Version Notification for draft-blank-ietf-bimi-00.txt
To: <[email-masked]>

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

-- 
bimi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bimi

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 9 Feb 2019 16:52:51 +0000

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:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Wei Chuang <[email-masked]>
Date: Sat, 9 Feb 2019 11:05:12 -0800

It is intended to support privacy, though it is up to email providers and
clients to do the right thing.  It uses certificates that carry the logo
(and other identity information) and assert 3rd party validation without
interacting with another server.  Our intent is that these certificates are
meant to be fetched at delivery and stored by email provider for the
client, though such a fetch could be done by the client at use.  Along
those lines, for revocation checks, the guidelines requires that CAs to
provide CRLs though OCSPs are allowed.

-Wei

On Sat, Feb 9, 2019 at 8:53 AM Stephen Farrell <[email-masked]>
wrote:

> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-blank-ietf-bimi
> >
> >
> > Abstract:

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 9 Feb 2019 19:45:00 +0000

On 09/02/2019 19:05, Wei Chuang wrote:
> It is intended to support privacy, 

"In its most basic setup, a BIMI-capable MUA could retrieve that
 image file directly from the site specified in the BIMI record."

It could well be that if various actors all do the right thing,
that bimi might not be privacy invasive. If however, any of the
relevant actors aren't careful, this becomes a tracking device,
as per the quoted text above. There are enough of those in mail
bodies already and we shouldn't be standardising such tracking
schemes in headers IMO.

I see no merit in bimi myself, only downsides.

S.

> though it is up to email providers and

---

From: Wei Chuang <[email-masked]>
Date: Sat, 9 Feb 2019 13:54:30 -0800

> bodies already and we shouldn't be standardising such tracking

Privacy is something the IETF process can very much help with, by providing
constraints on the parts of the specification that impacts privacy that
would otherwise be overlooked or worse.  Take for instance the choice of
CRLs vs OCSPs.  Our initial starting point in the Authindicators working
group* was only requiring CRLs indeed due to privacy, and intentionally not
stating anything about OCSPs.  The CA that we were working with this added
as optional because it was something they already supported.  I don't think
they meant OCSP support to be privacy invasive in any form and since we had
our as required support for CRLs we were fine.  What the IETF process can
do is provide many additionally eyes on the specification, with a strong
interest in security and privacy.  Making privacy mandatory in the
specification is something that the IETF process can make sure happens.

* The Authindicators working group is an informal group of individuals and
companies in the space of email providers and authentication consultancy
that has been developing BIMI so far.  The intent now is to bring the BIMI
specification to IETF if possible for further feedback and standardization
work.

-Wei

> >>> the logo validation.  I also have a security justification document
> that
> >> I
> >>> but the current mechanisms are more approachable to larger
> organizations
> >> in
> >>> first world countries
> >>> Status:
> https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/