RE: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

hat the user actually sees would have been a primary goal? Scott Kitterman ___ ietf-dkim mailing list ietf-dkim@mipassoc.org http://mipassoc.org/mailman/listinfo/ietf-dkim

RE: [ietf-dkim] a bit of philosophy on working group productivity andscope

ence, and validity of signatures. Unless we can get to at least that, then I don't think we've accomplished anything useful. Scott Kitterman ___ ietf-dkim mailing list <http://dkim.org>;

Re: [ietf-dkim] a bit of philosophy on working group productivity andscope

other than in the case of a valid signature for an identity that is identical to the body From:. If all I want is a cryptgraphically valid signature, there are other ways to get it. I thought your thread was about what is the minimum we can accomplish that will be worthwhile. I

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

ived and know that it came from a designated source. > The main benefit of DKIM is that a validating agent can know where the > message came from. This is more reliability than email source > identification has ever had before. > > >How do folks feel about this ch

Re: [ietf-dkim] linkage between "originator" and "handling agent"

DKIM needs it's mechanism for doing this. Combining results from multiple techniques is a separate question that ought to be tackled by somebody. I have thoughts on how to do that, but they aren't on topic for this list. Unfortunately, I'

Re: [ietf-dkim] linkage between "originator" and "handling agent"

Douglas Otis wrote: On Aug 15, 2005, at 6:09 PM, Dave Crocker wrote: Equally I am wondering whether it is not distracting from the core DKIM authentication work to emphasize this particular requirement prior to deployment of a signing/validating mechanism. In other words, it is starting to

Re: [ietf-dkim] linkage between "originator" and "handling agent"

ional information, the question in my mind is what can you do with it? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] linkage between "originator" and "handling agent"

Douglas Otis wrote: On Aug 17, 2005, at 7:18 AM, Scott Kitterman wrote: Douglas Otis wrote: There are two ways to look at DKIM goals- 1- A mechanism that provides an accountable domain for the message. A number of features are available as a product of the accountable domain. a

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

ld seem to be essential. I'm curious what those of you who have been arguing against inclusion of SSP in the working group effort would define as the bad act that DKIM will prevent in the absence of a sender policy of some kind. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

go about these things in the working group output, but that detailed designs aren't necessary. Perhaps not even that. Perhaps the WG just does the SMTP part? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

ncept extremely surprising and difficult to fathom. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

SM wrote: At 09:08 18-08-2005, Scott Kitterman wrote: It isn't entirely clear to me exactly where DKIM wants to live in this chain. Is it a tool for the SMTP server to reject messages from SMTP clients that are doing something unauthorized? Is it a tool for post-acceptance filterin

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

ine if the patient isn't dying already. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

based blacklist if someone doesn't like my mail? What benifit is being offered that I should risk that? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Sat, 2005-08-20 at 20:29 -0400, Scott Kitterman wrote: So, given that view, as a sender, what's in it for me? Sounds like all I get is more spam reports and maybe on a domain based blacklist if someone doesn't like my mail? What benifit is being offered tha

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

lve a problem that I personally have very little interest in. I am curious if I'm alone in that regard? If that's all DKIM is for, then I've got better ways to spend my spare time. Thanks, Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Sun, 2005-08-21 at 13:35 -0400, Scott Kitterman wrote: Douglas Otis wrote: This also, I think, brings to light an important reason for the divergence in our perspectives. I believe that you are saying that you think DKIM's usefulness is primarily in suppo

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

hat I think we absolutely need to avoid is a charter that just does that base and defers SSP to some future effort. The charter needs to include both. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 22, 2005, at 8:35 AM, Scott Kitterman wrote: To summarize, you think that SSP is dangerous, won't do what it's proponents claim, and can't be fixed. Thus SSP and it's ilk shouldn't be dealt with by the working group. You believe that

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 22, 2005, at 11:02 AM, Scott Kitterman wrote: So to narrow my previous attempt at a summary, you think that domain-wide assertions cannot be accurately made for mail addresses, but that it can for HELO/EHLO? Accuracy is not the issue. While a domain-wide

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 22, 2005, at 3:23 PM, Scott Kitterman wrote: Douglas Otis wrote: Binding a mailbox-address or mailbox-domain to a domain signature is not a goal, it is a mechanism. What is the intended goal? What is the selection process? What level of administrative

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote: Once it gets to the MUA, it's too late. I want to reject the message during SMTP (after DATA, but before OK). Your notion seems to consider mailbox address authorization will be the principle mechanism us

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

ry close, the one with or the one without SSP or are you saying that's true of either one? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

appears to me that there are those who do not want SSP for reasons that aren't clear to me. I'd rather get SSP in scope once and for all and not have to have the scope arguement again after base is published. Same starting line for both, not necessarily the

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

they aren't the same? If I didn't send you a message, how can you hold me accountable for you having gotten it? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

[EMAIL PROTECTED] wrote: --- Scott Kitterman <[EMAIL PROTECTED]> wrote: So in your view, what is the accountability entity for a message sent to you, the MUA/MSA/MTA that signed the message or the MTA that sent you the message if they aren't the same? One definition of acc

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

nistic Sender Signing Policy (I'm not saying the current draft is perfect) for an uncertain, undesigned, and undocumented automated abuse reporting infrastructure. You get to call this 'simple' from a DKIM perspective only by declaring all this complexity external to DKI

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 24, 2005, at 7:00 AM, Scott Kitterman wrote: It seems to me that your proposed approach is anything but simple. It would appear to me that you want to trade the direct, obvious, near- term benifits of a defined deterministic Sender Signing Policy (I'm not s

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 24, 2005, at 11:14 AM, Scott Kitterman wrote: What you are asking is what won't SSP accomplish. It's difficult to answer those questions before the design work is done. So lets quick arguing about if it should be done. Get it done and see what i

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

Douglas Otis wrote: On Aug 24, 2005, at 12:10 PM, Scott Kitterman wrote: As I said before, let's just agree that there is work yet to be done on SSP and quite arguing about if it should be done. We are back to using the term 'it' again as if 'it' has special

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

king group takes. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

that was DKIM's sole role. I certainly said that it (meaning forgery protection) is the application that's of most interest to me. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Apology

It has been brought to my attention off-list that some consider my postings here inappropriate. I'm sorry. That hadn't been my intent. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

. I don't think that building a better whitelist justifies the effort of DKIM. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

t. This would provide a clean break so that if there are incremental deliveries of documentation to the standards process, then the incremental threat assessment is already done. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

he signing domain? Also, does DKIM provide an authentication platform or an authorization platform? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

horize are specific terms of art and I'm trying to understand where DKIM stands in relation to them. DKIM-SSP attempts to at least partially fill that gap. Is that right? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] Re: Forgery complexities

authorized by the mailbox domain, but that it's ability to give a positive assurance of authorization is limited? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

RE: [ietf-dkim] Revised threat model

e presented to > a human reader the authentication mechanism currently defined is NOT > designed to prevent impersonation of other identifiers that a human > reader might rely on. In particular DKIM does not provide protection > against the use of 'cousin' or 'lookalike' addresses in a phishing > attack. > Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

No we should not. Is there anything in this line of reasoning that isn't duplicative of the last time we went through your view on this in August? Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

On 10/26/2005 07:24 pm, Douglas Otis wrote: > On Oct 26, 2005, at 3:32 PM, Scott Kitterman wrote: > > No we should not. > > > > Is there anything in this line of reasoning that isn't duplicative > > of the last > > time we went through your view on this in

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

Doug, So is it your view that DKIM roughly at it stands, with SSP and without your "Opaque identifier" is fatally flawed and shouldn't go forward? Scott K ___ ietf-dkim mailing list http://dkim.org

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

On 10/27/2005 05:49 pm, Douglas Otis wrote: > On Oct 27, 2005, at 1:52 PM, Scott Kitterman wrote: > > Doug, > > > > So is it your view that DKIM roughly at it stands, with SSP and > > without your > > "Opaque identifier" is fatally flawed and should

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

On 10/28/2005 08:11 pm, Frank Ellermann wrote: > 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

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

On 10/29/2005 01:29 pm, Earl Hood wrote: ... > Problem B2 also raises another potential problem, something I believe > Doug has been trying to point out. 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 t

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

tainly lowers the perceived value of the product). Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

On 10/31/2005 12:08, Earl Hood wrote: > On October 31, 2005 at 12:41, Scott Kitterman wrote: > > > For some businesses (like the mybank example that has been raised), > > > such restrictions are desirable, and probably justifiable. But if > > > ISPs and other

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

se of the word, DKIM does need some kind of reputation system to be effective. I think it's important to get SSP right (we can do that after there is a working group). Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

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

y question whether there is value in detecting > falsehood seems more a question for philosophy rather than engineering. I > think it's a distraction that we should just dismiss. Yes. Please. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] A plea to the silent amongst us

On 11/01/2005 15:41, Arvel Hathcock wrote: > I'm new to the IETF process but I've had the amazing good fortune of having > excellent guides. They've encouraged me to speak up when I've had > something to say and I want to pass that advice on to whomever might be > lurking on this list or who may b

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

ebody else's domain, not mine. So, yes, spammers buying another domain is a good benifit from my POV. Scott Kitterman ___ ietf-dkim mailing list http://dkim.org

Re: opaque-identifier scaling (was: Re: [ietf-dkim] ebay / eboy)

On 11/01/2005 22:11, Douglas Otis wrote: ... > On a daily basis, our dynamic lists fluctuate in the millions, What is the antecedent of 'our' in this message? Scott K ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] SSP acceptance chart

On 11/02/2005 13:19, Douglas Otis wrote: ... > ...of no signature? This seems force the use of SSP and completely > ignore the reputation of the signing-domain, does it not? > That's a feature, not a bug. Scott K ___ ietf-dkim mailing list http://dkim.o

Re: [ietf-dkim] SSP acceptance chart

Doug, I don't imagine we are ever going to agree on this. I really don't understand your view of the world and I am pretty well convinced I never will. I do not think that adding another level of unpredictable heuristics to spam filtering and calling it reputation is a particularly good thin

Re: [ietf-dkim] Email-address independent of signing-domain DKIM charter

On 11/06/2005 17:35, Douglas Otis wrote: > On Nov 5, 2005, at 9:16 PM, Dave Crocker wrote: > > However, the best way to gauge this probably is for you to specify > > the text that you propose to have changed in the charter. > > While there appears to be some support for imposing a requirement > tha

Re: [ietf-dkim] Email-address independent of signing-domain DKIM charter

On 11/07/2005 14:09, Douglas Otis wrote: > On Nov 7, 2005, at 4:27 AM, Scott Kitterman wrote: > > On 11/06/2005 17:35, Douglas Otis wrote: > >> On Nov 5, 2005, at 9:16 PM, Dave Crocker wrote: > >>> However, the best way to gauge this probably is for you to specify &

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

On 11/07/2005 20:37, Douglas Otis wrote: > DKIM without SSP can be better than with SSP. Take out the SSP > approach, and there should be fewer concerns with respect to > potential impact, while there would not be any benefit lost. If > anything there would be greater benefits as this approach o

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

On Mon, 7 Nov 2005 19:01:40 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: > >On Nov 7, 2005, at 6:24 PM, Scott Kitterman wrote: > >> On 11/07/2005 20:37, Douglas Otis wrote: >> >>> DKIM without SSP can be better than with SSP. Take out the SSP >>> appr

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

On 11/09/2005 11:15, Douglas Otis wrote: > > On Mon, 7 Nov 2005 19:01:40 -0800 Douglas Otis <[EMAIL PROTECTED]> > > > > wrote: > >>DKIM without SSP provides an ability for Name-based white-listing of > >>transports. Name-based white-listing/reputation would not be prone > >>to IP address exploits.

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

On 11/10/2005 09:41, Douglas Otis wrote: > > On 11/09/2005 11:15, Douglas Otis wrote: > >> A verified signer for the message could improve the results of filtering > >> applications like Spamassassin. As this is your primary mechanism, > >> improving these applications would benefit you significan

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

On 11/10/2005 18:49, Douglas Otis wrote: > > On 11/10/2005 09:41, Douglas Otis wrote: > >> > No matter what you do with hueristics, you are only modulating an > >> > approach that will only ever be so good. What we need is more > >> > deterministic solutions and less dependence on heuristics. > >>

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

On 11/10/2005 20:34, Hector Santos wrote: > - Original Message - > From: "Scott Kitterman" <[EMAIL PROTECTED]> > To: > > > By the time you get to the MUA, IMO, the battle is over. > > SSP is an MTA level tool to solve an MTA level problem. I

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

Doug, I don't know that we're getting any closer to any kind of agreement. Given the request to focus on the charter, let's just let this thread end (I hear cheers in the distance I think). Scott K ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] SSP focus

On 11/11/2005 18:10, Dave Crocker wrote: > Folks, > > > Having said all of that, I am at a complete loss as to much of this > > debate. If SSP isn't formalized in this group then you can be certain > > that bi-lateral or non-standard forms will emerge in parallel to > > DKIM. Those "select" domain

Re: [ietf-dkim] DKIM charter

On 11/12/2005 11:07, Barry Leiba wrote: > Here it is, appended (not attached) below. > > Barry > ... I like this. I think it is good. Scott K ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM charter

On 11/13/2005 14:41, Tony Hansen wrote: > To get past the contentions around SSP, I'm wondering if we should > change the wording slightly, as follows. > > Tony Hansen > [EMAIL PROTECTED] > > Barry Leiba wrote: > > - > > DRAFT IE

Re: [ietf-dkim] DKIM charter

On 11/14/2005 18:25, Douglas Otis wrote: > On Nov 14, 2005, at 2:04 PM, Jim Fenton wrote: > > Barry, > > > >> DESCRIPTION OF WORKING GROUP: > >> > >> The Internet mail protocols and infrastructure allow mail sent > >> from one > >> domain to purport to be from another. While there are sometimes >

Re: [ietf-dkim] DKIM charter (Should DKIM directly prevent spoofing?)

On 11/16/2005 13:32, Douglas Otis wrote: >... Would that get the policy debate off the table? > > -Doug > No. Scott K ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM charter (Should DKIM directly prevent spoofing?)

On 11/16/2005 16:32, Douglas Otis wrote: > On Nov 16, 2005, at 12:47 PM, Stephen Farrell wrote: > >> A claim made in the charter of detecting spoofing depends upon a > >> comparison of the signing-domain with the email-address domain. > > > > There is no such absolute claim that I can see in the dr

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On 11/18/2005 22:18, Douglas Otis wrote: > On Fri, 2005-11-18 at 09:47 -0800, Douglas Otis wrote: > > On Nov 18, 2005, at 7:45 AM, Michael Thomas wrote: > > > And the title of this thread is bogus. > > I may have missed explaining how a binding approach removes the eye- > test. Consider binding i

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On Sat, 19 Nov 2005 07:27:10 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: >On Fri, 2005-11-18 at 22:29 -0500, Scott Kitterman wrote: >> >> That or the title of the thread is bogus. >> >> I could equally say if we were trying your approach something like Doug&#

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On 11/19/2005 14:50, Douglas Otis wrote: > You agree that SSP does not provide a mechanism to prevent spoofing > without reliance upon visual presentations... No. I said pretty much the exact opposite of that. Scott K ___ ietf-dkim mailing list http:/

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

Doug, I haven't seen anyone else jumping on the bandwagon for your approach. Rather than continue to bog down the discussion here, wouldn't it make more sense for you to go off and develop your draft and then submit it as an individual submission once DKIM-base is submitted? Scott K _

Re: [ietf-dkim] Expediting the threat analysis for -core

On Fri, 18 Nov 2005 08:12:32 -0800 Dave Crocker <[EMAIL PROTECTED]> wrote: >Folks, > >My impression is that the threat analysis for SSP is far, far more >challenging than for the core DKIM services. At the least, this is because >we understand SSP far less. > >This means that having the threat

Re: [ietf-dkim] Comments on the Threat Draft - draft-fenton-dkim-threats-01

On Sun, 20 Nov 2005 16:14:48 -0800 "Jim Schaad" <[EMAIL PROTECTED]> wrote: > Jim, > >I have some comments on this draft that I would like to make. > ... >F. Potential Extensions to the base document (I would prefer this to be >labeled as appendix rather than section of the document for clarity)

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On Sun, 20 Nov 2005 18:37:06 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: >On Sun, 2005-11-20 at 14:49 -0500, Scott Kitterman wrote: >> On 11/19/2005 14:50, Douglas Otis wrote: >> >> > You agree that SSP does not provide a mechanism to prevent spoofing >

Re: [ietf-dkim] SSP security relies upon the visual domainappearance

On Sun, 20 Nov 2005 19:24:35 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: >On Sun, 2005-11-20 at 15:44 -0500, Hector Santos wrote: > >> > How is a look-alike domain rejected by comparing the From and >> > signing-domains? >> >> Signature/SSP valid or invalid? >> >> invalid --> reject >> valid

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On Mon, 21 Nov 2005 07:50:25 -0800 Douglas Otis <[EMAIL PROTECTED]> wrote: >On Mon, 2005-11-21 at 10:12 -0500, Scott Kitterman wrote: > >> SSP doesn't do what it doesn't do. SSP is not and does not pretend to be >> the ultimate solution to phishing

Re: [ietf-dkim] SSP security relies upon the visual domain appearance

On 11/22/2005 18:15, Douglas Otis wrote: > As a child, you may have enjoyed the game of tic-tac-toe. Once you > better understood the game, you simply decide not to play. Yes, exactly. That's why I stopped responding to this thread. Doug, I haven't seen anyone object to you developing your

Re: [ietf-dkim] Re: The Value of Reputation

On 01/04/2006 14:20, Douglas Otis wrote: I really hate it that we are debating SPF on the DKIM list, but it seems unavoidable... > SPF and SSP will have similar problems. With SPF, you have pointed > out the RFC1123 5.3.6(a) issue that may cause those concerned with > the resulting disappearanc

[ietf-dkim] Let's get back to chartering/threats (was Re: SSP; Is it safe and fair?)

I think we've wandered pretty far afield here and I'm not going to follow. Don't take my lack of response for agreement. Scott K ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM and mailing lists

On 01/19/2006 15:50, Michael Thomas wrote: > Earl Hood wrote: > > On January 19, 2006 at 03:10, "Hector Santos" wrote: > >>Sender-Signing Policy (SSP): > >> > >> NONE (no policy) > >>o=? WEAK (signature optional, no third party) > >>o=~ NEUTRAL (signature optional, 3rd party allow

Re: [ietf-dkim] DKIM and mailing lists

On 01/19/2006 17:50, Michael Thomas wrote: > Scott Kitterman wrote: > > On 01/19/2006 15:50, Michael Thomas wrote: > >>Earl Hood wrote: > >>>On January 19, 2006 at 03:10, "Hector Santos" wrote: > >>>>Sender-Signing Policy (SSP): > >>

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

On 02/23/2006 12:16, Douglas Otis wrote: > On Feb 22, 2006, at 7:52 PM, Douglas Otis wrote: > > On Feb 22, 2006, at 6:47 PM, Hallam-Baker, Phillip wrote: > >> In rebuttal to Doug's point about not depending on the DNS > >> supporting longer key sizes, an ECDSA key that gives equivalent > >> strengt

Re: [ietf-dkim] Core algorithm support/use, draft text v2

the following cryptographic algorithms are specified: Deprecated: None Required: SHA-1, SHA-256 High strength: SHA-256 then could be easily revised at the point it becomes clear what the next high strength hash algorithm is or if SHA-1 is determined to be broken to the

Re: [ietf-dkim] Core algorithm support/use, draft text v2

On 02/27/2006 10:58, Hallam-Baker, Phillip wrote: > > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kitterman > > Might it be useful to break the exact crypto algorithm out > > into a separate (very short) RFC so that it can be revised as > > necessary? Something like:

Re: [ietf-dkim] Auth-Results open discussion forum

On 03/09/2006 17:10, Dave Crocker wrote: > Folks, > > There is now a list for pursuing the specific topic of the Auth-Results > specification. > > The mailing list is [EMAIL PROTECTED] > > To subscribe, go to: > > > The list is intended for

Re: [ietf-dkim] Concerns about DKIM and mailiing lists, etc.

no beneficial effect. > > So, as vigorously as you are arguing your position, I am not seeing how it > produces anything that will work in the real Internet. > > d/ This database that you insist is necessary for DKIM to be useful is pretty well by definition a reputation system. So, if as y

Re: [ietf-dkim] Concerns about DKIM and mailiing lists, etc.

On 03/16/2006 00:35, Dave Crocker wrote: > > This database that you insist is necessary for DKIM to be useful is > > pretty well by definition a reputation system. So, if as you say a DKIM > > signature has no value without a reputation system of some limited kind > > and reputation is out of boun

Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error

On 04/14/2006 10:36, Hector Santos wrote: > In section 6.2 "Get The Public Key, we have step #2 > > | 2. If the query for the public key fails to respond, the verifier > | SHOULD defer acceptance of this email (normally this will be > | achieved with a 451/4.7.5 SMTP reply code). > >

Re: [ietf-dkim] authentication result headers are an unsafe alternative

On 04/18/2006 14:18, Douglas Otis wrote: > On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote: > > From a protocol design perspective, I think the right answer is to > > design for the case where the receiving MTA/MDA will check the > > signature and record a result that, i

Re: [ietf-dkim] x= lets senders expire responsibility

On 04/14/2006 12:26, Douglas Otis wrote: > On Apr 14, 2006, at 5:56 AM, Hector Santos wrote: > >>> Unless it has help from the backend server, offline mail systems > >>> will not work very reliably when keys are being changed. > >> > >> Should DKIM require services beyond DNS for verification? > >

Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit

On 04/18/2006 15:43, Douglas Otis wrote: > On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote: > > I would not say that we shouldn't include DKIM protection beyond > > SMTP, but that whatever happens after delivery shouldn't distract > > us from the primary use c

Re: [ietf-dkim] Attempted text for x= with DSN considerations

Because if we put that in the spec then we've effectively gotten rid of x= because no one would use it then and that's what he wants perhaps? Scott K On 04/19/2006 18:54, [EMAIL PROTECTED] wrote: > Why would a verifyer refuse a message that had a value for x=? > "Verifiers MAY support checking

Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error

On 04/19/2006 23:51, Jim Fenton wrote: > Scott Kitterman wrote: > > There is another potential issue with this approach if we get to a > > dedicated RR type. While not an issue when using TXT, there are > > resolvers that will fail to respond when queried with an unknown RR

Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error

On 04/20/2006 09:53, Douglas Otis wrote: > On Thu, 2006-04-20 at 07:53 -0400, Scott Kitterman wrote: > > WRT your point, I agree. Perhaps we need to add another bit along the > > lines of, "If an email is deferred based on lack of response to the > > query for the publi

Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error

On 04/20/2006 18:53, Michael Thomas wrote: > Scott Kitterman wrote: > >On 04/19/2006 23:51, Jim Fenton wrote: > >>This points out another problem: if a verifier defers verification or > >>acceptance of a given message, it SHOULD maintain enough state so that > >&

Re: [ietf-dkim] Trust Annotation Support

On 04/26/2006 17:59, Douglas Otis wrote: > On Apr 26, 2006, at 12:32 PM, J.D. Falk wrote: > > On 2006-04-25 08:51, Douglas Otis wrote: > >> Well vetted sources can be indicated by the signer with some type > >> of notation or semaphore. > > > > So, the signer -- who is most often the sender -- ind

Re: [ietf-dkim] Draft minutes...

On Wednesday 12 July 2006 23:16, Tony Hansen wrote: > Resent-From: and Resent-Sender: would be signed only if present in the > header. It's perfectly legit for a forwarding system to add them (and > expected according to the specs), and if that forwarding server then > signs the message, those head

Re: [ietf-dkim] Draft minutes...

On Thursday 13 July 2006 14:29, Tony Hansen wrote: > Scott, please reread the appeal response note more carefully. It does > not denigrate Resent-*, but acknowledges that rfc822/rfc2822-compliant > systems were not required to follow the practice. (It's marked as a > SHOULD requirement.) Consequent

  1   2   3   4   5   >