not need to add the l= tag to the signature
if they are signing the entire body.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
view, your proposed section 1.1 DKIM Architecture Documents and
with adding the AUID and ODID as part of the output to make all the
documents protocol consistent will settle the issue, in my view, for
all parties.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
[1
done.
I take the position that 4871bis does not incorporate what we have learned
since 4871. If it did, these concerns would not be on-going.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
change will fix this in 3.9 last sentence:
The output MAY include other signature properties or result meta-
data, including RFC5322.From, PERMFAILed or otherwise ignored
signatures, for use by modules that consume those results.
--
Hector Santos, CTO
http://www.santronics.com
http
to
mention anything closely related to it.
I would like to ask the chairs if we can get Consensus Reevaluated.
From the limited WG participants providing input, it appears we have
Rough Consensus for this identity to be included in RFC4871bis.
--
Hector Santos, CTO
http://www.santronics.com
http
, then we should allow a add
a more directly DKIM related reference to DKIM Service Architecture
[RFC5585] document.
Doesn't that fit with DS?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
Signing Practices per RFC5585.
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Dave CROCKER wrote:
Current implementations are irrelevant. They will completely and utterly
ignore what is in 4871bis, because they are done and work fine. The problem
is whether
.
--
Sincerely
Hector Santos
http://www.santronics.com
Hector Santos wrote:
Dave,
My perspective was that the damage was done per se in the last
errata and changes with this bis are irrelevant and don't reflect
current existing implementations. Code changes are not necessary for
current
, that is the goal in protocol designs.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
feedback verification method:
http://www.google.com/patents/about?id=NXSGEBAJ
So in my strong opinion, the RFC5322 Message-ID is a traditional
strong original mail authenticity identity and should be included in
the core group.
--
Hector Santos, CTO
http://www.santronics.com
, but in a
DKIM era, this header can be protected like other MLM core headers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
[1]
http://www.ietf.org/mail-archive/web/ietf-message-headers/current/msg00038.html
___
NOTE WELL
.
If no valid signature is found, the message is considered to be
unsigned by DKIM standards.
To limit potential denial-of-service attacks, verifiers MAY
limit the total number of signatures they will attempt to verify.
--
Hector Santos, CTO
http://www.santronics.com
http
that offers the best
technical and DKIM results.
If that can be stated in 6.5, I agree the 6.4 note would become redundant.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
.
That's just not right.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
-ID may apply under certain scenario
where it is known this header may be altered, such as
under a resigner creating a new message.
Whatever.
Hector Santos wrote:
Murray S. Kucherawy wrote:
Recommend adding the following paragraph (excuse the XML markup):
t There are tradeoffs
hosting requirements. You
won't, you will need to combine all the DKIM documents which was what
we had to do with I considered the holy bible for internet hosting -
RFC1123. Twelve years later RFC2821 made RFC1123 obsolete.
--
Hector Santos, CTO
http://www.santronics.com
http
related concerns
peppered in the document should be consolidated under 9.1.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
John R. Levine wrote:
That is quite specifically what 4871 says. To do anything different would
be a major incompatible change. We have explicitly rejected the idea that
first party signatures are special in DKIM. (They are in ADSP, but
that's ADSP.) Among the reasons we rejected the
concept.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
namespace and let
implementators decides?
I think it is really unreasonable to throw in this section (that is
not minor) at the last minute without the proper WG-man-hours for a
thorough consideration.
--
Hector Santos, CTO
http://www.santronics.com
1 DKIM Service Architecture. The AUID is needed for
the major CSP (Checking Signing Practice) black box flow in the DKIM
design.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
Rolf Wrote:
As the From: address is mandatory input for the signature, it may be a
logical step to also make it mandatory in the output?
Murray Responded:
Given the above, do we still need to?
Hector Santos responded:
To be more DKIM Mail Integration Consistent and Complete - yes.
See
some WGLC compromise that finishes the job and
still makes RFC4871bis useful for today's DKIM deployment requirements.
Can that be done? I don't know.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
Dave CROCKER wrote:
On 4/28/2011 12:49 PM, Hector Santos wrote:
To illustrate this in RFC5585 by labeling the inputs required:
|
|- RFC5322 Message
V
++
| Message Signed
Dave CROCKER wrote:
On 4/28/2011 3:23 PM, Hector Santos wrote:
Rather I am highlighting the limited DKIM output requirements is
outdated and insufficient to support today's (extended) DKIM mail
integration and security needs outlined by WG consensus-built RFC documents:
What part
to also make it mandatory in the output?
is no.
No further discussions needed about From: Address nor the AUID for the
Output Summary.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
A-R today because its the only BCP around for DKIM and if anyone who
dares to claim it not needed and even tries to compete with it, well,
you, I and probably many others will contest that claim as well.
--
Hector Santos, CTO
http://www.santronics.com
[1] http://en.wikipedia.org/wiki
Rolf E. Sonneveld wrote:
-1. I suggest to add clarifications etc. to a future update of RFC5863
(deployment and operations document).
So you agree clarification is required but not for RFC4871bis?
Interesting. Lets see:
1) A few words clarification for DKIM-BASE standard. A little
Alessandro Vesely wrote:
On 27/Apr/11 01:25, John Levine wrote:
Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file. If the
$ORIGIN is _domainkey.example.org, an
Dave CROCKER wrote:
The best I can suggest is something along the lines of noting that
assessment-level heuristics can be aided by certain choices of signature d=
names. And then specifying what they might be, so that both signers and
verifiers know how to encourage success for the
Rolf E. Sonneveld wrote:
Interesting. Lets see:
1) A few words clarification for DKIM-BASE standard. A little
[LESS] confusion for Windows people and domains using
ISP managed DNS zones.
Well, maybe it's time Windows people leave their .local zones and
discover a whole world beyond
into the mail stream.)
I think I could live with that.
+1
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, and are looking forward to
being part of creating it.
+1. I have strong convictions Policy with be DKIM's White Horse.
Thanks for your input.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http
understand.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
header is IETF RFC material fit issue,
then is it possible to use a generalized text:
o Any DKIM related verification results and trace fields
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http
.
--
HLS
Hector Santos wrote:
This is the problem with this ambiguous responsibility term in DKIM
and it becomes worst when blame or credit is distributed.
IMO, you can't have it both ways.
Sure, you are saying if unsigned parts altered or removed, then the
mail is still valid, everything
Dave,
Everyone accepts (maybe some reluctantly and with high DKIM concern),
the *policy semantics* separation between the AUID and SDID from
RFC4871bis.
My exception is the incorrect extended assertions there is no DKIM
created binding association between the 5322.From and the signature
John R. Levine wrote:
I have to agree with Dave. This is way outside anything that DKIM
specifies, it's the first party vs. third party distinction that I
hope we have buried for good.
Bury things alive, not making sure its not dead first or trying to get
rid of significant distinctions
John Levine wrote:
Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file. If the
$ORIGIN is _domainkey.example.org, an entirely plausible scenario, the
current text
because will have the GUI softare,
but in general for all. Levine may not need help, but others might.
Adding the complete public subdomain brisbane._domainkey is better
than just having brisbane and if you must explain the initial ZONE
assumption.
--
HLS
Hector Santos wrote:
John Levine wrote
these
labels will look like.
Can you provide a few example maybe showing how an IDN address and
domain will look like under each RFC and also UTF8 for?
From:
DKIM-Signature: d=
DNS zone record
or anything else you deem important to show the issue and/or conflicts?
--
Hector Santos
not support
lesser hash strength rsa-sha1 and will treat such messages
as unsigned.
Whatever.
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Sunday, April 24, 2011 4:39 PM
Barry replied:
Dave further tweaks:
INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged,
some senders might prefer to use rsa-sha1 when balancing security
strength against performance, complexity, or other needs. �However,
compliant verifiers might not implement rsa-sha1;
Michael Deutschmann wrote:
On Fri, 22 Apr 2011, Hector Santos wrote:
However, I suspect you're getting at the fact that, if it had to be
written today, such a certification standard would be hamstrung by the
fact that ADSP sucks.
Almost... see below.
All it could do is make dkim
should cover all the RFC4871bis paths an
implementator may take with this particular note:
- Updated systems pulling sha1 support,
- New systems never adding sha1 support, or
- All systems adding a failsafe switch to disable sha1.
--
Hector Santos, CTO
http://www.santronics.com
Quick question and comment:
I see the major change is the TOC (table of content) outline and all
the document's TOC references. Chapter 1 is a editor note, (very
odd). Is that what we really want for a CHAPTER 1? Especially when it
indicates the idea of removal thus once again changing the
less secured
(low-security).
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
SDID.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Douglas Otis wrote:
Changing a reference of RFC3490 to RFC5890 already represents an
incompatible change.
Your assertion is noted.
John, it is correct to reference RFC5890 but for any implementations
that currently have RFC3490 support there is a conflict verifiers need
to be aware of. A
to that? Could that show how as exploited AUID
can use ADSP to protect against multiple SDID signing exploits?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
Barry Leiba wrote:
I asked my IDNA expert, who said that the definitive answer is it
depends. �He suggests our chair ask our AD to check with the IESG.
Our chair is asking our AD to check.
We have the IESG's answer: we should change the reference to RFC 5890
and change the text to use
Murray S. Kucherawy wrote:
Bill Oxley:
In my mind the whole adsp degenerated into a use case only for well
recognized narrowband senders such as banks. Had nothing to do with
reputation sellers, and judging by a recent exit from the market a
reputation is only as good as it is maintained.
Murray S. Kucherawy wrote:
Oops, this is a separate issue. But I hope it's also not
contentious.
[...]
Since I'm not exactly an EAI/IDNA expert...
The only thing that's not obvious to me is whether the hash functions
should hash the bytes of the UTF-8, or convert them to UTF wide
Charles Lindsey wrote:
Murray,
I viewed this as another layer issue. Adding a DKIM-Signature: header
is no different than any other RFC5322 header where UTF8 conversion is
already a consideration. But maybe to provide guidance for what parts
of the DKIM-Signature RFC5322 header needs to be
, you are not going
to get wider acceptance. Its as simple at that.
At this moment, you are the DKIM technology market leader. It is up to
you as a PRODUCT RD engineer if you want to see ADSP used, tested and
explored among your OPENDKIM customer base.
--
Hector Santos, CTO
http
author domain
policy records.
Silly or not, those are the fact lawyers look for.
--
Hector Santos, CTO
http://www.santronics.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
-Original Message-
I can break it down by month if anyone's interested in trend
data, but the numbers are so small in the first place that I
doubt it'd be very interesting.
So we can't tell how widely ADSP has been deployed because we
don't check in
Murray S. Kucherawy wrote:
We tried policy, and couldn't make it work. It's time to
spend all this energy looking at something else.
Murray, I appreciate your assessment.
The writing was on the wall when you have an opponent of policy become
the author of ADSP, broken by erroneous removing
Murray S. Kucherawy wrote:
-Original Message-
Why isn't an authorized signer an identity example?
It is. The question is: Is it harmful not to list it explicitly?
There doesn't seem to be support for that idea so far.
Which makes very strange.
If you think it is, and had
Dave CROCKER wrote:
On 4/15/2011 12:10 PM, Murray S. Kucherawy wrote:
All of that discussion belongs in the deployment document or some unwritten
specs about policy or reputation (which is all semantics), not in the base
specification (which is all syntax).
+1
It's more fun to
Hector Santos wrote:
Dave CROCKER wrote:
On 4/15/2011 12:10 PM, Murray S. Kucherawy wrote:
All of that discussion belongs in the deployment document or some unwritten
specs about policy or reputation (which is all semantics), not in the base
specification (which is all syntax).
+1
It's
them, Microsoft is still a market leader. Ignore ADSP at
your own peril.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Hector Santos wrote:
John R. Levine wrote:
So in my limited dataset, ADSP usage is if anything shrinking, with only
Paypal publishing discardable.
hmm
John, you do realize its only April? 1/4 of 2011?
According to your stats:
2649*4 = 10,596
what is already
stated as an independent trusted identity.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Barry Leiba wrote:
My proposed text attempts to inject the idea that at least one
identity is an author authorized signer distinct from what is already
stated as an independent trusted identity.
But I don't think the actual author (in the case of this message,
me, the guy who's writing it)
and will hopefully
universally trusted by all DKIM receivers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
think this clarifies anything in particular. If the zone file
is for a domain itself, this makes sense, but the text as-is is just fine
if the zone file is for _domainkey.domain. I've seen it done
(and have done it) using both designs, so both are equally correct.
--
Hector Santos, CTO
?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
into the mail stream.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Murray S. Kucherawy wrote:
I think it's redundant to refer to a signed message, since that's what the
entire document is defining; if the message isn't signed, the document
doesn’t apply in the first place.
So the question to me is more like: Is an intermediary adding a signature
Dave CROCKER wrote:
I think that that's entirely the wrong question.
For this stage of the document, the questions are:
1) What problems have been documented as being due to this wording?
2) What technical errors does this text clearly represent.
In both cases, the answer for
For appendix C, I believe the example for the public key DNS record is
missing the complete subdomain. It has brisbane where it should be
brisbane._domainkey
Text change to consider:
This public-key data (without the BEGIN and END tags) is placed in
the DNS as a TXT record subdomain
correct.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
Dave CROCKER wrote:
On 4/13/2011 10:31 AM, J.D. Falk wrote:
I'm generally in favor of updating the document to match the current state
of IDN and EAI work, but I don't know it well enough to comment
intelligently on whether John's proposed text does so.
as phrased, I'll disagree with
SM wrote:
[I suggest following up on the DKIM WG mailing list]
You are restating a MUST. :-) I agree that it is important. The
problem here is that it still leads to various interpretations due to
the keywords.
I'll try rewriting the text in Section 3.6.1:
h= Acceptable hash
did nothing until Microsoft came out with
their own versions.
Anyway thanks for your comments regarding the WG future.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
is not consistent in 2.3, I would like to see that we
also add Policy Assessment semantics to this text.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
semantics to
help serve DKIM total deployment interest or c) we can remove the
independent trust assessment service evaluation layer semantic that
should had been snuck in at the last minute in the first place without
keeping it open ended.
--
Hector Santos, CTO
http://www.santronics.com
http
Hector Santos wrote:
Fundamentally, we tried to make DKIM-BASE independent of specific
implementation evaluation methods starting by pulling semantics
regarding policy.
However, an evaluation layer for trust was reintroduced in section 2.3.
2.3. Identity
A person, role
be rendered - should be treated
+1
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
using SHA1.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
Douglas Otis wrote:
On 4/7/11 10:08 AM, Murray S. Kucherawy wrote:
You could, if you know that the use of i= by a given
SDID is consistent, and it's useful for you to track per-AUID
reputation. Those are two big ifs to me.
Murray,
Anyone processing this type of data will quickly
.
The easier implementation is #1 and maybe with limited #2 would work.
So to answer to this question, yes, it is better to use headers if
only because it would be the only way to currently maximize the
probability of support without a need for software change.
--
Hector Santos, CTO
http
Charles Lindsey wrote:
Which suggests that future use profiles may need tag hooks to hang their
features on, and so if there is some underused existing tag (such as i=)
already in the spec, then it is better left there to facilitate such
future profiles.
Good point.
The thing is, for
Michael Thomas wrote:
On 04/06/2011 08:48 AM, Steve Atkins wrote:
That sounds like a fragile way to extend things - leave a
little used feature around and hope someone who wants something
new hijacks that field in a non-conflicting way instead. (Which
may not be what you're suggesting, but
standard allows for signer-defined non-standard
tags to exist and be bound to the DKIM-Signature. Of course, the only
technical requirement would be for it to follow the tag=value ABNF syntax.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Tony Hansen wrote:
Whether it were done by adding semantic signposts for i=, additional tag
values, or additional 5322 headers, it should *not* be done in an ad-hoc
fashion.
+1.
From my perspective, we are beyond the idea of whether i= or a new
st= tag is needed or not, but rather
it is already possible to create
multi-signer streams, the only incentive I can see is a signer
incentive to reduce multi-signer stream management and cost related
issues.
It sounds your question about handling results a certain way.
--
Hector Santos, CTO
http://www.santronics.com
http
Murray S. Kucherawy wrote:
-Original Message-
That's a fairly grandiose expectation. One might also wonder
why law enforcement hasn't managed to stop drug abuse, cybercrime,
or myriad other plagues on society.
Does that mean laws should not exist?
The issue is that the
Murray S. Kucherawy wrote:
-Original Message-
2.3. Identity
A person, role, or organization. In the context of DKIM, examples
include the author, the author's organization, an ISP along the
handling path, an independent trust assessment service, and a mailing
list
with the d= value, I see less value in
passing this to the engine unless it is something that reflects the
5322.From address and even then, the 5322.From is also hash bound
signature requirement.
So with a reputation mindset only, I can only see i= useful for
logging or tracing.
--
Hector
Lets also keep mind that i= predated any reputation assessment
modeling the WG cogs took on which was first out of scope as oppose to
the focus with the chartered policy standard proposal. Hence DKIM
verification output modeling was based on a security model to protect
against any signature
and the outcome would be the same -
no valid signature.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
John R. Levine wrote:
So if we keep i= as is in the spec, we can conclude the standard process
and give a meaning of i= outside this spec in another RFC?
No, it's not backward compatible. My signatures all have a fully
compliant i= value which is not an e-mail address. (Take a look.)
It
Dave CROCKER wrote:
On 4/1/2011 10:04 PM, Franck Martin wrote:
I would suggest we deprecate i= and add st= (if not already used)
that would let the sender specify a stream category.
With IPv6 we may loose IP reputation, this is a way to bring it
back within DKIM.
Why doesn't
component.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, etc) in describing
the what, why and when to use reasons for his particular i= option,
was not easy to do especially when it came to the DNS management aspects.
--
Hector Santos
http://www.santronics.com
___
NOTE WELL: This list operates according
to ambiguously document
for customer to understand and use with no real verification payoff,
then +1 to remove i= from DKIM.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
setup does not have a i= defined, yet it is
showing one in the A-R record when verified by sbh17.songbird.com.
Does that mean, a proposal to remove i= in DKIM-BASE, would imply an
update to the A-R draft is necessary?
--
Hector Santos, CTO
http://www.santronics.com
http
801 - 900 of 2144 matches
Mail list logo
