I'm at about 1:10 in the audio, and the quoted are clips from the
transcribed audio. don't blame me for the quoted spelling errors :)
TL;DR: I still don't see anything that precludes this as a DKIM update.
* * *
> We need to have a signature per hop in order for this to work
What in this context is a "hop"? It would be nice to clarify whether
that means some larger aggregate or whether "hop" means every MTA that
inserts a Received header field.
Also: what is that "this"?: I'm guessing it's back scatter, but am not sure.
> They need to be ordered you need to know what order these were supposed
This is something I never understood from even the ARC days:
DKIM-Signature is a trace header. So is Authentication-Results for that
matter so I'm not sure what the value is in numbering them.
In any case, adding a new tag with a signature number could be backward
compatible with existing deployments because it would get ignored.
> So if we just put this in a decim signature header, we some extra
fields, there would be a ton of signatures that didn't validate most
particularly the signature of the original source that aligned with the
from address would not validate as soon as any changes were made
Why?
> I mean, but there's going to be a ton of decim signatures that just
don't validate on messages well there aren't
Again, why? Especially if the receiver knows whether it's base DKIM vs
upgraded DKIM via some explicit signaling with the tags from the sender?
If they are just unknown tags, it will verify and even if the receiver
is upgrade-savvy it would just look like a normal STD76 signature.
(also there was a comment in the chat that i= is already taken with
DKIM... well, tags are cheap so name it something else that's not taken).
> The big con is that it discourages people from upgrading to decim too
(at around 1:12:45)
Why? I honestly am having a really hard time following the overall
argument in this section.
Or am I off track because this is talking about the mutation stuff, not
the rationale for a new protocol?
> Which headers should be mandatory for signing?
There is already a list of mandatory headers that must be signed. As far
as oversigning, is that actually a problem in the field?
> so that you only list additional headers that are being signed rather
than all of them
This would be a breaking change, but it seems of pretty dubious
rationale. For all of the talk of cheap bandwidth, the cost of this is
pretty much nothing.
> And then there's the handling upgrade and this is a whole big open
question that I think will require quite a lot of discussion. My
original proposal a year something ago, which I don't know if it made it
even to an IETF draft that I was throwing around to a few people
suggested that you would check at SMTP layer or with a DNS query whether
the next hop supported decim two.
Why does a signer need to know this?
> if it has gone outside D Kim 2
I really don't understand the notion of in or out of the "ecosystem".
Why does this matter? There will be forwarders that never implement
this. Should I assume it will be bounced or something else drastic if
they don't?
> we should not leave it random as to which headers get signed I think
after the number of years we've had we ought as a community to have a
pretty good idea which headers should be signed and in particular
I'm pretty sure the point was made previously that we don't in fact know
the headers that should be signed. If the goal here is to just expand
the list of headers that DKIM requires, I don't think that is a breaking
change though.
> if it's not in an rSC then uh doesn't make it into the list but that
but most of the things which you now should be there and most people
would not want to put that in list in there because some of the heads
are so exotic that they've uh that it comes as a surprise even to email
experts that these headers even exist and i'll are described.
I'm not sure what the point of this is. Sure if we want to mandate more
headers to be signed, that's fine. But what exactly is it hurting to
sign headers that might not really need to be signed?
> However, if we are all going to be reading bodies in memory, in order
to do the algebra
re: Relaxed bodies
So we seem to be back to the efficiency argument which seems to be
bounce around between "CPU's are way faster now" and "we need to save
every single CPU cycle". The latter is, in my experience, not a very
persuasive argument because not even the cost of the RSA operations
which are relatively expensive, didn't turn out to be a very big deal
given all of the other processing that happens, and that was 20 years ago.
My personal take is that we should just dispense the notion that making
DKIM more efficient is a goal, especially since that's not even in the
charter.
> i think having two sets of code for dealing with this is we must have
learned something for the last few years, so let's learn those lessons
and then simplify the code
[re: relaxed vs simple bodies]
Huh? The code is already available and has been available for 20 years.
This is a tiny, tiny optimization of dubious value, imo.
I believe Murray asked a question about whether the mutations would be
done against the canonical text or not. It seems to me that is
plausible, but I haven't read the mutations draft close enough to know
whether it might contain some gotchas.
* * *
I should say that I've asked many of these questions before... it would
be nice to get a response.
But if you're still in Bangkok, catch a game of chess for me and have fun.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
