[Bimi] Re: Possible security flaw in BIMI spec / interaction of BIMI-supporting MUA with non-BIMI-supporting MTA

[Taavi Eomäe <[e-mail]>]

On 10/05/2024 21:14, John C Klensin wrote:
> Or, if the intent is to
> continue to have implementations evolve (and not be fully
> interoperable or inter-trust across the Internet) until either
> convergence magically occurs or is determined outside the IETF, why
> is this effort being allowed to use IETF resources?

What resources are we talking about right now? It's also quite weird to 
suggest that the intent isn't to reach interoperability.

I personally struggle to see what seems to be the issue here with 
different parties conducting their experiments at implementing the 
current drafts in more controlled environments, such precautions have 
proven themselves necessary more than once. Testing before formalizing 
is a common practice? This is not an indicator that those parties want 
to keep their implementations somehow closed.

> I also see a third option, which is that the BIMIgroup is seeking
> free technical advice from people with longer and/or deeper email
> experience.  If that were the case, using the pretense of bringing
> work to the IETF to get it would be, to put it mildly, unfair and
> possibly even sleazy.

I'm fairly certain most of those group members have a bunch of know-how 
in-house already. I also can't say that there have been many active 
discussions here that would provide them with heaps of "free technical 
advice."


>>> [...] the likelihood of operational errors from the complexity as
>>> dramatically higher.
>> A lot of the issues BIMI has to solve are not due to BIMI itself,
>> BIMI just highlights how bad the situation (of identifying mail) is
>> in the wild. One of the first things BIMI demonstrated was how
>> utterly useless SPF really is nowadays (and even that is too hard
>> to implement for many), but that's certainly not all.
> But part of what you've been told (and which has been carefully
> explained several times) is that, for the purpose to which you want
> to put it and the inferences you want to draw, DKIM (with or without
> DMARC) is only slightly better than SPF.

Is your point here is that DKIM is not usable for identifying senders?


> adding a great deal of complexity
> --complexity reaching all the way to the MUA-- in an attempt to work
> around the issues.

I was speaking about the draft shared here earlier. I don't have an 
opinion on putting the burden on MUAs.


> There is good news and bad news about that.  The
> good news is that we have long-established protocols that permit
> identifying and verifying senders that work (if used) and that avoid
> all of the issues associated with changes to message headers and
> tampering with message bodies in transit.  They are called S/MIME and
> PGP / OpenPGP and work by authenticating both the sender and message
> body (encryption optional).

As a member of the CA/B Forum S/MIME Workgroup I am familiar with 
S/MIME, but BIMI tries to build upon existing approaches that have been 
deployed in a larger extent. A new S/MIME Baseline was adopted just 
recently, it would in theory take us a tiny step towards using S/MIME 
for similar purposes as BIMI/VMC. But this happened *after* the work on 
BIMI and VMC started. The S/MIME ecosystem is not mature enough for 
this, at least now. OpenPGP is even less so.

I would also in theory also like to see a combination of S/MIME and "VM" 
certificates considered, but that's even further away in the future and 
also not the topic here.


>> On 10/05/2024 15:51, Dave Crocker wrote:
>>> If there are multiple ways for this to happen, then either there
>>> is no  standard, or the standard is dramatically more complex and
>>> the  likelihood of operational errors from the complexity as
>>> dramatically  higher.
>> These implementations existed before that draft was where it is
>> now, and a bunch of improvements are still WIP. It's also fairly
>> expected that implementations evolve and change as long as things
>> aren't finalized.
> But that (as well as other comments below), takes us back to the
> important procedural question.  If this is intended to be IETF work,
> what is the plan for moving things in that direction so that
> decisions can be made and things finalized?

I'd certainly be interested to know any future directions as well. As 
there clearly have been recent attempts at making improvements and 
discussion happening, it's clear that there's willingness to cooperate. 
Though I wouldn't rush to making conclusions based on just such 
activities. At this point it shouldn't come as a surprise that making 
any changes related to email is not trivial, and any approaches taken 
have to be evaluated for quite a while before coming to conclusions.

When the current draft has gotten enough testing in real life, I'm sure 
(at least some) effort will be taken to move things toward.