in theory, there's no difference between theory and practice.
in practice, there's interoperability testing...
I'd think more conformance than interop, since I'd be surprised if there
were any ambiguity about the correct way to encode UTF-8 into punycode.
Do we know whether DKIM works
since I'd be surprised if there were any ambiguity about the correct
way to encode UTF-8 into punycode.
Would you rather be surprised in the middle of critical infrastructure
operations or during an interop event?
No, of course not. If we have another interop event, it would make sense
You understand this stuff far better than I. I'm not even sure of what it
might mean to license a /patent/ under the GPL (perhaps it means that any
implementation released under the GPL is automatically licensed?)
There's no such thing as a GPL patent license. The FSF has a longstanding
Hmm... suppose that we do, and that we manage for DKIM to be finely
implemented at most hosts, paving the way for a spam-free world. In addition,
suppose that Yahoo! Inc goes out of business and the domain keys patent is
acquired by Unisys...
Then it makes no difference at all, since the
See the CHUNKING extension defined in RFCs 1830 and 3030.
CHUNKING can in theory be used to send the headers and body separately. But
it doesn't have to be - the chunk boundaries are aribtary and there's no way
for a server to say send me the headers and body in separate chunks please.
Of
I can't say, but I do know that many of us toss a whole lot of mail at EHLO,
some at MAIL FROM: and some at DATA. The idea I was thinking about was
whether it provides any value whatsoever to at least know that you are
authentically dealing with a legitimate source sooner, without having
This is the mailing list advice that I strongly suggest we NOT attempt
to provide at this point.
strongly disagree. Filtering early is more likely to pickup signature
breakage and protect the down stream recipient. Its more likely to
reject back to the sender if they configured stuff
To put it concretely, your registrar is JANET, ...
Mine's JANET, too. Sure, they won't all be accurate, but if they're
inaccurate then I know how to get hold of someone to fix the problem. Anyway,
the person who cares most about the accuracy is the domain owner (or their
customers).
I
[ this is also well trodden ground, so I will again try and keep this short ]
Short summary: DKIM and ADSP offer no meaningful defense against spoofing.
Shorter summary: The WG charter says there should be
Yes, there was considerable naive optimism in the charter.
We all agree that it would
You half-joke, but one of the arguments we presented to the FTC back in 2003
or so regarding spam was that we had an opportunity to regulate issuance of
domain names. If not regulate, then at least insist on an identifiable legal
entity being required to register a domain.
Without going
I think l= and x= both put more information into the hands of the
verifiers.
Well, sure, but the question is whether that information is useful. We
could include the phase of the moon and the software author's middle name,
too.
Both l= and x= are bad for interoperability, because it is
DKIM and (Sender-ID and SPF while I'm at it) make recommendations about
what to do with a signature that fails to verify
Right, but l= and x= make it unclear what it even means to verify.
R's,
John
___
NOTE WELL: This list operates according to
I submit that RFC4871 can make assertions about the verifier, but not
about the assessor. I further submit that many assessor implementations
will prefer the benefits of a verifier that provides more than just a
Boolean output.
You're probably right, and that's the problem.
I don't have
DKIM is too complicated as it is, and it strikes me as an extremely poor
idea to add yet more cruft to work around perverse situations that are as
yet (and probably always) entirely hypothetical.
I don't understand what cruft you think I'm talking about.
Telling people that it is reasonable
If you're going to send a message on and are not going to break the
signature, you do one of these:
Sign or don't sign, it works fine either way.
If you're going to send a message on and ARE going to break the
signature, you do this:
You're a mailing list, so filter, sign and earn your own
My recollection of the debate about l= is that there were about as
many theories about the point of l= as there were people promoting it.
The main theory I remember was about hypothetical mailing lists that
were too incompetent to filter incoming spam so the list recipients
would do it based
One of the reasons l= came to be was that we wanted to have as many valid
signatures out there as quickly as possible, so as to provide a reasonable
alternative basis for reputation. There was the presumption that the mailing
list software would lag, and it has. Now we know that one MAJOR
Why was the informative note that you added in -09, which also described
a signing practice not described in RFC 4871, not (to use your term) silly?
Because it pointed out a way that version of ADSP was badly broken, of
course.
R's,
John
___
NOTE
,
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
More Wiener schnitzel, please, said Tom, revealingly.
On Tue, 7 Apr 2009, Michael Thomas wrote:
I think that John meant to send this to the list.
John R. Levine wrote:
Then it doesn't meet the requirement in RFC 5016
The following shouldn't be discouraged:
From: f...@bar.com
DKIM-Signature: ... d=43343.rep.bar.com ...
where 43343.rep.bar.com doesn't have any MX or A record.
On further reflection, you're right. The signature isn't an email address
or a web site, so there's no reason it needs anything
Informative Note: ADSP is incompatible with DKIM signing by parent
domains described in section 3.8 of [RFC4871] in which a signer uses
i= to assert that a parent domain is signing for a subdomain.
That's not fine, since we've just gone around and agreed that the
signing identity is d=.
We've still got a fairly basic disconnect here.
The verifier doesn't need to do anything with the additional field, so
if it just passes all unknown fields to the assessor it doesn't need to
change at all.
OK, so you're saying that the verifier should consume the fields it knows
(let's say
I see no benefit whatsoever in using DKIM for blacklists. But we need
to be careful to avoid automatically carrying the habits of blacklist
filtering into whitelist filtering.
This on its face seems like a very fair statement, and I agree with you that
we clearly have been living in a
I agree that it is better to include this information in the signature
itself, which is why draft-fenton-dkim-reputation-hint does it that
way. But the constraints on the output of the verifier being proposed
would mean that the assessor can't depend on that additional tag/value
being
We seem to have a fairly basic disconnect here. As far as I'm
concerned, an assessor has better things to worry about than the
internal details of the signature. Trying to reverse engineer or guess
what the signer had in mind would be a hopeless swamp even if it were
desirable. ...
If
If assessors can't be bothered to assess the supposedly self-limiting
implementation details, then reputation systems can not take them into
account. By definition.
Right. That's a feature. It's not my job to work around or even identify
crappy signatures. If there's junk in your signed
I sign all my mail, but there's no way I can say that with ADSP. In its
current form, ADSP is broken and useless.
I thought that's what dkim=all says:
allAll mail from the domain is signed with an Author
Signature.
Do you not sign them with Author Signatures?
Take a
You have chosen to sign your mail in a manner that is inconsistent with
the practices described by ADSP.
Right. My signatures use i= to describe the local identity responsible
for each message, you know, like DKIM says I should.
In any case, that's a different question than Steve asked: He
So, by ADSP's definitions, you don't sign with Author Signatures. That
doesn't mean it's broken and useless.
Even though I do in fact sign all my mail with valid DKIM signatures, I
can't say that with ADSP. Perhaps there are people who consider that
makes ADSP highly functional, but it
The i= field doesn't do that. DKIM doesn't identify individuals, only
domains.
The spec says that it *does* identify a user.
It says that i= is the user or agent on behalf of which this message is
signed. It gives the example of an agent that's a mailing list, and
we've seen all sorts of
That's correct. This is dependant on the receiving system having some
knowledge that the UAID is meaningful to parties outside the signing domain,
and is therefore not the default.
OK. Now we're back to my t=address proposal, I guess.
R's,
John
Except that the UAID might or might not be an e-mail address. The one
on this messgage isn't.
So, for clarity, can you (or someone) call out what you think is
the impact, if any, for ADSP, caused by this proposed change to
4871.
Nothing. ADSP's attempt to force i= to be an identifier that
This protection depends upon a means for the signer to assert which
algorithm is deprecated, and what shiny new algorithm is being offered.
Wearing, as usual, my receiver hat, I still don't see any reason to be
interested in random senders' opinions about the relative merits of
various
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the modification was as an option.
That's one
John, I think one of us must be missing something. Why would the
flag always be set the same? The problem only occurs when you are
using g= in the key, and there might be good reason why you would not
want to limit the signature to the d= domain in this case, e.g.,
role-based names such as
Question (not a suggestion): why is draft-kucherawy-sender-auth-header
not on that list? ...
Well, it's not in our charter, but assuming that the -base discussion
doesn't take up the entire agenda it seems worthwhile socializing it
in a pre-re-charter kind of way. I'll note that Auth-res is
This is a contract issue, not a technical issue.
Few entities are in a position to negotiate security details relevant
to DKIM keys within higher-level domains.
Too bad. It's still a contract issue, not a technical issue.
A verifier should not expect any parent domain to be authoritative
effective response at affected levels. If a TLD used DKIM with 768
bit keys for example, that might be adequate when this domain's
messages are seldom targeted. On the other hand, big-
financial.tld may need to react to a highly targeted attack
employing greater resources, perhaps
The text for the r= parameter indicated that as the number increases,
the recommended annotation levels made by the signer also increase.
Indeed, but we still have no idea how that translates into making a
reputation decision.
The assurance being made by the signer has _nothing_ to due with
C) You duck out of the rain into a building which turns out to be a
courthouse. ...
You say that anyone could have added that signature, there being
no binding from the public key to the purported signer (i.e. no PKI,
which does exist for a reason) therefore DKIM stuff should be
weighed
If by some miracle people actually rolled their keys over every
week -- as Mark is to be suggesting as the alternative to x=
-- then your use case would not work either.
Quite true. So what?
To me the answer is obviously
yes. How do you handle that with x= ?
This is a false dilemma
Uh, what situations are those? If DKIM isn't useful for mail sent to
humans with MUAs, why are we wasting our time?
A nice strawman.
No, it's an honest question. Many real users read their mail a whole lot
less often than we weenies do. I know people who read their mail once a
week.
There is no specification that restricts what lists are allowed to do.
There will, however, be restrictions on who and how a domain's
name in origination addresses can be used soon enough. That is the basic
conflict.
If you are planning on setting rules for lists about what they can do with
It seems to me that since DKIM signatures are expected to have short
lifetimes and to have only moderate value, and that we've established
quite thoroughly that there is not yet an obvious successor to SHA-1,
it would be OK simply to note that we'll need something more secure in
the
I would strongly suggest that we make SHA-256 the MUST on the signer
side for interop and SHA-1 a MAY.
Agreed, with a note that if the IESG has a new and improved hash they like
better than SHA-256, we can plug that in instead.
Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of
I'm increasingly getting the impression that we don't
really understand the semantics of SSP.
Here is the current proposed policies: ...
o=! EXCLUSIVE (signature required, no 3rd party)
Well, OK. if a message has both a signature from the From: domain and
one from someone else, does
Well, OK. if a message has both a signature from the From: domain and
one from someone else, does that pass? Why or why not?
-
From: Hector Santos [EMAIL PROTECTED]
For the EXCLUSIVE policy? Following SSP, it would be a REJECT because the
policy says no 3PS should exist. If it does,
John, this would be all well and good except for the fact that even
though my name isn't on the draft I've had a great deal to do with
it from even pre-DKIM days. Hector's interpretation is wrong, and
that's not how it should be implemented.
I don't have any strong feelings about SSP other
As far as I can tell, the simple body canonicalization seems to work
pretty well -- I'm not sure I recall anything that I could attribute
to a failure in the body canonicalization that wouldn't defeat _any_
attempt (ie, it was mangled).
I'm inclined to agree, particularly if we're not trying
Hey, wait a minute -- isn't that what lists already do?
The discussion was whether the DKIM signature itself can serve as a
basis for acceptance. In other words, can a DKIM signature safely
accrue a reputation?
If the answer isn't yes, I think we're wasting our time.
A best practice
I don't find forging to be a useful description of what mailing
lists do.
Then try indistinguishable from forging.
I dunno about you, but I have little trouble telling mailing list mail
from random forgeries when I look at it.
If your favorite anti-spam technique or security model behaves
So if, during the threat analysis, we identify some such
constraints that make life easier/better when combined with
some ssp options then we could consider standardising them,
or did you mean that any such constraints should be just up
to the individual implementer/signer?
The latter. The
Yes, and if there were a proposal for standardizing something that
depended on solving World Hunger first, I would be skeptical of
that too.
Since the people I know involved with DKIM expect it to be plenty useful
without third party reputation services, I'm not sure what your point is.
Mail
message has three sigs from Able, Baker, and Charlie (in that order if
you care about order.) Able and Charlie verify, Baker doesn't. Now
what do you do?
I have come to the conclusion that you just need to behave as if Baker
isn't there at all. If you treat the message more favorably,
OK. Able is on your whitelist. Charlie is on your blacklist. Now what?
I'm making this up as I go, but I suppose I would accept the message:
if someone I trust asserts responsibility for the message, that's more
important than the fact that that someone I distrust also asserted
I concur with Tony's model that a signature only means I will accept
the blame for this message.
I don't think that flies, or at least, I think that makes DKIM of fairly
marginal value. A message itself is rarely blameworthy; what matters is
the context.
Right. The context is who
Right. The context is who signed it.
That's not sufficient unless signers who (re)transmit messages are
clearly distinguishable from signers who author content.
You keep saying that, I keep pointing out that you're wrong. I guess
we're done.
R's,
John
PS:
That's a bit like saying that
The question that gets asked here is: what problem are you trying to solve?
in effect, you're asking me to do the analysis for my threat model. *
No, he's asking what problem you're trying to solve. If you say a bunch
of things are important, you must have something in mind to do with them.
301 - 358 of 358 matches
Mail list logo
