rength of
the glue. Alas, l= makes the glue weaker, rather than the originally
intended stronger (ie, survivable when transiting a mailing list.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dki
UA might also hide or mark the
portion of the message body that was not signed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
historical precedence in the IETF.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
n to claim some
responsibility for a message by associating the domain with the
message. "
RFC 6376: DomainKeys Identified Mail (DKIM) Signatures <#>
https://www.rfc-editor.org/rfc/rfc6376.html
<https://www.rfc-editor.org/rfc/rfc6376.html>
d/
--
Dave Crocker
Brandenburg Interne
On 5/10/2024 2:33 PM, Dave Crocker wrote:
On 5/10/2024 10:54 AM, Murray S. Kucherawy wrote:
* Prior to accepting any Standards Track document for development,
there must
be a commitment to implement the resulting proposed standard from at
least
two independent parties, as recorded on a related
On 5/19/2024 9:26 AM, Wei Chuang wrote:
Dave Crocker mentioned that there is a pathway to do a narrow update
to the RFC6376 as an individual submission. I agree that it is a good
idea as hopefully a narrow update can be done relatively quickly.
What I am suggesting is /first/ getting
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
On 2/6/2024 10:43 AM, John Levine wrote:
In this case, Dave's right.
Wow. Can't help yourself, can you? "In this case."
As ad hominems go, that was almost creative. But alas, it was offset by
being so thoroughly gratuitous.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
On 2/5/2024 5:50 PM, Dave Crocker wrote:
we'd see reductions in user understanding, awareness and resistance
abuse.
sigh. /increases /in user understanding, awareness and resistance abuse.
reductions in user clicking errors, or somesuch
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 2/5/2024 4:57 PM, Murray S. Kucherawy wrote:
Interesting. Is that online anywhere?
You mean, as in a recording? This was the early 1970s... So, no.
This seems to be related to the topic:
https://scholar.archive.org/work/k2udwjcwqndofj6mw3fnn5jiky
d/
--
Dave Crocker
Brandenburg
On 2/5/2024 2:08 PM, Jim Fenton wrote:
On 5 Feb 2024, at 14:02, Dave Crocker wrote:
On 2/5/2024 1:56 PM, Jim Fenton wrote:
And you will also provide citations to refereed research about what you just
asserted as well, yes?
Ahh, you want me to prove the negative. That's not exactly how
with by user training.
d/
(*) When someone talks about 'average' users, one has left off (at
least) half the user population...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim
security-related information.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
.
Since some miniscule portion of the user population might like to see
it, for whatever reason, it could make sense to make it available, but
not as a default.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
-- and inside each was a goto into the other. OMG. But
this code was clear, concise and easy to understand.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
.
Was that not sufficiently pragmatic? I can't tell, because again, you
ignored it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On 2/3/2024 12:11 PM, John Levine wrote:
It appears that Dave Crocker said:
Any DKIM signer or verifier already has a state machine looking for CR
and LF to do header or body canonicalization. When the state machine
runs into a bare CR or LF, it has to do something. The only options
On 2/3/2024 11:29 AM, Dave Crocker wrote:
DKIM is not a general message parsing engine
btw, one might imagine a parsing engine that mixes a number of
functions, such as general message parsing AND DKIM validation.
For such an engine, where a bare CR or bare LF might be illegal --
though
On 2/3/2024 10:32 AM, John R Levine wrote:
On Sat, 3 Feb 2024, Dave Crocker wrote:
Having a DKIM module check for one aspect of RFC5322 conformance
raises a need to make it a full RFC5322 compliance engine.
That's easy: no, it doesn't.
Any DKIM signer or verifier already has a state machine
It usually produces cleaner, simpler, clearer results.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
discipline.
It usually produces cleaner, simpler, clearer results.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
, of course.
Opinions differ.
The prohibition is not in DKIM. So the violation is not within DKIM.
And why should DKIM care?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim
the softest
criticisms...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
in the pipeline is supposed to do that, and all I
can do is screw things up.
This.
A 5322 processor gets to decide what is a valid message. That's not
DKIM's job. And DKIM has no inherent reason to care about CR or LF on
their own, as distinct from any other character on its own.
d/
--
Dave
different cases has an
academic purity to it, but has already been demonstrated to be
destructive in practical terms, because it creates confused discussion.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
On 1/18/2024 1:46 PM, Dave Crocker wrote:
The issue is not whether those broader concerns are... concerns. They
are. But the topic of DKIM Replay has to do with a scenario that is
affected by things like oversigning.
sigh. sorry. small, insignificant typo, merely flipping the sign bit
IM modules
support this capability.
However the abuse scenarios which are reduced or eliminatoversigning are
outside the scope of the recent abuse that is being called DKIM Replay.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@masto
-To is different. DKIM doesn't (and can't) cover that SMTP
command.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
DKIM Replay.
Could you provide an example?
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On 10/30/2023 12:44 PM, Steffen Nurpmeso wrote:
Dave Crocker wrote in
:
|On 10/29/2023 1:51 PM, Jan Dušátko wrote:
|> In my opinion, the verifiability of the place and time of origin needs
|> to be addressed, which is one of the reasons to use DKIM:
|
|While I think I unde
. That is fundamentally different than what your
text means.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
___
subject matter expertise and operational interest.
If there is enough interest and productivity there, then when the work
gets to a degree of maturity, pursuing enhancements and formal status,
via the IETF, will make sense.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
On 9/2/2023 7:29 AM, Jesse Thompson wrote:
On Tue, Aug 29, 2023, at 9:02 PM, Dave Crocker wrote:
DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators
and receivers opt in to use them. Both sides are necessary. So I'm
wondering about looking for something the furthers
asymmetric information both ways.
To the extent it can help the receiver, a hashed version of the address
might be useful without divulging too much ( though yes, I know that
approach can be problematic.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
now wondering
about the sending side providing more information to the receiver,
rather than just trying to detect and stop on their own.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing
On 8/30/2023 1:21 AM, Alessandro Vesely wrote:
On Wed 30/Aug/2023 07:35:08 +0200 Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker wrote:
Why not re-use the existing DKIM solution, just
On 8/29/2023 10:35 PM, Murray S. Kucherawy wrote:
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker wrote:
On 8/29/2023 7:46 PM, Grant Taylor wrote:
> On 8/29/23 9:02 PM, Dave Crocker wrote:
>
Rather than doing it in a header field, though, could it be done
simply with a n
On 8/29/2023 7:46 PM, Grant Taylor wrote:
On 8/29/23 9:02 PM, Dave Crocker wrote:
Why not re-use the existing DKIM solution, just with a different
domain / set of keys?
Because it does not provide the affirmative information that I am
postulating/guessing the originating platform can supply
e furthers the collaboration.
And the attacker can't bypass it, if the signature covers enough (or
all) of the message.
d/
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf
f outbound filtering are, among
major platforms. If it ain't already very high, yeah, seems like it
should be and that this is an added incentive why.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dk
coordination, to detect and deal with the attack. (it's not
difficult to imagine scattered retransmissions, over time, to hide
the coordination. Sort of a spread spectrum transmission style...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
On 8/16/2023 11:23 AM, Murray S. Kucherawy wrote:
For the record, the attribution here is wrong. That was Alessandro's
comment, not mine.
drat. sorry. the downside of trying to compress quoted text. this was
not a lossless compression...
d/
--
Dave Crocker
Brandenburg InternetWorking
it is
quite a bad thing to do.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
problem. I think we assumed that the
re-posting and re-delivery processes would entail enough control to stem
that particular tide.
Kinder, simpler days.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf
expected
to survive, although in practice it usually does. It typically creates
a new RCPT-TO without changing the message itself. Hence DKIM survives.
But this case is fundamentally different from classic MTA-MTA transfers.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
ove points is not only true but is
fundamental to the nature, design and intended use of DKIM. And
well-phrased, IMO.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf
, prevents intermediaries from improving MIME
interoperability).
MTAs that are doing MTA functions are not supposed to make changes to
the content and typically they don't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
__
a legitimate message.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
not effective.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
to note the
issue.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On 8/4/2023 11:57 AM, Jim Fenton wrote:
On 4 Aug 2023, at 11:53, Dave Crocker wrote:
On 8/4/2023 11:39 AM, Jim Fenton wrote:
I’m even less clear on draft-chuang-mailing-list-modifications. Does it have to
do with the currently chartered work
... it will help to hear specifics, rather than
and the historical basis for them?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
cument author, without providing
them any indication what criteria you are applying here or any detail
about why you think it not relevant.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim maili
On 8/4/2023 11:39 AM, Jim Fenton wrote:
concerns about creating a dependency on something experimental
I missed the details about a 'dependency'.
What is it that would be dependent and what is it it would be dependent on?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
to be lacking cohesive effort to
formulate serious technical and operational 'solutions' and the
community support to field them.
We need a lot more focus on the recruiting industry
support/participation and on formulating technical specifications that
will be used.
d/
--
Dave Crocker
Brandenburg
of the indirection. (Extra clicks cost usability.)
I suggest, instead, whatever spec is produced have a statement of the
problem. This is a relatively simple problem to explain. No doubt the
text will be drawn from this draft.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
wording changes.
I think casting it in those terms will likely be more useful and less
likely to conjur philosophical debates.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf
gement
to have existing users of Domainkeys move to using the (then)
newly-minted DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/li
. It is creation of a new protocol.
c/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
minem.
I am pretty sure there isn't one.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On 3/24/2023 6:45 AM, Dave Crocker wrote:
On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption.
Wei is merging 'mine' into his. (Note mine was done as a variant of
his.)
For folks new to IETF processes, it might be worth explaining
other hand, have some discussion of security-related
issues in a section identified for that topic, might be useful for
highlighting dangers or concerns.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dk
On 3/24/2023 6:42 AM, Laura Atkins wrote:
We currently have two problem statements to discuss for adoption.
Wei is merging 'mine' into his. (Note mine was done as a variant of his.)
I believe there will again be only one draft.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
the description.. Rather it is a separate topic.
There is a difference between describing the problem, versus describing
solutions.
The exercise was to describe the problem.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
On Wednesday, March 22, 2023 8:21:55 PM EDT Dave Crocker wrote:
The scenario is re-posting a message such that the original DKIM
signature remains valid.
Any other sort of re-posting does not qualify, under this definition.
So, for example, anything depending on 're-signing
on 're-signing' is not a DKIM Replay
Attack.
Yes?
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross
, it might help to have some general discussion of
operational issues, and broad strokes of current thinking about
solutions. But again, that's for extra credit.
It would, after all, be nice to move from PS discussions to, you know,
talk about remedy and maybe prevention paths.
d/
--
Dave
The reason that I think it would be useful in the problem statement is
that it would give a way to get people up to speed.
Both of the Problem Statement drafts have text relevant to the topic of
solution proposal.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker
-- between the two problem statement drafts?
Preferences? Disagreements? Suggested wording/content changes?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https
prevention/mitigation is isolated to the
last, brief section. Given that the document is likely to get wide
distribution, I think it might be helpful to have a small amount of
discussion that emphasizes that this topic will not be amenable to
trivial solution.
d/
--
Dave Crocker
Brandenburg
this problem is that it is difficult for receivers to differentiate
between legitimate forwarding flows and a DKIM Replay Attack.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim
and standards 101. Seems odd to be
rehashing something this basic, in a forum like this
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman
.
Prepping and packaging a message would likely be done a long way before
retry queuing happens.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman
of leigimate mail delivery attempts.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
at someone, somewhere might find useful, but with caveat emptor
warnings highlighted. But no, those are not technical specifications.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
, reliably
an accurately, that they are in the target market?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
iators can preserve or break things.
For example, one version of this is "what happens when there are
multiple signatures from different domains?" While I've heard some
discussion of real-world treatment of such cases, I haven't heard enough
to know what is normal or, for that matter, u
'intention' is distributed, given Mediators.
I also don't know what draft by Levine you are referring to.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.o
riginating service, then
it's clearly not Replay.
If it is from an Aliasing site, the receiver can quickly build up a
reputation for that site, to aid in determining replay or not.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@masto
to raise possibilities, and difficult to raise
good ones.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
community. This is in spite of constant efforts to correct the
(mis)practice.
So, when someone authorized to use an address, then its use is not spoofing.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf
or another technology is wonderful or the devil's work
should be entirely out of scope, IMO.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman
the potential for
replay. Having a reference to this fact makes sense to me.
It doesn't need more than a mention, at this point, I believe, which
makes the current quick, reference exactly the right text, IMO.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
to look for
something useful outside that space. but again, the goal should be
basic description, rather than attempt anything definitive.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
of the differences, could help
consideration of the ways to counteract replay.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
of /exactly/ the same message as was originally
sent.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
. (Remember that the specification says a failed
DKIM is the same as no DKIM present.)
d/
ps. this exchange nicely demonstrates the need to make sure the wg
documents on Replay are extremely clear and precise.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
/. Not the mere reuse of the signature, but the continued
validity of that signature, for the message being sent. A signature
that fails is not a replay attack.
d/
--
Dave Crocker
dcroc...@gmail.com
mast:@dcrocker@mastodon.social
408.329.0791
Volunteer, Silicon Valley Chapter
Information
the "and so on..."?
Sorry. I meant 3.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
How about "replay-resistant protocol"?
btw, it isn't clear that 'protocol' is what a solution will be. might
be. might not. might be purely operational conventions, for example.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
rather than later.
The others seem more like research topics.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
f a technical solution doesn't
explicitly deal with the technical details of that problem.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
constraint you mean. I was describing some
history. (I think the Thaler report supports that model) But it's not
typically a requirement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing
of work and
agreement. This makes the effort quite a lot riskier.
The fact that things are taking quite a few months doesn't help.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
suing.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
ect on how to handle results from an earlier
validation, but only later retrieval and use of the public key, I think.
So let's at least distinguish between post-delivery validation and
post-delivery use of an earlier validation.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast
pretty sure that's allowed here. At least sometimes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
assertions of fact -- since I was there, too,
it's not unreasonable for me to do that.
In spite of my making no reference to you, you somehow decided that I
was making a statement about what was in your brain.
For reasons that might be obvious by now, I'd never do that.
d/
--
Dave Crocker
on substance and not personality.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
1 - 100 of 1842 matches
Mail list logo
