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
on
the dkim wg mailing list.
and, again, there is nothing in the specification work that reflects a
desire to have the signature validate long after delivery.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf
amental.
I don't recall seeing a similar comparison between DKIM and IIM.
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 12/9/2022 4:13 PM, Dave Crocker wrote:
DKIM's motivation was (and is) to create a noise-free channel, by
reliably associating an accurate identifier to a message stream. This
permits a receiver to evaluate the messages in that stream, without
concern that it has been polluting by other
., rather than ._dkim. is just a
coincidence?
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
implementation, I would suggest you not tell me what was in my
head at the time.
You appear to be telling your self to stop with the ad hominem references.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
tantiating material?
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
there was the first, direct effort to bring
things to the IETF.
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
ent effort. There is nothing in DKIM's development that
was intended -- nor do I recall discussion -- for post-delivery
forensics or non-repudiation. And article I cited, as well as the
replay problem, demonstrate basic problems with such a use of it.
d/
--
Dave Crocker
Brandenburg InternetWorkin
al current use, I doubt even that.
Frankly, the word transit was included to get an essential point,
without otherwise trying to tweak the wg work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dk
e.
More to the current point, if the anti-replay work to be done benefits
from a position on transit vs. non-transit, then including it directly
in an anti-replay specification would be more helpful than in a separate AS.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 12/4/2022 7:52 PM, Murray S. Kucherawy wrote:
On Sat, Dec 3, 2022 at 12:20 PM Jon Callas wrote:
> On Dec 3, 2022, at 11:42, Dave Crocker wrote:
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight"
ity' as a technical term meant as a specific
reference...
--
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 12/2/2022 10:38 PM, Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in
the datatracker:
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim
On 11/28/2022 2:40 AM, Laura Atkins wrote:
On 27 Nov 2022, at 18:48, Dave Crocker wrote:
On 11/26/2022 5:38 PM, Jim Fenton wrote:
Not Safe: It’s not safe because it breaks Barry’s use case above,
and others have pointed out MUA usage of the signature.
DKIM signature survival after delivery
On 11/28/2022 12:14 AM, Murray S. Kucherawy wrote:
On Sun, Nov 27, 2022 at 6:50 PM Dave Crocker wrote:
This does not provide any real understanding of how replay is
accomplished. And since it's easy to explain and doesn't take much
text, I'll again encourage including
to include in mine. I think it's
important.
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 11/27/2022 6:13 PM, Murray S. Kucherawy wrote:
On Sun, Nov 27, 2022 at 6:01 PM Dave Crocker wrote:
Hmmm. Having looked through the RFC, for every occurrence of
'delivery', I don't see an obvious statement indicating it is a goal.
This is the citation I keep coming to, toward
tatistical terms. Yes,
some MUAs can do the validation, but as we keep seeing, this sort of
information has no effect on end user behavior.
Going back to an earlier posting, I noted that a site that removes the
signature as part of delivery could provide an option to retain it.
d/
--
Da
a version of the same design thinking.
Or perhaps you think open relays are ok, since, after all, attackers can
easily circumvent this?
We should move onto better ideas.
Or, we might have thoughtful discussion, that engages carefully with the
substance, before discarding suggestions.
d/
--
Da
erent
RCPT TO but the same MAIL FROM and "From:".
Post-delivery survival of the signature is not only not a goal, it is
arguably (or possibly demonstrably) a problem.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
seems ok to me, since the
expense of imposing that expense isn't that high either.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman
for a received message, we can specify renaming the field
(and removing the actual signature value.)
This retains the desired signalling information, without being useful
for replay.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
nd forever occupies zero percent of
obtained efficacy.
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
. Again, this doesn't have a magic bullet, given the degree of
distribution and independent development and deployment that happens
with email.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing
.
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 11/20/2022 2:22 PM, Steve Atkins wrote:
On 20 Nov 2022, at 21:42, Dave Crocker wrote:
It’s a reasonable heuristic if Bcc is included in the DKIM signature, I just
don’t think including Bcc in the DKIM signature is a good idea.
Including Bcc: in the signature is a given, for this topic
On 11/20/2022 1:12 PM, Steve Atkins wrote:
On 20 Nov 2022, at 20:48, Dave Crocker wrote:
Remembering that you kicked this off with a heuristic approach, I'm merely
noting that a BCC with an addressee listed in it should be just as valid (to
the heuristic) as having it occur in To: or CC
. That means that an array of techniques is likely needed,
in the hope that each provides some benefit.
I'd class this one as 'some' benefit. No idea how much.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
On 11/20/2022 12:31 PM, Steve Atkins wrote:
On 20 Nov 2022, at 16:30, Dave Crocker wrote:
On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email address is
not in the To: or Cc: header then treat the mail as unsigned”.
Even
and it occurs to me that a) no it was not and is not intended, and
b) this might argue for *having MDAs remove DKIM signatures...*
Seriously. DKIM is intended as a transit-time mechanism. When delivery
occurs, transit is done. So DKIM has done its job and can (safely?) be
removed.
d/
--
Dave
) move toward eventual wg publication, I encourage
having at least one include this kind of detail, if only to make clear
what scenarios the proffered protection mechanisms are seeking to work
against.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
als; other
proposals remain welcome.
These can be cited in the wg datatracker and aren't needed here, since
they are only initial input and, as you note, other input is acceptable.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@masto
ly correct and important to a charter, rather than a more
general discussion. For example, it used to be helpful to include
reference to the initial drafts providing input to the effort, but
current wg datatracker capabilities make that unnecessary.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email
address is not in the To: or Cc: header then treat the mail as unsigned”.
Even if it is showing in a (signed) BCC field?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
as changed to ietf-dkim@ietf.org.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
aren't needed for it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
)
https://www.m3aawg.org/DKIMKeyRotation
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
seem to fare.
But it seems interesting, gets raised periodically, and at least could
be a cleanly-handled topic if pursued this way. (Especially if it is
encoded as a separate header-field...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
, and then figuring out why and how they are useful to provide...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
mean ?
This group is for discussion of the dkim specification. Your question
has to do with specific dkim software.
You should consult the opendkim users mailing list. See:
http://lists.opendkim.org/
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
oh and the clips of the seven other authors, including a
brief introduction of the award with Michael Adkins and the award
presentation by Dave Crocker
*Keys Under Doormats: Tutorial on Content and Issues* -
https://youtu.be/G-R8Tti0hCA
with Josh Benaloh and a brief overview of current M3AAWG Perv
your /seeing/ it. From me (or anyone else).
This translates into privacy relates to controlling disclosure of
information about a person or organization. Then add the
scope-of-control portion.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 4/16/2015 12:05 PM, Ted Hardie wrote:
RFC 6973 (found, among other places at:
http://www.rfc-editor.org/rfc/rfc6973.txt) has an extensive terminology
section and review of the issues. You may find it a useful place to start.
Except that it does not define privacy.
d/
--
Dave Crocker
Statement attempts to do -- requires robust effort both to be accurate
in what is said, but also to protect against misinterpretation.
Montevideo Statement seems to have accomplished neither.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
parts are
phrased in a manner that mostly misses any of the interesting issues
about ICANN, and tends to focus the reader on misperceptions and
irrelevancies.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, there was a concern raised by Pete
Resnick, when an IETF working group chair made statements at an ITU
gathering and represented himself as an IETF wg chair. We might want to
review whatever guidance came out of that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
to apply it to all
of us, the IETF community.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, and being
able to review the history of the document. While one might add a
mechanism to remedy this, note that we don't do that now.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
. Unless someone
thinks that this core construct for the IETF is going to be subject to
constant and fundamental modification???
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
at risk. But still, the correct outcome in this case is to
look at the very weak signal against the huge background noise in
order to find the rough consensus.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 10/2/2013 11:46 AM, John C Klensin wrote:
I assume we will need to agree to disagree about this, but...
--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
d...@dcrocker.net wrote:
If a spec is Historic, it is redundant to say not recommended.
As in, duh...
Duh notwithstanding, we
and
understanding an applicability statement.
ADSP is only worthy of a small effort, to correct its status, to reflect
its current role in Internet Mail. Namely, its universal non-use within
email filtering.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
centralized.
+1
Except that essentially all services other than email have gained
popularity in centralized form, including IM. So there appear to be
some important and difficult operational and usability barriers,
standing in the way of more truly distributed applications.
d/
--
Dave Crocker
to ensure that the implementations -- especially the widely
re-used open systems versions -- haven't introduced essentially systemic
exposures.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
of truly independent, distributed processing
environments, with limited resources and fundamental human factors
barriers really are quite shocking.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
feasible to satisfy -- if we ignore the continuing human
factors barriers to large scale email authentication. However given the
resources at the time the operational service was developed, I think it
wasn't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
is
with efforts to define IPv6-based email as having different semantics
from IPv4, rather than as the transparent extension it needs to be.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the 'then a miracle happens' faith that end system
designers will magically figure out the best user interface design for
security, since they have failed at that for the last 25 years; they'll
eventually succeed but they haven't, so far.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker d...@dcrocker.net wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations, appropriate for concern
On 9/6/2013 11:42 AM, Dean Willis wrote:
On Sep 6, 2013, at 9:55 AM, Dave Crocker d...@dcrocker.net wrote:
In other words, the IETF needs to assume that we don't know what
will work for end users and we need to therefore focus more on
processing by end /systems/ rather than end /users
On 9/6/2013 4:19 PM, Scott Brim wrote:
On Sep 6, 2013 3:34 PM, Dave Crocker d...@dcrocker.net
mailto:d...@dcrocker.net wrote:
To what end? Their poor uptake clearly demonstrates some basic
usability deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as we've seen
.
Is there something about PGP that creates different exposures than
S/MIME, in terms of those algorithms? (Key management has obvious
differences, of course.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, by placing too much into the infrastructure.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
in the same way, we might not
understand what behaviors to attempt or to avoid, since that often
requires some understanding of the differences between cultures and people.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
merely seeking to refute them.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
for the broader topic, you also might want to reevaluate much of
what your note does say, in light of the realities of Individual
Submission (on the IETF track) which essentially never conforms to the
criteria and concerns you seem to be asserting.
d/
--
Dave Crocker
Brandenburg
is to have any relation to the operational
Internet, it needs to treat solid, real-world deployment as having
higher priority than theoretical technical perfection.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
/ to IETF quality assurance and I have as little patience for
the sneering you describe as anyone else.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
be exactly what RFC 2418 says it should be.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
legitimacy.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/21/2013 11:13 AM, Patrik Fältström wrote:
But we are not there. A proper migration strategy to SPF has not been published.
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
d/
--
Dave
-based Entrusted Registry
(CIDER)
draft-kaplan-stir-cider-00
An Identity Key-based and Effective Signature for Origin-Unknown
Types
draft-kaplan-stir-ikes-out-00
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/21/2013 11:58 AM, Pete Resnick wrote:
AD hat squarely on my head.
On 8/21/13 1:29 PM, Dave Crocker wrote:
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
That's not an appropriate
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
for more explanation, given the number of
years of use the construct has had and for the number of different
applications, where has the problem (whatever you mean specifically)
been seen?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
is a
feature, not a bug.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/20/2013 9:08 AM, Andrew Sullivan wrote:
On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote:
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
You should explain that to my employer's support department.
In any case, I
waiting
period.
I do not recall anyone (else) showing support for that view, but
certainly not any substantial constituency.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
would've had that information when we did the
research for RFC6686.
Well, they were written down 15 years ago, but they haven't gained
traction yet, though I remain hopeful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
technologies have multiple components needed before they
are worth adopting, and an initial, incomplete set might be published
before a sufficient set is available.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
reality incorrectly or otherwise made a
problematic engineering choice.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
be aesthetically
displeasing, but it works just fine.
The second is that, unfortunately, deploying a new RR that gains
widespread, end-to-end support remains problematic, assurances to the
contrary notwithstanding.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the meeting session, do we re-imburse
them? Do we pro-rate the re-imbursement based on how many of their
meetings had technical issues with audio or video?
...
It's not worth it.
OK. Let's not put effort into thinking through a robust revenue model.
Let's stay with daddy pays.
d/
--
Dave
to document its tradeoffs; it often
does not make sense to choose only one such specification for use in all
scenarios.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
criteria that
determine assignment of our standards labels and our process really is
quite ad hoc and therefore unreliable.
I hope you are wrong.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
actually destructive,
since it provides fuel to the view that the IETF is a questionable venue
for standards work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
challenging it on basic technical
grounds.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
not.
So let's be careful about whether slides ahead of time need to be a
requirement, rather than being considered only a nice-to-have.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
distributed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/6/2013 12:15 PM, Ted Lemon wrote:
On Aug 6, 2013, at 11:27 AM, Dave Crocker d...@dcrocker.net wrote:
An entirely different approach would be to have all speakers make a
'reservation' into a single meetecho (or whatever) online queue, and then get
called in order, whether local or remote
not appropriate to throw out results that were validly obtained but
yield unpleasant results, and then repeat the same query. (In fact a
repetition of a survey on the same sample population is a rank violation
of reasonable experimental methodology.)
d/
--
Dave Crocker
Brandenburg
/wiki/MeetingTimePrioritization
I might argue that that specific list is overly fussy and possibly
Procrustean, but the gist of it definitely looks like the right kind of
thinking, to focus wg face-time on resolving things rather than chatting
and teaching.
d/
--
Dave Crocker
Brandenburg
insist on treating consideration of Full standard as an excuse to
discuss first principles, but it's not within scope.
Over time, as more specifications are processed to Full, the community
will learn to be a bit more efficient about it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
in the DMARC BoF:
a mechanism for protecting the display-name portion of the
RFC5322.From field
My guess is that it might be educational. :-)
I'm involved with the DMARC effort. I'm almost positive it won't be...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that is applied to event logistics will go a
long way here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
dotless names one way to another should be seen as an
impossible task.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
no historical precedent.
It is, in fact, possible that Marshall Rose was wrong and that for some
things, there is no possible thrust sufficient to make pigs fly, or at
least not without killing an extraordinary number of other pigs.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 7/13/2013 7:25 AM, Livingood, Jason wrote:
There must be something similar to Godwin's Law whereby any IETF
discussion can devolve into a debate over NAT. ;-)
It's not devolution, it's translation into our private context.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
101 - 200 of 1843 matches
Mail list logo
