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

[Wei Chuang <[e-mail]>]

On Sat, Feb 9, 2019 at 11:45 AM Stephen Farrell <[e-mail]>
wrote:

>
>
> 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.
>

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

I see no merit in bimi myself, only downsides.
>
> S.
>
>
> > 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 <
> [e-mail]>
> > wrote:
> >
> >>
> >> 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:
> >>> 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 <[e-mail]>
> >>> Date: Wed, Feb 6, 2019 at 12:11 PM
> >>> Subject: [Bimi] New Version Notification for
> draft-blank-ietf-bimi-00.txt
> >>> To: <[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
> >>>
> >>>
> >>> _______________________________________________
> >>> Spasm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/spasm
> >>>
> >>
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
> >
>