[ietf-dkim] Re: Using PKIX certificates with dkim

Hallam-Baker, Phillip wrote: > Document: draft-dkim-pkix-00.txt http://www.ietf.org/internet-drafts/draft-dkim-pkix-00.txt Page not found. Do you have it in human readable (*) format anywhere ? Bye, Frank *: "human readable" excludes anything you MUA spews out

[ietf-dkim] Re: DKIM Threat Analysis v0.06

william(at)elan.net wrote: > Please define "joe job" Yes, apparently that's important, I see two definitions in the context of articles here: 1 - intentionally damaging the reputation of a domain / address, typical cases involve drugs and porn in the same spam mail 2 - a relaxed definition

[ietf-dkim] Re: on DKIM as an anti-spam measure

Keith Moore wrote: > "I will accept any content that claims to be > sexually-explicit, the other filters notwithstanding" :) A quick and dirty threat analysis: "Publishing 'receiver policies' might not work as expected". > OTOH, If we don't want the direct marketing folks to fight > this tooth

[ietf-dkim] Re: Not exactly not a threat analysis

william(at)elan.net wrote: >> There's a lot more information available about domain names >> than about IP addresses, > I disagree. "Age of domain" has its uses if you can get it. RFCI listings are also interesting. > In the end the most reliable way to detect and filter these > domains is

[ietf-dkim] Re: Not exactly not a threat analysis

Tony Finch wrote: > Isn't the i= tag the new identity that Keith is asking for? Checking the draft, i= is optional, must be below d=, it's not required to match anything selected by h=, and it's a "verifier policy issue" [XREF TBD] with the fine print. I'm not sure, but for Keith's idea the "

[ietf-dkim] Re: Not exactly not a threat analysis

Ned Freed wrote: >> Okay, so I have a counterexample. You and I have a long >> history of working well together, so maybe we can discuss >> this offline and come to some mutual understanding. > Sounds like a plan. Email or phone would be fine. One of you please post a summary of what you'll f

[ietf-dkim] Re: Purpose and sequence for DKIM specification and deployment

Dave Crocker wrote: > The sequence matches what is already specified in the DKIM > draft charter Apparently many / some (?) participants here prefer to consider DKIM only in conjunction with SSP, not as an isolated solution. This makes sense, the

[ietf-dkim] Re: Feedback in charter

Hallam-Baker, Phillip wrote: > If we do propose a maintenance model we develop a very clear > advantage over SPF. Unlikely, because the error handling was improved, all newer SPF implementations will "PermError" syntax errors. But it was a major PITA to get this into the draft, because not all o

[ietf-dkim] Re: Thoughts on the DNS RR issue

Hallam-Baker, Phillip wrote: > _prefix.exists.example.comTXT "Policy1" > *.example.com CNAME _wildcard.example.com > _prefix._wildcard.example.com TXT "Policy2" [...] > This algorithm is 100% compatible with the deployed, legacy > DNS and meets all use cases that we

[ietf-dkim] Re: Apology

Scott Kitterman wrote: > It has been brought to my attention off-list that some > consider my postings here inappropriate. Oops, I considered the long thread with you and Doug as very interesting, it explained parts of the philosophy behind this idea. And "spammers will just sign whatever they

[ietf-dkim] Re: Purpose and sequence for DKIM specificationand deployment

Earl Hood wrote: > It may be better to state: > A verified domain signature within the message should facilitate > domain-defined identification methods so domains can more easily > deal with abuse complaints. Don't get me wrong, but all this crypto-signing-header-DNS effort only to get

[ietf-dkim] Re: Purpose and sequencefor DKIM specificationand deployment

Hallam-Baker, Phillip wrote: > What we should attempt to achieve in the specification is a > method of describing the protocol from a neutral point of > view that is independent of the perspective of any given | party. Let's say that the perspective of an "ignorant" receiver is more important tha

[ietf-dkim] Re: Purpose and sequence for DKIM specification and deployment

Hallam-Baker, Phillip wrote: > Lets say that I want to reject any message from > [EMAIL PROTECTED] if the policy record at verisign.com > denies responsibility for any message that does not > have a valid signature. Yes, that makes sense, and it's more than what I read in Doug's articles, "simpl

[ietf-dkim] Re: An overview of cryptographic protocols to prevent spam

Amir Herzberg wrote: [http://eprint.iacr.org/2005/329.pdf] About 640 KB PDF. it cannot be displayed by AcroReader 3.0 (obscure problem to extract an embedded font). Bye, Frank ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: New DKIM threat analysis draft

Jim Fenton wrote: > By "envelope-based" I presume you mean SPF, Sender ID > Framework, and/or CSV. JFTR, Sender ID minus PRA is SPF, and PRA isn't envelope based. > We should not create a normative dependency on any of > these in the DKIM specs Most definitely, that would result in some "downre

[ietf-dkim] Re: DKIM BOF -- draft charter and agenda

Barry Leiba wrote: > Does this reflect what most of us think? You have something like draft-kucherawy in the "once the primary goals are met" section, that's fine. What about draft-dkim-pkix-00 ? I'm only asking, I can't judge it. > Does it adequately explain what we're trying to do, and > not

[ietf-dkim] Re: New DKIM threat analysis draft

Douglas Otis wrote: > Path registration and DKIM? NAK. We're talking about technical differences, and if Jim mentions this at all he'll probably pick the aspect "works independent of SMTP everywhere" adding "unless some idiot mangled the DATA in transit beyond repair" detail. In other words DKI

[ietf-dkim] Re: over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

Dave Crocker wrote: > We should make sure that there is a reasonably clear view of > priorities for preservering installed base... or not. My idea would be "like TLS and SSL": A future "IETF checker" must handle valid "legacy signatures", but a "legacy checker" might be unable to handle all vali

[ietf-dkim] Re: over-the-wire (in)compatibility between pre-IETFDKIMand (eventual) IETF DKIM

Hector Santos wrote: > The SMTP specs has it written in STONE that Validation of the > MAIL FROM is not required, hence the #1 basis for the SMTP > spoofing problems and reason we are trying to find something > to AUGMENT SMTP to secure the transaction. Well, of course I disagree with this assert

[ietf-dkim] Re: list config, was Admilistrivia question

[EMAIL PROTECTED] wrote: > Well if we made it an rss feed instead http://dir.gmane.org/gmane.ietf.dkim might have what you want. Bye, Frank ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: Admilistrivia question

Hector Santos wrote: > Some list servers will force a Reply-To: header in the > distribution to point to the mailing list address. Horrible. Hopefully DKIM will put an end to all these unnecessary manipulations of 3rd parties, it's bad enough when one user (not here) inserts a Reply-To list manu

[ietf-dkim] Re: over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

Stephen Farrell wrote: > This time in BoF chair mode. Nice new draft about it: http://ietf.org/internet-drafts/draft-narten-successful-bof-00 > Discussing things like "kludges", "infinite improvements", > "rubber stamp" etc is just not productive for either > supposed "side". Yes, apparently t

[ietf-dkim] Re: SSP and Sender header field

william(at)elan.net wrote: > 1. It changes the originator entirely to From and now instead >of using Sender header field value (as per RFC2822) to >decide cases of multiple From addresses, the first one in >From header field is used? That would be a step backwards, with more than one

[ietf-dkim] Re: DKIM BOF agenda

Dave Crocker wrote: > It means that a substantial constituency from industry can > organize to solve a serious problem, can develop > interoperable implementations, can agree that the mechanism > is an important component to solving that problem, can obtain > supportive evaluations as to the natur

[ietf-dkim] Re: SSP and Sender header field

Earl Hood wrote: > IMHO any design and policy decisions that rely on particular > MUA rendering behaviors is a mistake. +1 Besides some "popular" MUAs (on the wrong side of 2049 ;-) show the Sender. Maybe it's ambiguous, but not obscure. > a signer can bind to Sender, From, Resent-Sender, etc

[ietf-dkim] Re: SSP and Sender header field

[EMAIL PROTECTED] wrote: > If a bad actor sends me a mail from a non DK compliant domain > and he tags the mail with a hash compiled to decode as being > from eBay, the sending IP would not match? My idea was a phisher using his own throw-away-DKIM-domain of the day, pretending to be a mailing l

[ietf-dkim] Re: Should DKIM drop SSP?

Douglas Otis wrote: > Can you acknowledge the trade-off and defend this choice? I'm more interested in your choice, DKIM without SSP. Your vision is some kind of reputation system, e.g. you know that N are good guys. Therefore you want to accept anything that's really from N. If it com

[ietf-dkim] Resent-nit (was: Should DKIM drop SSP?)

Douglas Otis wrote: > Allow the DKIM SSP policy assertion be referenced from the > header associated with the domain that "introduced" the > message (Resent-Sender, Resent-From, Sender, or From), and > not the domain associated with the originator (From). Terminology issue: (2)822 uses "originat

[ietf-dkim] Re: is this a problem or not?

Stephen Farrell wrote: > If the above is possible, how should/can it be avoided? Never ever sign anything that is already signed. Or at the very minimum don't "drop" signatures. It's the point of DKIM to find some "accountable" party as near to the sender/originator/author (pick what you like)

[ietf-dkim] Re: is this a problem or not?

Douglas Otis wrote: > Removing or over-writing signatures (as reviewed in the > multiple signature section of my threat review) would ensure > the list does not expose other domains to replay abuse. The header is user territory, end-to-end, nobody in transit has to modify or remove a single bit i

[ietf-dkim] Re: is this a problem or not?

Earl Hood wrote: > With DKIM policy controled by the domain owner, and not the > mailbox users, a mailbox user may be held "hostage" by the > domain owner on how the mailbox user can use their account. If I can't use "my" [EMAIL PROTECTED] (or similar vanity host [EMAIL PROTECTED] constructs) whe

[ietf-dkim] Re: is this a problem or not?

Earl Hood wrote: > the end-user may have little "real" choice. That's the time when being support@ must be interesting. For unrelated reasons I've done that (new address) once, took me almost a year, and in two cases I never managed to replace the old address (it still works, but I check it ra

[ietf-dkim] Re: SSP and Sender header field

Jim Fenton wrote: > A lot of list software is broken then Most definitely. But no show stopper for a DKIM WG. Instead of h=Subject:From:Date:Content-Type:Content-Transfer-Encoding you could pick something else: Message-ID, Date, Content-Type, and From should survive mailing lists (I'm not sure

[ietf-dkim] Re: is this a problem or not?

Earl Hood wrote: > It is worth noting that this scenario relies on ISPs that > either do not do DKIM signing or utilize relaxed policies. They could also offer addresses in various subdomains with different "protection" schemes. If they're not interested in upgrading their software they could st

[ietf-dkim] Re: Review of draft-fenton-dkim-threats-01

Eric Rescorla wrote: >> If I see a message which is DKIM signed by iecc.com and >> iecc.com is on my "DKIM white-list" this is pretty useful >> info right? [...] > The scenario you cite is likely of *some* utility but > it's not clear how much, or if it exceeds the cost of > implementation and des

[ietf-dkim] Net abuse (was: opaque-identifier scaling)

JFTR, if something like this hits my inbox I'd treat it as net abuse no matter what it's experimental or standards track status might be: | DomainKey-Trace: U=http://domainkeys.sourceforge.net; V=$Revision: 1.4 $; | h=::12::562:2::2:3:44:31:2:63:23:27:16

[ietf-dkim] Re: opaque-identifier scaling

Douglas Otis wrote: > SSP is the Son of Sender-ID Protocol. More like a stepsister. ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: DKIM proposed charter tweak

[EMAIL PROTECTED] wrote: > A domain is a public IP Class or Address assigned by a > registrar to an individual or company. Not all domains have an IP, some even have no MX. They might still send or receive a message/rfc822 somehow. > Sending domain is the IP Class or Address that sent the > mes

[ietf-dkim] Re: DKIM h= tag - Defauilt or required headers?

Hector Santos wrote: > I thought I have read somewhere a few months back that the > default list of signing headers is all headers, but I don't > seem to find this reading. Maybe I just assumed it. http://tools.ietf.org/html/draft-delany-domainkeys-base-03#page-16 (sorry, I just love to play wi

[ietf-dkim] Re: DKIM h= tag - Defauilt or required headers?

Hector Santos wrote: > From: > To: > Subject: > Date: Everybody and his dog insert tags at the begin of the Subject, a special kludge might help: Input: Subject: Re: 12345678 Note 8 and sign: Output: Subject: [Fun-list] Re: 12345678 Subject: ***SPAM*** R

[ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated

Dave Crocker wrote: > pointers to the presentations being made in today's BOF. A jabber log is now also available: http://www.xmpp.org/ietf-logs/[EMAIL PROTECTED]/2005-11-07.html ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: Change the SSP o= to use words, break out 3rd party?

Tony Hansen wrote: > table of possible policies: > sending mail signature3rd partycurrent > 1 allowed unspecified unspecified NONE > 2 allowed nevernever > 3 allowed neverallowed > 4 allowed optional never?/WEAK > 5 allowed

[ietf-dkim] Re: Quick meeting notes for saag

[EMAIL PROTECTED] wrote: > Excellent jabber log ACK. it was fun to read it while it was created. My personal interpretation of Sam's comments: A BCP for draft-hutzler-spamops-05 might help with anything DKIM produces. Bye, Frank ___

[ietf-dkim] certain forms of spoofing (was: DKIM charter)

william(at)elan.net wrote: >>> together, these will assist receiving domains in detecting >>> (or ruling out) certain forms of spoofing as it pertains to >>> the signing domain. > "certain forms of spoofing" - very vague But true. And IMO not "vague", the spec. will explain which forms of spoof

[ietf-dkim] Re: DKIM charter

Barry Leiba wrote: > updating RFC 2821 is out of scope, and anyone who > participated in DRUMS will understand why. It should be also clear for others. It's the "BAR" in FUBAR... > We want to finish the DKIM work in 2006, not in 2016. Let's hope that at least draft-hutzler will be ready to b

[ietf-dkim] Re: Threat analysis kickoff

Jim Fenton wrote: > For "countermeasures", I'd like to declare out-of-scope the > use of independent mechanisms such as SPF and CSV; I think > those apply more-or-less equally to all. Add DNSBLs and MTAMARK for a more or less complete 2821-zoo ;-) That's kind of obvious, only independent 2822 mec

[ietf-dkim] Re: DKIM DNS record types

Hallam-Baker, Phillip wrote: > You cannot support two record types. It is either or. The SSP part is short enough to be mirrored in SPF, either inline as "modifier", or as its own record using the same record type 99. The key is a different issue, it's rather long, about 342 B64 characters for 2

[ietf-dkim] Re: DKIM charter

[EMAIL PROTECTED] wrote: > The only problem I have with SPF is a possible licensing > nightmare wrt Microsoft. *_Please_* don't confuse SPF with PRA. You don't need any license for v=spf1 (or any kind of spf2.0 excl. spf2.0/pra). SPF is an open standard from an SPF's POV or an "experiment" fro

[ietf-dkim] Re: Threat analysis kickoff

Jim Fenton wrote: > In some cases (2821-zoo) it appears you agree Yes, in other words, if DKIM is all you have - either as "signer" or as "checker" - it must still make sense. > in others it appears that you are describing new threats Not really, I just like your idea to sort the threats by pro

[ietf-dkim] Re: DKIM DNS record types

wayne wrote: >> The SSP part is short enough to be mirrored in SPF, either >> inline as "modifier", or as its own record using the same >> record type 99. > I think this would be A Bad Idea because neither of the DKIM > records have a required magic number at the beinning of the > record. Addin

[ietf-dkim] multi-From (was: SSP security relies upon the visual domain appearance)

Stephen Farrell wrote: >> The "From:" header should not be signed if it contains more >> than one sending address. > Exactly. Or whatever the correct variant might be e.g. I > think I'd prefer "don't sign at all if there's >1 From > address" so that we have fewer chances for verifier > misinterpr

[ietf-dkim] Re: Domain Ownership

Douglas Otis wrote: > Sending messages where the From header field indicates the > message's author is not exploiting or abusing the domain of > the author's email-address. In that caae you have a Sender or Resent-* header field with a "Purported Responsible Address", or it's a mailing list, or s

[ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Arvel Hathcock wrote: > the list of domains running DKIM is over 35. I'll exceed > your "< 100" by the time I'm done writing this message. That's fine, and as we know about 1,000,000 domains and 10 independent interoperable implementations are good enough for "experimental". 3 steps or 4 steps

[ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Mark Delany wrote: > I presume your 1,000,000 domains reference is a humorous > allusion. Of course, about an "experiment" trying to set new records wrt the length of the accompanying IESG note, at least half of it about another experiment. As long as nobody claims to "embrace and extend SSP" no

[ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Arvel Hathcock wrote: > I now have a list as a result of my 200 customer sampling > last night that is 300+ domains. Tnx for info - most of the mails I get are spam because I read mailing lists behind a mail2news gateway online as "news", and therefore I "see" only what the bad guys do. So far t

[ietf-dkim] Re: Pre-picking one solution

Douglas Otis wrote: > DKIM should be seen as aspect of the SMTP transport. IBTD. Trying to find any feature in DKIM not covered by the existing SMTP schemes (MTAMARK, CSV, SPF, but not PRA) it's _independence_ of SMTP that fascinates me in DKIM. All you need is the header, a piece of software,

[ietf-dkim] Re: The Value of Reputation

Douglas Otis wrote: > dangerous open-ended policies as seen with SPF. (Very bad.) Define "open-ended": I've no idea what you're talking about, or rather if it's NEUTRAL you're wrong. And for your favourite "pure DKIM" I'd like to know what it's good for: As an example, what exactly could say I

[ietf-dkim] Re: The Value of Reputation

Stephen Farrell wrote: > there will be a time when the group should be focusing on > the policy stuff, but its just not yet. For now we ought be > focusing on the threats draft. s/now/tomorrow/ after the WG is chartered... ;-) I think I've now got Doug's terminology of "closed" vs. "open", it 's

[ietf-dkim] Re: Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP)

Jim Fenton wrote: > When a message is received with a valid signature, the signer > is acknowledging that the message came from or through them. > [We should really work out the wording on this: do they "take > responsibility"? Are they "accountable"? But I digress.] No, it's a good point. Th

[ietf-dkim] Terminology (was: Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP))

upporting List header fields probably exist, and UAs not supporting the Return-Path at all would never be able to do anything remotely related to RfC 3834. > The reason I say "Typically the 2822-From" is that it's my > belief that most users will point to it and say "It&#

[ietf-dkim] Re: Terminology

> (Sam) > (Bill) Sorry ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

Stephen Farrell wrote: > "Policies can be open or closed. Open policies define a set of > conformant messages and are silent about other messages. Closed > policies define the set of conformant messages and other messages > do not conform to the policy. > If a domain owner publishes an open

[ietf-dkim] Re: one more comment I forgot...

Stephen Farrell wrote: > Jim Fenton wrote: >> - If broken signatures are seen as worse than the lack of a >> signature, it will serve as a disincentive to signing >> messages: potential signers might not want to do so if they >> risk having their messages downgraded if they pass through >> an MT

[ietf-dkim] open-ended threats (was: [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt])

Douglas Otis wrote: >>> [...] Any "open" policy exposes the email-address domain >>> owner to unjustified complaint traffic. >> No more than could happen today. I don't see any reason why >> complaints will rise that couldn't happen right now. > The mechanism directs complaints to the email-add

[ietf-dkim] Re: Terminology

Jim Fenton wrote: >> the use of multiple terms creates an architectural >> separation of authority that is not reflected in real life. > I was reacting to what limited consensus I saw, rather than > to the architectural issue. If there is support for the use > of AdMD instead, I'm happy to use t

[ietf-dkim] Re: DKIM and mailing lists

Stephen Farrell wrote: > *none* of the I-Ds listed on the tools page [1] are official > DKIM WG drafts. Yes, they'd start with draft-ietf-dkim-*. Besides you'd know if you or Barry approved the -00 and appointed the editors. > the others remain, for now, as individual submissions (and > I'm no

[ietf-dkim] Re: DKIM and mailing lists

Douglas Otis wrote: > The From header may then need to have multiple addresses > introduced, where the first email-address would be that of > the mailing-list. NAK. > It may also require that the From email-address be moved > entirely into the body of the message and replaced with the > email-a

[ietf-dkim] Re: DKIM and mailing lists

John Levine wrote: > Our lives would be simpler if everyone would mail only in > ways that matched our favorite simple security model Sure, but where some practice is far beyond anything found in an RfC it's okay to say "broken". > disparaging real mail sent in inconvenient ways as "forging" > i

[ietf-dkim] Re: DKIM and mailing lists

Hallam-Baker, Phillip wrote: > There is an RFC that describes a bunch of mailing list > headers but I can't find it/ -v please, I don't see the relation to Doug's speculations about what mailing lists might do. You're not talking about RfC 4021, or are you ?

[ietf-dkim] Re: DKIM and mailing lists

Douglas Otis wrote: > Modifying the message is already a common practice by > list-servers and resigning a modified message may not > overcome restrictions imposed by a From email-address > policy. Then it's not more the original message, they could send it as "digest" (multipart/digest, a single

[ietf-dkim] Re: DKIM and mailing lists

Jim Fenton wrote: >> --- 1/0/0 >> -The list server adds a signature. >> -does not remove the existing signature,/ >> -does not modify the message [...] > If I want to treat certain messages preferentially, perhaps > because they come from the ietf-dkim mailing list, I'd like > to m

[ietf-dkim] Re: DKIM and mailing lists

Mark Delany wrote: >> I think we're in trouble if the list signs something that is >> already signed. [...] > a signed List-ID proves it came via the List that I've > subscribed to. An unadorned List-ID could, shall we say, be > forged. So far it was my impression that DKIM tries to establish som

[ietf-dkim] WEAK (was: DKIM and mailing lists)

Hector Santos wrote: > As an author of a list server, I prefer to STRIP the > signature when allowed to avoid tampering with the many > options already offered to the list owner. If you tamper with the message that's your best choice. But ordinary lists don't tamper with messages, they redistrib

[ietf-dkim] Re: WEAK

Hector Santos wrote: > Just to be clear, I was referring with screwing around with > all the existing options that a sysop traditionally desires > in mailing list based distributions. My desire to screw around with echomail was somewhat limited to the "reduced seen-by lines" Traditionally sys

[ietf-dkim] Re: Message Replay Abuse and Acceptance of a Signature

Douglas Otis wrote: > A Low Administrative Solution Insensitive to High Latency: > Just as email domains check lists when deciding to receive a > message, they now also check a list to decide whether to > sign, or perhaps even send a message. > With this paradigm, as a best practice, to ensure

[ietf-dkim] Re: Message Replay Abuse and Acceptance of a Signature

Douglas Otis wrote: > The DKIM signature however indicates the AdmD providing > initial access and not just the last hop. Your X + Z example sounded like Z getting X's newsletters directly (MON X to MRN Z). For that case reducing it to the one critical hop where one of X's MTAs determined one of

[ietf-dkim] Re: DKIM and mailing lists

Douglas Otis wrote: > The proposal for the 'w=?' parameter is to identity three > roles. The MSA, mediator, and MDA. An MSA probably knows what it is, also if it delegates the signing to an additional "mailout" MTA. I'm not sure about mediator vs. MDA, do they always know what they are ? Is th

[ietf-dkim] Re: Attempted summary

Stephen Farrell wrote: > - SSP was suggested as being a useful check to make during > subscription processing. (Although there was no feedback on > the suggestion, or else I missed it.) When I talked about "SSP of the day" I had that in mind. The SSP might change. If that would require to chang

[ietf-dkim] Re: draft-ietf-dkim-threats-00 Unreasonable estimate of impact from a highly probable exploit

Douglas Otis wrote: >> 4.1.5. > The Very High was used to make a point. Just High would be > fine. Your point is clear. What you say is that MONs shouldn't sign mails if they have no MoU with the (final) MRN to protect this signature. Otherwise the bad guys abuse this signature in a replay a

[ietf-dkim] Re: draft-ietf-dkim-threats-00 Misstatement of the DKIM mechanism

Stephen Farrell wrote: > Looks much better to me +1 > though I had no problem with the original. That was a bit vague, Doug's proposal is IMO clearer. Bye ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: How mailing lists mutate messages

Hector Santos wrote: > I think you are underestimating the flip side - receivers > won't bother with implementing DKIM verification. DKIM > Signatures - valid, broken or otherwise, without a concept > that is essentially a "permission or authorization to sign > verification" concept, has little

[ietf-dkim] SSP accelerators (was: How mailing lists mutate messages)

Douglas Otis wrote: >> I also worry about the expectation of lists looking at >> policy - it's going to be many many years before a signer >> can expect their policy to be looked at by a significant >> majority of list s/w. In the intervening years they will >> be able to advertise as restrictive

[ietf-dkim] terminology (was: DKIM and mailing lists)

Douglas Otis wrote: >> And do you really mean MDA, not maybe MRN ? > The MDA signature role could encompasses any receiving MTA > within the receiving AdmD. I am not sure if that is the > same as the MRN. I mentioned MRN because checking is better done at the border in the case of a reject, a

[ietf-dkim] Re: Attempted summary, SSP again

John Levine wrote: > I'm increasingly getting the impression that we don't really > understand the semantics of SSP. If a domain uses SSP to say > that it signs everything, and a message from that domain has > both the domain's signature and someone else's, is that OK? > I can easily imagine in

[ietf-dkim] New Issue: Misleading figure in 1.1 (was: Attempted summary, SSP again)

Hector Santos wrote: > ProcessB() - SSP lookup > - Message Arrives > - OA SSP Policy lookup >- EXCLUSIVE >- Two Signers found --> REJECT > I would think ProcessB() is more ideal, more efficient and > 100% DKIM/SSP compatible, and more importantly with a > rejection

[ietf-dkim] Re: Attempted summary, SSP again

Hector Santos wrote: > "! All mail from the entity is signed; Third-Party > signatures SHOULD NOT be accepted in lieu of an > entity signature >>Yes, that's what it's supposed to mean. > So in other words, for the EXCLUSIVE (o=!) policy. > DO NOT ACCEPT IF AN OA

[ietf-dkim] Re: canonicalization

John R Levine wrote: > One thing I do wonder is whether there are predictable header > changes, e.g. do forwarders try to do us a favor and rewrap > headers or re-code subject and address comments in our out of > the MIME codes. I suppose some experiements are in order, > along with beefing up so

[ietf-dkim] Re: Attempted summary, SSP again

Hector Santos wrote: > keep in mind that is not specification Okay, but at this time of the WG work I still think that the concept of "re-signing" is utter dubios. Without "re-signing" it's simple to pick the "right" signature for checking, and your algorithm "exclusive and less or more than o

[ietf-dkim] Re: canonicalization

John Levine wrote: >> Do you have a mail2news -> news2mail scenario in your >> tests ? That could be one of the more "interesting" >> cases. > I find it hard to't imagine one that wouldn't break any > sensible canon scheme. It's the same issue as mailing > list software. Not necessarily, "mes

[ietf-dkim] Re: New Issue: 4.2 needs new Attack Item: Inconsistent Signature vs Policy Attacks

Tony Hansen wrote: > 1) always look for the SSP, as Hector suggests; > 2) add information to the DKIM DNS record to indicate that >the SSP should always be looked for; > 3) incorporate the SSP information into the DKIM DNS record; > or 4) some other ways I'm not thinking of at the moment. Do

[ietf-dkim] OT o=. (was: New Issue: 4.2 needs new Attack Item: Inconsistent Signature vs Policy Attacks)

Jim Fenton wrote: >> Example loopholes: >> 1) A message is signed, but the SSP indicated a "o=." (No >>mail expected from domain). > There has been a lot of discussion of "o=." but it's not > actually in the current version of the SSP draft. Did you confuse this with WEAK ? Or do you have

[ietf-dkim] Re: New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

John Levine wrote: > How long did it take people to realize that the majority > of mail that passes SPF is spam? Is that already so ? I've expected that much later in the game for SPF and DKIM. And of course also for PRA and CSV. Whatever "PASS" from unknown strangers is a waste of time, witho

[ietf-dkim] Re: the Internet is inherently insecure

J.D. Falk wrote: > Are there truly no bounds on the threat analysis? Of course there are, as Phil explained it yesterday: Get some "WG rough consensus" and a GO from the proto-shepherd (or from the real shepherd, Russ), submit to IESG, get GenArt review nits and IESG [Discuss], fix that in a ne

[ietf-dkim] Re: New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

Hector Santos wrote: > 80-84% of all SPF policies seen by SMTP receivers are NEUTRAL > (relaxed) policies. Among these, atleast 60%, are Bad Actors > exploiting a RELAXED domain policy. It's not possible to "exploit" NEUTRAL, as it's by definion the same as NONE. What's so unusual with 60% spam

[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

Douglas Otis quoted: > ,--- > | 1. Introduction > | ... > | Once the attesting party or parties have been established, the > | recipient may evaluate the message in the context of additional > | information such as locally-maintained whitelists, shared reputation > | services, and/or third-party

[ietf-dkim] Re: now up on roundup tracker

Eliot Lear wrote: > It's not perfect It throws an error when I try to look at it, apparently it thinks that UAs MUST send an Accept-Language header field - that's not the case with my UA. > you shouldn't hear from the tool I got an ACK for the one message with "Subject: New Issue". If that was

[ietf-dkim] Re: Measurement Results on Deployment Ratio of Domain Authentications

Kazu Yamamoto wrote: > Just FYI. Thanks, also discussed in... Bye, Frank ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

Douglas Otis wrote: > Often "block-listing" is a method of ostracism used for > email sources that have been identified as violating a > trust. s/a method of ostracism// > Email sources being block-listed often have not adhered > to an "opt-in" criteria for the distribution of bulk email. There

[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

Douglas Otis wrote: > Of course other identifiers can be assessed. This statement > however indicates assessments associated with the signing > domain can not include elements of the message envelope. Okay, but it's IMO unnecessary to talk about it in Jim's draft. He has it already in 1.2: | Th

[ietf-dkim] Re: fyi- current open issues

Douglas Otis wrote: > I also noticed that clicking upon the links that you give > require a sign-in. Did I miss your explanation on how that > works? User ietf password ietf used to work for me before they screwed up their certificates in some non-netscape-SSL3-compatible way For the root certif

  1   2   3   4   5   >