Re: [ietf-dkim] DKIM Key Size Constraints

biting reasonable levels of security. Or is this something not to be asked? Ever since Edward Snowden revelations driven home by Barbara Honegger, it seems high time to not be sloppy about security. Especially when you don't know who to trust. Regards, Douglas Otis ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM Key Size Constraints

Dear Scott, Signatures normally offer options not easily supported by DKIM. One being use of a binary keys, rather than base64. Indeed shorter keys were a mistake. What other mistakes should be corrected? I can name a few. Regards, Douglas Otis On 5/11/15 10:06 AM, Scott Kitterman wrote

Re: [ietf-dkim] That weird i= is most probably EDSP

abuse reporting. It is absurd to expect large providers will review timestamps and logs to ascertain problem sources. Lack of standardization due to an unfounded fear this reduces user privacy simply misunderstood what is meant by the term opaque. What we have now

Re: [ietf-dkim] The problem with the DKIM design community

re processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards. See Section 8.15 for additional discussion. '--- Regards, Douglas Otis ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Weird i= in client mail

by DMARC with a lower failure rate, and then offer a BCP for use of 'i='. Regards, Douglas Otis ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] value-added DKIM-ish enhancements )was - Re: Weird i= in client mail)

On Jun 18, 2013, at 3:32 PM, Murray S. Kucherawy wrote: > > It needs a method of declaring its presence, such as an extra > header field or a special external query, but after that, it's free to > define anything it wants, including a public meaning for i= > > ATPS did exactly this. It m

Re: [ietf-dkim] value-added DKIM-ish enhancements )was - Re: Weird i= in client mail)

eir deceptive messages delivered to their victim's inbox. This problem is real. Regards, Douglas Otis ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

On 8/10/11 11:18 AM, Michael Deutschmann wrote: > On Mon, 8 Aug 2011, Douglas Otis wrote: >> The concept behind the TPA scheme was to enable services on behalf of >> senders that lack requisite staffing to support this level of policy >> effort when using open-ended third-part

Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

On 8/2/11 11:43 PM, Michael Deutschmann wrote: > On Mon, 1 Aug 2011, Douglas Otis wrote: >> This would be a safe method to extend policy without requisite two >> party coordination as currently expected by DKIM. > The problem is that for the majority of From: domains claimed

Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

On 7/28/11 2:03 PM, Mark Delany wrote: >>> DKIM should be viewed as a Work-In-Progress still missing a viable >>> policy layer. >> +1. But 5+ years WIP? :) It wasn't rocket science. > Well, 7+ years ago it was suggested that "Domain policy is nascent" > with the stated expectation that MARID would

Re: [ietf-dkim] Doublefrom, ADSP and mailing lists in perspective,

On 7/27/11 12:13 AM, Michael Deutschmann wrote: > I have one comment to make which ties together both my stance on Otis' > doublefrom crusade, and some reforms I have argued for in ADSP. > > Basically, at present the doublefrom trick is simply *unnecessary* for > someone trying to pass me a forged

Re: [ietf-dkim] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

On 7/22/11 7:09 AM, O'Reirdan, Michael wrote: > Chaps > > I would like to bring to your attention and solicit comments on the > following draft. > > http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 > > Thanks > > Mike O'Reirdan Mike, Indeed, abuse issues represent a cha

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/12/11 12:02 PM, Charles Lindsey wrote: > Essentially, my concern is that an implementor reading this section should > be able to infer the nature of the particular attack I have described (the > one where the signer is the BadGuy himself using a throwaway domain), > including spotting how and

Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-15.txt still permits deceptive DKIM results

8.15. Attacks Involving Extra Header Fields ... ,--- Agents that evaluate or apply DKIM output need to be aware that a DKIM signer can sign messages that are malformed (e.g., violate [RFC5322], such as by having multiple instances of a field that is only permitted once), or that become malformed in

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/8/11 4:43 AM, Alessandro Vesely wrote: > On 07/Jul/11 16:13, Dave CROCKER wrote: >> On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote: I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise Postel's statement, do we?) >>> You're either liberal in your application of the

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/7/11 3:21 PM, John Levine wrote: >> Will your "assume one more From than listed in h=" lead to failed >> verifications on messages that actually follow the advice in the RFC >> to list duplicate headers in their h= values? > The RFC also says you shouldn't sign messages that aren't RFC 2822.

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/7/11 10:09 AM, Pete Resnick wrote: > DKIM can only be "deployed to mount a > variety of attacks" if the recipient has already made the fatal mistake > of assuming that the existence of a cryptographically valid signature > *means* that the message is reliable and from a known "good" sender. St

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/6/11 3:30 PM, John R. Levine wrote: >> When DKIM signatures serve as a basis for acceptance, ... > Since they don't, can we skip the rest of the screed? In other words, when DKIM signatures serve a basis for acceptance, this would be an issue? The statement "they don't" contradicts preceding

Re: [ietf-dkim] Final update to 4871bis for working group review

On 7/6/11 9:31 AM, Barry Leiba wrote: > I actually like Charles's edits except for one paragraph, and, as a > participant, would be happy to change 8.15 accordingly. The one > problem paragraph is this one: > > On Wed, Jul 6, 2011 at 7:17 AM, Charles Lindsey wrote: > ... > Recall that, when m

Re: [ietf-dkim] Pete's review of 4871bis

On 6/30/11 9:53 AM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Charles Lindsey >> Sent: Thursday, June 30, 2011 7:05 AM >> To: DKIM >> Subject: Re: [ietf-dkim] Pete's review of 4871bis >>

Re: [ietf-dkim] Pete's review of 4871bis

On 6/29/11 11:49 AM, Pete Resnick wrote: > On 6/29/11 11:20 AM, Charles Lindsey wrote: >> I agree that 8.14 is poorly written (and it was even worse a while back). >> However, there most certainly IS an attack here, which is NOT the same as >> the related attack discussed in 8.15, and cannot be pre

Re: [ietf-dkim] Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

On 6/24/11 2:43 PM, Steve Atkins wrote: > On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote: >> >> Complaints from John, Dave, and Barry and others is likely and >> understandably out of fatigue. They just want the process to be over. >> We are now hearing there i

Re: [ietf-dkim] Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

On 6/23/11 8:24 AM, John Levine wrote: > In article<4e02ee24.2060...@gmail.com> you write: >> On 6/22/11 11:14 AM, Dave CROCKER wrote: >>> Folks, >>> >>> The bottom line about Doug's note is that the working group extensively >>> considered the basic issue of multiple From: header fields and Doug

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

On 6/23/11 8:34 PM, John R. Levine wrote: >>> I'm pretty sure that we have uniformly agreed not to attempt to do >>> MUA design, so, no, it doesn't. We have no idea what is displayed >>> in the message. We have no idea if the message will ever be >>> displayed at all. >> Ian, >> >> John is rig

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

On 6/23/11 2:52 PM, John R. Levine wrote: >> Acceptance policies and results for DKIM MUST align with >> what is being displayed in the message. > I'm pretty sure that we have uniformly agreed not to attempt to do MUA > design, so, no, it doesn't. We have no idea what is displayed in the > messa

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

On 6/23/11 5:16 AM, Ian Eiloart wrote: > > On 21 Jun 2011, at 19:47, Douglas Otis wrote: >> Hi Rolf, >> >> The general goal of DKIM was to establish a domain relationship as >> a trust basis for acceptance. DKIM was also to allow incremental >> deployment wi

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

On 6/17/11 1:05 PM, Rolf E. Sonneveld wrote: > Dear all, > > after some off-list conversation with Dave he suggested I might want to > send this to the list. I apologize in advance if this message does not > apply to you. I also apologize if you get this message twice, when you > are subscribed to

Re: [ietf-dkim] EAI and 8bit downgrades

On 5/22/11 10:38 PM, John R. Levine wrote: >> Specify MUST, but clarify that this is just for now and may be revisited >> at a later time -- for example, if the SMTP protcol design community ever >> backs down and accepts DJB's approach to the 8-bit message problem >> (

Re: [ietf-dkim] Certifying the DKIM public key?

On 5/19/11 2:32 PM, Rolf E. Sonneveld wrote: > Hi, all, > > recently someone asked me whether it would have any added value if the > DKIM public key, which is stored in DNS, would be 'certified' in some > (yet to be determined) way by a 3rd party like VeriSign, Thawte etc.? My > first reaction was,

Re: [ietf-dkim] Ticket #17 & Ticket #24 and allowance of deceptive results

On 5/8/11 10:28 AM, Dave CROCKER wrote: > On 4/27/2011 2:21 AM, SM wrote: >> I thought that the advancement of the specifications from Proposed to >> Draft would not be too much of an effort as there are existing >> implementations of RFC 4871. But then, this is the DKIM WG. > > The effort is prima

Re: [ietf-dkim] Protocol layering / Software vs. Protocol

On 5/6/11 6:28 AM, Charles Lindsey wrote: > On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba > wrote: >> Doug says... >>> This can *only* be achieved by some mandatory test within the Verifier. >> Not at all; that's exactly Dave's point in discussing the difference >> between the protocol and the so

[ietf-dkim] Ticket #24

The intended content of this ticket by Charles Lindsey, Rolf Sonneveld and my self is as follows: ,--- We were asked by Barry to provide an agreed text to resolve the "multiple header" problem, for consideration by the WG. The attack arises when some header (typically From:) which is supposed to

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

On 5/5/11 9:40 PM, Hector Santos wrote: > Dave CROCKER wrote: > I don't think this is correct. The signer creates and signs the i= value, so it's not "garbage", >> >>> By "garbage", I mean "not guaranteed to have any useful meaning". >> >>> So, I believe, it's essentially meanin

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

On 5/5/11 1:34 PM, Michael Thomas wrote: > On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: >> Technical: The AUID is an unvetted value. The local-part and the subdomain >> could be garbage. It's inappropriate for a security protocol to return a >> possibly false value in the context of sayin

Re: [ietf-dkim] Protocol layering / Software vs. Protocol

On 5/5/11 1:24 PM, Barry Leiba wrote: > Dave says... >> In terms of working group process, one line of criticism demands >> re-opening >> (and, apparently, reversing) the work of the Update (RFC 5672). I >> haven't seen >> any working group consensus to do this nor any industry feedback >> indi

Re: [ietf-dkim] Protocol layering / Software vs. Protocol

On 5/4/11 10:01 AM, Dave CROCKER wrote: > Folks, > \ > In terms of working group process, one line of criticism demands re-opening > (and, apparently, reversing) the work of the Update (RFC 5672). I haven't > seen > any working group consensus to do this nor any industry feedback indicating > th

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 5/3/11 4:25 PM, Murray S. Kucherawy wrote: > I might even go so far as to say returning that From: field is dangerous > since it is not confirmed by anything, so DKIM (which is an authentication > protocol) returning data that can't be validated, even if it was signed, is > quite possibly ask

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 5/3/11 4:25 PM, Murray S. Kucherawy wrote: >>> Why does the output of DKIM need to include something when the >>> consumer of that output already has that information? >> Because a consumer should/must not have to re-do the work of the DKIM >> verifier. Or put it differently: a consumer is just

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

On 4/30/11 10:37 PM, Murray S. Kucherawy wrote: > > -Original Message- From: Hector Santos > > [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM > > To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: > > [ietf-dkim] Output summary - proposing ODID "Originating Do

Re: [ietf-dkim] Output summary

On 4/28/11 12:00 PM, Rolf E. Sonneveld wrote: > Right. I strongly believe in the layered approach. However, that's > exactly the problem here. Like with IP and SMTP and any layered > application, the upper layer is dependent on what the lower layer > provides it with. If DKIM only enforces: > > d=

[ietf-dkim] Ticket #17 is not a duplicate

Sorry for the repeated message, but the wrong subject line was used. Barry, Ticket #17 was listed as a duplicate of Ticket #4 http://trac.tools.ietf.org/wg/dkim/trac/ticket/17 This is not correct! The result of Ticket #4 was a change that simply said: ,--- Internationalized domain names MUST be

Re: [ietf-dkim] ADSP stats

Barry, Ticket #17 was listed as a duplicate of Ticket #4 http://trac.tools.ietf.org/wg/dkim/trac/ticket/17 This is not correct! The result of Ticket #4 was a change that simply said: ,--- Internationalized domain names MUST be converted as described in Section 2.3 of [RFC5890] to "A-Labels" '--

Re: [ietf-dkim] Ticket #17

On 4/27/11 2:21 AM, SM wrote: > Hi Doug, At 18:43 26-04-2011, Douglas Otis wrote: > > Not validating input creates a bigger mess when used in conjunction > > with RFC5336bis. As such, it seems unfair for the DKIM WG > > operating within the Security area to close and then ha

Re: [ietf-dkim] Ticket #17

On 4/26/11 2:03 PM, Dave CROCKER wrote: >> Detecting Fake A-Label use is essential for the safe introduction of UTF-8 >> throughout email > DKIM does not have the task of validating input. In addition, the nature of > DKIM's crypto algorithms provides quite a bit of validity checking inherently.

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

On 4/25/11 9:29 PM, Dave CROCKER wrote: > On 4/25/2011 9:18 PM, Murray S. Kucherawy wrote: > >> Double listing in the "h=" tag can not fully mitigate risks > >> related to appended header fields when messages are signed by a > >> different domain than the domain found in the appended From > >> hea

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

On 4/25/11 9:18 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Douglas Otis >> Sent: Monday, April 25, 2011 6:33 PM >> To: ietf-dkim@mipassoc.org; Barry

[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // Attacks Involving Additional Header Fields

Although DKIM is reviewed within IETF's security area, input validation by DKIM remains dangerously neglected. DKIM's Introduction indicates it can be implemented independent of clients. As such, few assumptions are safe in how users become aware of DKIM's intended protections or acceptance p

[ietf-dkim] draft-ietf-dkim-rfc4871bis-07 // A-Label use

Although DKIM is reviewed within IETF's security area, input validation by DKIM remains dangerously neglected. References of RFC5890 rather than RFC3490 and removal of the ToASCII function once again neglects proper input validation. Detecting Fake A-Label use is essential for safe introducti

Re: [ietf-dkim] ISSUE: non-ascii header text

On 4/21/11 5:25 AM, John R. Levine wrote: >> Use of A-labels within header fields supporting UTF-8 is a bad idea. > Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no > header fields in a compliant message can contain UTF-8. I don't know > why you keep repeating this uttetly

Re: [ietf-dkim] ISSUE: non-ascii header text

On 4/20/11 5:02 PM, John R. Levine wrote: >> Internationalized domain names MUST be encoded as Non-Reserved LDH, >> A-Labels as described in RFC5891, or equivalent U-Labels. > > Repeating this bad idea doesn't make it a good idea, > > Besides being a bad idea on its own merits, this would without q

Re: [ietf-dkim] ADSP stats

On 4/20/11 2:50 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org >> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis >> Sent: Wednesday, April 20, 2011 2:40 PM >> To: ietf-dkim@mipassoc.org >>

Re: [ietf-dkim] ADSP stats

On 4/20/11 1:25 PM, J.D. Falk wrote: > On Apr 20, 2011, at 4:36, wrote: >> Indeed lack of support for 3rd party signers was where I gave up any >> interest at all in adsp > As I remember it, there was (or appeared to be) consensus to get ADSP out > there for testing by the entities it might work

Re: [ietf-dkim] ISSUE: non-ascii header text

On 4/20/11 7:09 AM, John R. Levine wrote: >> Is there anything that actually needs to be done with a UTF-8 header that >> is not covered already in our DKIm spec.? > No, it's fine, so long as we make my proposed changes that clarify that > the bits of domain names in the DKIM-Signature: header (d=

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

On 4/19/11 3:35 PM, John R. Levine wrote: > Sorry, this message makes no sense. The IETF has been working on > non-ASCII domain names and e-mail for over a decade, and we are > certainly not going to do random things that ignore that effort and > the many RFCs that describe the use of IDNs in t

Re: [ietf-dkim] Issue: Repeated headers

On 4/19/11 2:37 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Charles Lindsey >> Sent: Tuesday, April 19, 2011 12:56 PM >> To: DKIM >> Subject: [ietf-dkim] Issue: Repeated headers >> >> Y

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

On 4/15/11 7:25 PM, John R. Levine wrote: >> Instead, conversion to A-label form, or any other special encoding >> required by a particular name-lookup protocol, should be done only by >> an entity that knows which protocol will be used (e.g., the DNS >> resolver, or getaddrinfo() upon deciding to

Re: [ietf-dkim] ADSP stats

On 4/18/11 12:33 PM, Murray S. Kucherawy wrote: > This working group spent a huge amount of blood, sweat and tears working on > attempts to create a viable policy layer, and after all that, ADSP is what we > managed to get consensus to do. Lots of other alternatives have been > proposed, and no

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

On 4/15/11 8:59 PM, Michael Deutschmann wrote: > On Fri, 15 Apr 2011, Douglas Otis wrote: >> In addition, verifiers MUST >> ensure the presence of multiple singleton originating header fields >> do not provide a valid signature result. >> --- >> >> Not includ

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871bis-06.txt // Input requirements

http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.8 ,--- DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322 ],

Re: [ietf-dkim] Working Group Last Call on 4871bis// A-label requirement

On 4/13/11 12:23 PM, Dave CROCKER wrote: > On 4/13/2011 12:21 PM, John R. Levine wrote: >>> i'm also tempted to suggest using months in a different language, >>> with enero or >>> Januari... >> >> If you're going to change it, change it to 一月 or يناير > > not after i just got done trying to avoid

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 4/11/11 2:06 AM, Charles Lindsey wrote: > I think you may have missed the point of my 'bob' example. It would have > been clearer if I had said: > > 3. From = al...@example.com i=mal...@example.com d=example.com. > > Where mallet is some disgruntled example.com employee posing as Alice. A > hum

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 4/7/11 10:08 AM, Murray S. Kucherawy wrote: >> 2) Can we use i= for a purpose of reputation as a) it's meaning is >> > loosely defined, b) it is there already (cf (1) ) c) it has been used >> > by some to differentiate different emails in the same domain. > You could, if you know that the use

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 4/6/11 3:06 PM, John Levine wrote: > > For there to be reasonable semantic meaning, it must be > > understandable. > > > > 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. > > Quite

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 4/4/11 1:59 PM, Steve Atkins wrote: > On Apr 4, 2011, at 1:21 PM, Franck Martin wrote >> I think you are thinking it as only a DNS issue. >> >> But creating a sub-domain, means that the from needs to match too, therefore >> you may need to remap all your corporate email addresses from j...@iecc

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 4/4/11 7:47 AM, John R. Levine wrote: > ... kludges to work around short term deployment problems are rarely > a good way to do long term standards development. The problems go > away, but the kludges don't. Why are A and records used to locate mail servers and not limit discovery to j

Re: [ietf-dkim] Open issues in RFC4871bis

On 4/1/11 2:08 PM, Murray S. Kucherawy wrote: > > In our conference call with Jim, Dave and I are left with three things > that need discussion in the working group before we request a working > group last call on it. > > > The first, and biggest, is the removal of “i=” that Jim has proposed > s

Re: [ietf-dkim] Security Area Directors

On 3/19/11 5:17 AM, Barry Leiba wrote: > With Stephen's becoming an Area Director (replacing Tim Polk), Stephen > and Sean have reshuffled the working group responsibilities, thus: > > Sean: dkim, emu, isms, msec, pkix, tls, ltans, ipsecme > Stephen: abfab, dane, hokey, kitten, krb, nea > > As you

Re: [ietf-dkim] DKIM software needed

On 3/3/11 4:07 AM, Mark Martinec wrote: > On Thursday March 3 2011 12:18:45 Charles Lindsey wrote: >> Having just had a deluge of bogus messages from Twitter, all allegedly >> DKIM-signed, I think I need a working DKIM checker (my ISP has not >> implemented DKIM ckecking so far). >> I have not the

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted

On 2/22/11 4:08 AM, Alessandro Vesely wrote: > On 22/Feb/11 00:31, Douglas Otis wrote: >> Any message containing multiple orig-date, from, sender, reply-to, >> to, cc, message-id, in-reply-to, and subject header fields will not >> produce a valid signature. See Section 5.3.

Re: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03 submitted

On 2/16/11 9:18 AM, Dave CROCKER wrote: > Folks, > > A new version of rfc4871 has just been posted as an I-D. A diff is > attached. > > The draft is available at: > > > > This version does NOT contain text that resolves two outstandin

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

On 1/13/11 9:10 AM, Dave CROCKER wrote: > Folks, > > Summary of the reactions posted so far...[1] > > Some of the postings asked questions or expressed confusion about some > procedural or technical or wg scope "fact" issues that have already been > answered; so they are not covered here. Also, th

Re: [ietf-dkim] SPF/DKIM complementary failure scenarios?

On 11/24/10 11:38 AM, Mark Delany wrote: > On Wed, Nov 24, 2010 at 10:57:58AM -0800, Douglas Otis allegedly wrote: >> On 11/24/10 9:01 AM, Dave CROCKER wrote: >>> On 11/23/2010 3:14 AM, Ian Eiloart wrote: >>>> Actually, they're complementary. In places w

Re: [ietf-dkim] SPF/DKIM complementary failure scenarios?

On 11/24/10 9:01 AM, Dave CROCKER wrote: > > On 11/23/2010 3:14 AM, Ian Eiloart wrote: > > Actually, they're complementary. In places where DKIM fails > > (mailing lists rewriting messages), SPF can succeed. And in places > > where SPF fails (message forwarding), DKIM can succeed. > > This assert

Re: [ietf-dkim] A comprehensive DKIM verification specification will not violate protocol layers.

Murray argued singleton header checks to qualify DKIM signatures violates protocol layering. SMTP messages are exchanged in two parts, a header and a body section. The header section should conform with RFC5322, and the body should conform with RFC2045. RFC2047 and RFC2231 define header encod

Re: [ietf-dkim] DKIM Japan has been set up

On 11/22/10 9:25 AM, Steve Atkins wrote: > ... > > But if you're trying to stop mail that's being sent by a bad > actor... give up on this approach, as it's trivial to add a "fake" > DKIM header that will not authenticate. > > Also, it may discard quite a bit > of legitimate email, if any of your u

Re: [ietf-dkim] Getting resolution on the "double header" issue

On 11/12/10 9:35 AM, Charles Lindsey wrote: > On Thu, 11 Nov 2010 17:55:55 -0000, Douglas Otis > wrote: > >> Once one DKIM verification vendor includes these necessary checks that >> suppress DKIM PASS, and another vendor does not, DKIM implementations >> are no lon

Re: [ietf-dkim] Getting resolution on the "double header" issue

rfc4871bis-02 Introduction: ,--- ... DKIM: o is compatible with the existing email infrastructure and transparent to the fullest extent possible; o requires minimal new infrastructure; o can be implemented independently of clients in order to reduce deployment time; o

Re: [ietf-dkim] Necessary Verifier Actions to mitigate exploitation of trust established through DKIM signatures.

Append to Section 6 Verifier Actions: It is not reasonable to assume a message is in compliance with RFC5322. To mitigate trivial exploitation of trust established by DKIM signatures, messages having multiple header fields for "orig-date", "from", "sender", "reply-to", "to", "cc", "message-id"

Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)

On 11/3/10 6:28 AM, Alessandro Vesely wrote: > On 02/Nov/10 22:58, Douglas Otis wrote: > > On 11/2/10 11:47 AM, Alessandro Vesely wrote: > > > > If big-bank.com asserts a restrictive policy, the relevant author > > address should make that message fail ADSP verifi

Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)

On 11/2/10 11:47 AM, Alessandro Vesely wrote: > On 01/Nov/10 22:56, Douglas Otis wrote: > > If big-bank.com asserts a restrictive policy, the relevant author > address should make that message fail ADSP verification, since no > author domain signature can be found. Apparently, R

Re: [ietf-dkim] Proposal for new text about multiple header issues

On 10/30/10 3:05 AM, Alessandro Vesely wrote: > On 28/Oct/10 03:36, Douglas Otis wrote: >> I'll repeat the example given previously. The multiple listing of a >> header in the h= parameter can not mitigate exploitation of DKIM PASS >> results where a valuable domain is

Re: [ietf-dkim] Proposal for new text about multiple header issues

On 10/27/10 8:53 PM, Hector Santos wrote: > The lack of focus for 1st party domain protection is what allowed this > issue to fall through the crack. We tried our best to make DKIM a > pure signing mechanism with an open ended "implicit policy" of > unrestricted resigners, remolding the specs with

Re: [ietf-dkim] Proposal for new text about multiple header issues

On 10/25/10 9:36 PM, Murray S. Kucherawy wrote: > > On Monday, October 25, 2010 2:48 PM, Douglas Otis wrote: > >> 1) During the handling of a message in conjunction with a DKIM > >> result that indicates a valid signature, consider as valid only > >> those fie

Re: [ietf-dkim] Proposal for new text about multiple header issues

On 10/24/10 9:05 PM, Murray S. Kucherawy wrote: > > Here’s my proposal for a section in Security Considerations to talk > about the malformation issues that have been discussed on the list. > This is an addition to -02 directly and does not continue from any of > the other proposals. > > 8.14 Ma

Re: [ietf-dkim] the usual misunderstanding about what DKIM promises

On 10/23/10 12:25 PM, Barry Leiba wrote: > On Fri, Oct 22, 2010 at 10:13 PM, Hector Santos wrote: >> John Levine wrote: > DKIM makes no statement about the validity of a "sender" address. > d/ I guess I should have said Author address. >>> DKIM makes no statement about the validity of

Re: [ietf-dkim] Proposal for new text about multiple header issues

On 10/25/10 2:12 PM, Steve Atkins wrote: > On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote: >> Isn't the more interesting attack a signature from some throwaway domain >> that covered a matching From: but also contained a From: indicating some >> high-value phish target? > Not really, no.

Re: [ietf-dkim] double header reality check

On 10/20/10 3:19 PM, Murray S. Kucherawy wrote: > [] > I totally agree that that's an important distinction to make, document, > highlight and shout from the rooftops. But... Does it *have* to use RFC2119 > normative language? > > Here's maybe a better way to frame the question: Should we empowe

Re: [ietf-dkim] detecting header mutations after signing

On 10/20/10 8:10 AM, Ian Eiloart wrote: > --On 19 October 2010 11:35:53 -0400 "John R. Levine" > wrote: > >> True, but there already are UI designs that indicate when a From > >> header is DKIM verified. > > > > So you're saying that all a spammer has to do is to put on a > > throwaway domain's

Re: [ietf-dkim] double header reality check

On 10/20/10 10:55 AM, Murray S. Kucherawy wrote: > I think a lot of this discussion conflates protocol specification > with implementation. I'm focused on the former. I maintain that > including wording intimating that a DKIM implementation is > non-compliant if it fails to do mail format vali

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/20/10 7:27 AM, Alessandro Vesely wrote: > On 20/Oct/10 13:23, Charles Lindsey wrote: >> The scam I have described involves the use, by the phisher, of a >> DKIM-signed (by himself) email with two From: headers, which is intended >> to fool verifiers into not spotting that the first signature

Re: [ietf-dkim] double header reality check

On 10/19/10 5:08 PM, Murray S. Kucherawy wrote: > Since the issue is an attempt to fool users, those seem to me to be in the > same family as the other thing we're talking about. And none of them have > anything at all to do with DKIM. Disagree. It is TRUST being established by DKIM that is bei

Re: [ietf-dkim] detecting header mutations after signing

On 10/19/10 1:45 PM, Dave CROCKER wrote: > On 10/19/2010 1:33 PM, John R. Levine wrote: > > Re Security Considerations, it's better than nothing, > > Not necessarily. > > The current issue is part of a much larger one. We will not be > dealing with that larger set of security details because it

Re: [ietf-dkim] Data integrity claims

On 10/18/10 4:15 PM, Murray S. Kucherawy wrote: > > On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote: > > > > Should the charter of a security related protocol need to > > anticipate minor modifications to a verification process, that > > appears essential fo

Re: [ietf-dkim] Data integrity claims

On 10/18/10 12:18 PM, Murray S. Kucherawy wrote: > >> This is no more presumptuous than expecting that MUAs will adapt > >> to consume the output of DKIM as it stands now. > > In another message I indicated that I don't presume either, but > assert that there's no middle ground; they will or t

Re: [ietf-dkim] How MUAs render mail

On 10/18/10 6:49 AM, Wietse Venema wrote: > Mark Delany: >> My problem is that if some valuable domain like paypal sends me a >> bunch of bits that I or my MUA or my MTA ties to paypal.com then the >> end goal of DKIM is, IMO, that those bunch of bits I "see" are the >> ones that paypal sent. No

Re: [ietf-dkim] Data integrity claims

On 10/15/10 4:50 PM, Murray S. Kucherawy wrote: >> On Friday, October 15, 2010 2:30 PM, Douglas Otis wrote: >> >> Citing a layer violation makes little sense. With DKIM, the message >> body does not stand on its own. DKIM binds elements related to the >> RFC5322

Re: [ietf-dkim] Data integrity claims

On 10/16/10 7:16 AM, Dave CROCKER wrote: > On 10/16/2010 2:39 AM, Mark Delany wrote: > > My problem is that if some valuable domain like paypal sends me a > > bunch of bits that I or my MUA or my MTA ties to paypal.com then > > the end goal of DKIM is, IMO, that those bunch of bits I "see" are >

Re: [ietf-dkim] detecting header mutations after signing

On 10/15/10 2:10 PM, Wietse Venema wrote: > MH Michael Hammer (5304): > >> On Friday, October 15, 2010 11:59 AM, Bill Oxley wrote: > >> > >> Well a broken signature is morally equivalent to unsigned so Im > >> not sure of the potential harm... > > > > And this is where I angst. In all the discus

Re: [ietf-dkim] detecting header mutations after signing

On 10/15/10 8:40 AM, Mark Delany wrote: >>> h=from:from:subject:subject:to:to:cc:cc:mime-version:mime-version:list-id:list-id? >> Yes, it does. The only question is to devise normative statements >> correctly, e.g. MUST duplicate "From", SHOULD duplicate the rest. >> >> This is _not_ a kludge.

Re: [ietf-dkim] ISSUE: 3.6.2.1 - Working with other TXT records

On 10/15/10 10:58 AM, Barry Leiba wrote: > On Fri, Oct 15, 2010 at 1:27 PM, Hector Santos > wrote: > > Murray S. Kucherawy wrote: > > > >>> I appreciate the desire to put more information in there to > >>> help, but we really can't be writing a tutorial on managing DNS > >>> records. > >> > >>

  1   2   3   4   5   6   7   8   9   10   >