Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Dave Crocker wrote: Sorry, Mike, but that particular line of argument isn't applicable here.> Hence, it was pure academic exercise. Working group specs are subject to semantic change up to the point of IESG approval. Anyone deploying code based on a spec prior to that moment is taking a we

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Stephen Farrell wrote: Michael Thomas wrote: Simply stated, as the draft is currently worded, the simple body canonicalization will be immune to additions *and* deletions of of CRLF's at the end of the body in all cases. The proposed change to the normative behavior, on the other

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Dave Crocker wrote: Michael Thomas wrote: Mark Delany wrote: I don't think the "lateness" has anything to do with it since there are bugs in either direction and no one even noticed until recently. It can hardly be the case that it is breaking much to apply the fix.

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Stephen Farrell wrote: If the two fixes differ in how they affect signature robustness then that is a significant difference. Can you elaborate? (Sorry, I'm not a mail person so I don't get all the nuances of what can happen to the last few bytes of a message.) Simply stated, as the draft is curr

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Mark Delany wrote: Michael Thomas wrote: Yes. In my mind there's a substantial difference in clarifying an edge condition Last call is intended to find bugs. We found a bug, let's fix it. Last call ended 4 months ago. I don't think the "lateness" has anything to do

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

[EMAIL PROTECTED] wrote: BTW: we're *waaay* past last call here. This text has been here for time immemorial. All I propose we do is clarify the meaning of what is actually in the draft now surrounding a corner case. I think the bar should be a lot higher for actually changing the text to

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Stephen Farrell wrote: "The canonical text can be thought of as a virtual representation of the actual input. In particular, a body without any lines (ie, a null body) is canonicalized as a single CRLF, which its canonical length set to 2 (l=2). Note that the canonical length still applies to

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

octets (if specified, otherwise all octets) are presented to the hashing algorithm. Mike Ok, so we've this and we've that. Who's volunteering to craft new text for the document? S. Michael Thomas wrote: Tony Hansen wrote: Michael Thomas wrote: Tony Hansen wrote: That&

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Tony Hansen wrote: Michael Thomas wrote: Tony Hansen wrote: That's why the issue was raised. I firmly believe that we *intended* to canonicalize each of these cases into the empty body Well, that may or may not have been the intent, but the current spec does say that and

Re: [ietf-dkim] canonicalized null body and dkim

Eric Allman wrote: --On December 15, 2006 7:58:39 AM -0800 Michael Thomas <[EMAIL PROTECTED]> wrote: The thing that I've seen is that at the very least sendmail will strip a body with a single CRLF to a null body in its output stage; I would not be surprised to hear that oth

Re: [Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

Tony Hansen wrote: That's why the issue was raised. I firmly believe that we *intended* to canonicalize each of these cases into the empty body Well, that may or may not have been the intent, but the current spec does say that and it's my claim that what the current spec is doing is *usef

Re: [ietf-dkim] canonicalized null body and dkim

Tony Hansen wrote: Mike Thomas and I have been having a conversation about how empty message bodies should be canonicalized. Go and reread section 3.4.3. There is text in there that was added to handle the case of a message body that has been transmitted using CHUNKING and doesn't have a CRLF at

Re: [ietf-dkim] New Issue: Applicability of SSP to subdomains

Scott Kitterman wrote: On Fri, 08 Dec 2006 15:23:58 -0800 Michael Thomas <[EMAIL PROTECTED]> wrote: Eliot Lear wrote: Jim, I'm not sure I fully understand the threat. If an attacker is attacking from mail.example.com, then mail.example.com must have been delegated

Re: [ietf-dkim] New Issue: Applicability of SSP to subdomains

Eliot Lear wrote: Jim, I'm not sure I fully understand the threat. If an attacker is attacking from mail.example.com, then mail.example.com must have been delegated to first in example.com. Otherwise, there would be no lookup for an SSP record in mail.example.com, right? I had thought the

[ietf-dkim] new issue: requirement to enumerate receiver side benefits of SSP?

Dave Crocker wrote: Michael Thomas wrote: Hi, One of the things I noticed from recent discussions is that we need to have clarity in SSP on what, exactly, qualifies as a valid signature for "I sign everything". Michael, To carry your point farther than I suspect you intend:

Re: [ietf-dkim] Re: Role of Sender header as signing domain

Charles Lindsey wrote: On Wed, 29 Nov 2006 13:44:30 -, Scott Kitterman <[EMAIL PROTECTED]> wrote: SSP needs an identity to key off of to lookup a policy. The agreed identity for that is 2822.From for several reasons: But that is wholly back to front. The SSP policy to look up initially

[ietf-dkim] new issue: clarify i= vs. SSP

Hi, One of the things I noticed from recent discussions is that we need to have clarity in SSP on what, exactly, qualifies as a valid signature for "I sign everything". This guidance is not in dkim-base (purposefully), but I believe that we had intended i= to provide that clarity. In any case, we

Re: [ietf-dkim] Re: Role of Sender header as signing domain

Scott Kitterman wrote: On Tuesday 28 November 2006 12:36, Frank Ellermann wrote: In that point I agree with Hector: The problems of braindead MUAs are out of scope. Except that any solution that starts out with upgrade every MUA in the world (except I think GNUs) is probably not g

Re: [ietf-dkim] Re: ISSUE: Better definition of "DKIM signing complete" required

Hector Santos wrote: It depends on how mixed failure and success is interpreted. DKIM-BASE says as long as one signature is valid in a multi-signature message, the message is valid. Failures MUST be ignored as if it was never signed. There is something not very kosher with that. That's inco

Re: [ietf-dkim] Re: "I sign everything" yes/no

Eliot Lear wrote: Charles, Forgive my sloppy message, but netnews *is* a separate case, and I'm not going to go there with you on this list (others already have). Mail / Unicast mechanisms require either 3rd party authentication or the message to flow back to the 1st party through some authe

Re: [ietf-dkim] Re: ISSUE: Better definition of "DKIM signing complete" required

Jim Fenton wrote: If this is the case, I suggest you ask for an issue to be opened on the issue tracker requesting the change you have in mind, such as "SSP should also be queried for the {Sender, Resent-From, Resent-Sender, List-ID, Reply-To, ...} header fields. It would be helpful to also e

Re: [ietf-dkim] Re: ISSUE: Better definition of "DKIM signing complete" required

Stephen Farrell wrote: Frank Ellermann wrote: As they SHOULD NOT be used on _irregular_ mailing lists. Maybe more cases, we should ask the 'lemonade' folks what they think about this "I (defined by 2822-From) sign everything DKIM-complete" construct. Good idea. Do you know who to ask? If so

Re: [ietf-dkim] Collection of use cases for SSP requirements

Wietse Venema wrote: Hallam-Baker, Phillip: FOR DKIM BASE: We have three possible outcomes: Definitely Genuine, Definitely Fake and Undetermined [We can if people think there is value further break down Undetermined according to probability but bear with me] My understanding is that D

[ietf-dkim] ssp req 02 available

until they hit the repository... http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-02.html http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-02.txt Mike, I'll try to come up with a summary in a bit... ___ NOTE WELL: This list op

Re: [ietf-dkim] Re: Issue 1382

we leave it open for now. Scott K On Tuesday 17 October 2006 16:11, Michael Thomas wrote: From the requirements standpoint, I'd just assume that we avoid this topic. There are some pretty deep engineering and political tradeoffs and absent actual proposals, it's really hard to imagine t

[ietf-dkim] Re: Issue 1382

From the requirements standpoint, I'd just assume that we avoid this topic. There are some pretty deep engineering and political tradeoffs and absent actual proposals, it's really hard to imagine that a requirements draft would finesse this topic correctly. Mike Scott Kitterman wrote:

Re: [ietf-dkim] New Issue: New resource record type

From a requirements standpoint, I'd just assume we not go into this level of detail. The high level bits of deterministic number of lookups and other things seem fairly uncontroversial, but the engineering/deployment considerations of the RR problem require a lot more detail and/or experimental e

Re: [ietf-dkim] 1359: ssp-requirements-01 // Outsource First Party Signing concerns extended

Stephen Farrell wrote: william(at)elan.net wrote: No-one spoke against that, so please consider this closed/rejected. You're quite wrong. If so, apologies. Can you point me at the mail archive please? (I mean since we discussed this in the jabber session and I posted the summary.)

Re: [ietf-dkim] Using mailing list to work through open issues

Stephen Farrell wrote: If there were support for something like that I'd be willing, but I suspect it might also generate opposition and as Dave said it puts a big burden on the moderator. I'd like us to stick with the jabber sessions for the next few weeks and we can discuss it in San Diego (a

Re: [ietf-dkim] Jabber session this Thursday 1500 UTC

Steve Atkins wrote: (I've also not found a decent jabber client for OS X that's stable and has the functionality I'd expect. Suggestions welcome.) I'm using Adium which after I figured out that jabber.org was the root cause, worked fine. Mike ___

Re: [ietf-dkim] Jabber session this Thursday 1500 UTC

Just as a note, I'm becoming more convinced that jabber.org accounts are hosed when it comes to connecting to jabber.ietf.org... try making a different account on some other server if you're having problems. Eliot pointed me to jabber.psg.com, but I don't know if it's polite to extend the cattle

Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP - Suggestion to Remove this.

Arvel Hathcock wrote: 10. The Protocol MUST NOT be required to be invoked if a valid first party signature is found. Hector, doesn’t it say exactly what you want it to say? It says that the protocol must not require invocation when valid first party signatures are found. It doesn'

Re: [ietf-dkim] New Issue: ssp-requirements-01 // Negative Commentary corrections

Douglas Otis wrote: On Sep 22, 2006, at 1:56 PM, Michael Thomas wrote: The intention here is not to validate each point of the positive and negative commentary, but to bring the issues to the fore so that the entire scenario and requirements it generates can be understood in the context

Re: [ietf-dkim] New Issue: ssp-requirements-01 // Negative Commentary corrections

Doug, The intention here is not to validate each point of the positive and negative commentary, but to bring the issues to the fore so that the entire scenario and requirements it generates can be understood in the context of what has gone on with the list. If I have transcribed the negative co

Re: [ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent

Dave Crocker wrote: Whatever SSP does (and the more interesting case is a "Bob" who is completely DKIM-unaware), the mail should not be rejected by the next receiver(s) ... Dave, I'm completely confused. The constraint of requirement 12 is a constraint on the protocol design in the form

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

Douglas Otis wrote: On Sep 21, 2006, at 3:53 PM, Michael Thomas wrote: o DKIM Strict: the state where the domain holder believes that all legitimate mail purportedly from the domain are sent with a valid DKIM signature and that non-compliant services are avoided. What is difficult to

Re: [ietf-dkim] New Issue

Frank Ellermann wrote: Eliot Lear wrote: If you have more, please send a note to this mailing list with the subject "New Issue". See posted in reply to the announcement (requrements-01 available) 2006-09-13:

Re: [ietf-dkim] New issue: What is the purpose of SSP? {3.5}

Dave Crocker wrote: Michael Thomas wrote: I think that the interesting meta issue here is that DKIM verification does not require this; SSP requires this. I hope that there isn't confusion about that because the two really are severable. I am glad you raised this. It encourage

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

Douglas Otis wrote: On Sep 21, 2006, at 11:15 AM, Michael Thomas wrote: Douglas Otis wrote: On Sep 21, 2006, at 11:02 AM, Michael Thomas wrote: Douglas Otis wrote: o DKIM Strict: the state where the domain holder believes that all legitimate mail purportedly from the domain are

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

Douglas Otis wrote: On Sep 21, 2006, at 11:02 AM, Michael Thomas wrote: Douglas Otis wrote: On Sep 21, 2006, at 7:59 AM, Michael Thomas wrote: It's my opinion that "strict" means far too many things to far too many people. Instead of rehabilitating the term, I'd f

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

Douglas Otis wrote: On Sep 21, 2006, at 7:59 AM, Michael Thomas wrote: It's my opinion that "strict" means far too many things to far too many people. Instead of rehabilitating the term, I'd far prefer that we pick something else and really define what it means. I&#x

Re: [ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent

Dave Crocker wrote: Michael Thomas wrote: Whatever SSP does (and the more interesting case is a "Bob" who is completely DKIM-unaware), the mail should not be rejected by the next receiver(s) ... This line of discusses re-enters the model in which we believe the sender is t

Re: [ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent

Dave Crocker wrote: Whatever SSP does (and the more interesting case is a "Bob" who is completely DKIM-unaware), the mail should not be rejected by the next receiver(s) no matter what Alice's SSP says. Bob is perfectly entitled to resend a mail he got using the header fields specified in STD

Re: [ietf-dkim] New issue: What is the purpose of SSP? {3.5}

Jim Fenton wrote: Interesting thoughts...comments inline. Tim Draegen wrote: - My largest customers will not deploy DKIM verification if it requires making a DNS query (or two) for every single non-signed email that they receive. Even if it makes no real-world difference, some p

Re: [ietf-dkim] Re: New Issue: Problems with Scenario 4: Resent

Frank Ellermann wrote: Dave Crocker wrote: or what? It's about mail with one or more Resent-From or Resent-Sender header fields as far as I'm concerned. all of the discussion about signing by Alice is irrelevant, since the later focus seems to be on signing by the re-poster, Bob

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

It's my opinion that "strict" means far too many things to far too many people. Instead of rehabilitating the term, I'd far prefer that we pick something else and really define what it means. I'm not sure that I've achieved that and would appreciate help, but reverting back to the handle that nobo

[ietf-dkim] requrements-01 available

until it hits the drafts repository: http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-01.txt or http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-01.html Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/

Re: [ietf-dkim] SSP and mailing lists

John Levine wrote: Maybe one solution to the mailing list problem would be to approach from a different angle. Would it be possible, for verification etc purposes, to consider mailing list traffic to have come from the mailing list not the person who submitted to the list? That'

Re: [ietf-dkim] SSP and mailing lists

Scott Kitterman wrote: On Mon, 11 Sep 2006 21:14:11 -0700 Steve Atkins <[EMAIL PROTECTED]> wrote: I certainly think that not breaking DKIM signatures will be a mild positive for mailing list software, and in product terms it's probably a smart thing to do. Why break something if you can

Re: [ietf-dkim] SSP = FAILURE DETECTION

Wietse Venema wrote: What was the advantage of SSP with look-alike domains? To find large unproductive ratholes? Neither DKIM or SSP claim to have any direct effect on look-alike domain names, and there's nothing in our charter that says that we'll be doing anything about that ever. DKIM/S

Re: [ietf-dkim] we don't know what SSP means

Dave Crocker wrote: Stephen Farrell wrote: But, let's see what happens as we close out the work on ssp-reqs. Speaking of which, Mike hopes to have a -01 out during the next Stephen, Normally, revisions to working group documents follow explicit assessments of rough consensus about cha

Re: [ietf-dkim] SSP = FAILURE DETECTION

Dave Crocker wrote: Wietse Venema wrote: Here is an example why first-party signatures can be dangerous. Right. They key point, to me, is that a signature by the rfc2822.From domain is likely to help control against some existing types of phishing, but it clearly will not help against

Re: [ietf-dkim] user level ssp

wayne wrote: In <[EMAIL PROTECTED]> John Levine <[EMAIL PROTECTED]> writes: 1 - All mail from this domain is signed (valid). 3 - This domain sends no mail (effectively equivalent to [1]). I don't think these two are equivalent. Sigh. Please provide an operational example

Re: [ietf-dkim] user level ssp

Wietse Venema wrote: Hallam-Baker, Phillip: I think it is entirely likely that bigbank.com would have a situation where the mail servers for its east coast offices were adding signatures but the ones for the west coast were not. The part that is less easy to see is whether there is value t

Re: [ietf-dkim] user level ssp

Wietse Venema wrote: Could someone please explain the nature of the problem that would exist when these (financial) institutions can't selectively add DKIM signatures to outbound email? Engineering is about balance, but I haven't heard enough to make the trade off yet. See my note to John.

Re: [ietf-dkim] user level ssp

John Levine wrote: Could someone please explain the nature of the problem that would exist when these (financial) institutions can't selectively add DKIM signatures to outbound email? Engineering is about balance, but I haven't heard enough to make the trade off yet. I think the alleged p

[ietf-dkim] user level ssp

All of this talk about additional requirements for user level ssp ignores the basic question: should there be any requirements for user level SSP at all? If so, what are the use cases? I'm not terribly convinced that even that has consensus -- this is the first that I even recall the subject bein

Re: [ietf-dkim] Itemized Summary of SSP Requirements-00

Hallam-Baker, Phillip wrote: I think it is possible to do everything we want using only TXT records. I do not see any reason to involve NS records CNAME records or anything of the sort, if we are getting that deep into the DNS architecture for basic policy publication we are doing something wro

Re: [ietf-dkim] Itemized Summary of SSP Requirements-00

Just as a note, this is not a summary of the current draft, and it includes things that I've seen no support for to date. I'd appreciate it if we stick with what I actually wrote down, suggest language changes and/or new requirements instead of reinventing a whole new draft. As experience has sh

Re: [ietf-dkim] New Thread: Use of CNAME in place of NS subdomain delegation

Scott Kitterman wrote: On Monday 28 August 2006 16:58, Michael Thomas wrote: This has been discussed before, and the answer is that it doesn't work very well. You can't, for instance, CNAME an interior node -- just leaf nodes. For DKIM, the ability to roll selector names pretty

Re: [ietf-dkim] New Thread: Use of CNAME in place of NS subdomain delegation

Scott Kitterman wrote: One of the major reasons I've been promoting the idea of the third party authorized list/DSD is to allow smaller domains that do not have the ability to do subdomain NS delegation to get the effective benefit of first party signing. So, when I saw this: On Saturday 26

Re: [ietf-dkim] Reputation trusted layers is out of scope

Hector Santos wrote: - Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: Folks, If there are other things Mike should be doing with reqs-01 that haven't been said on the list, now is probably a good time to raise them (in a new thread). I'm taking your of

[ietf-dkim] there is no such thing as a valid dkim-base *message*

Hector Santos wrote: Subject: Check your account Date: Sun, 27 Aug 2006 05:04:42 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] DKIM-Signature: d=bank.com # invalid 1st party DKIM-Signature: d=asp.com... # valid 3rd party [...

Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains

Stephen Farrell wrote: Mike has suggested that after he produces the reqs-01 that we might want to go back to the jabber/issue-tracker modus operandi to close out the ssp requirements work. That sounds like a reasonable plan to me, but if you've any concerns do let Barry and I know. (I guess tha

Re: [ietf-dkim] Re: Responsibility concerns with DesignatedSigning Domains

Wietse Venema wrote: The problem that you refer to is due to the mistaken belief that DKIM signatures imply anything about rfc2822.from addresses. We can eliminate the problem by simply taking DKIM signatures for what they actually are: proof about the identity of the signing party, not proof a

Re: [ietf-dkim] Responsibility concerns with Designated Signing Domains

Scott Kitterman wrote: On Fri, 25 Aug 2006 22:02:40 -0700 Jim Fenton <[EMAIL PROTECTED]> wrote: Scott Kitterman wrote: I can see this going either way. In the end the operator controls what goes out and what doesn't. Both the author domain and the operator domain c

Re: [ietf-dkim] Responsibility concerns with Designated Signing Domains

Stephen Farrell wrote: But if the delegator delegated its private key, or if the signer supplied its public key to the delegator, then the buck might get moved between them (from their, and not the verifier, perspective), depending on the details of how the key delegation happened. For example,

Re: [ietf-dkim] Responsibility concerns with Designated SigningDomains

[EMAIL PROTECTED] wrote: DKIM has nothing to do with reputation, reputation providers may want to use DKIM as part of their processing technologies but that is their issue/point of failure. I want something that allows me to accurately identify who decided to send me a piece of mail. What I choo

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Stephen Farrell wrote: Jim, I look forward to your seeing further problems with this DSD thing. Meanwhile, I just want to clarify one thing, since I seem to have confused a number of folks: Jim Fenton wrote: Key delegation is already introduced in -base, and we have already described how t

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

over who signs in your domain's name. That's an already solved problem that needn't be revisited by SSP. Mike Regards, Damon Sauer On 8/24/06, Michael Thomas <[EMAIL PROTECTED]> wrote: Damon wrote: > On 8/24/06, Michael Thomas <[EMAIL PROTECTED]> wro

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

Damon wrote: On 8/24/06, Michael Thomas <[EMAIL PROTECTED]> wrote: Damon wrote: > In my opinion, I am agreeing with you due to the lack of specific > rules covering who can and cannot sign for me and when/how do I expect > my policy to be enforced. This is factually incorrect

Re: [ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

Damon wrote: In my opinion, I am agreeing with you due to the lack of specific rules covering who can and cannot sign for me and when/how do I expect my policy to be enforced. This is factually incorrect. Dkim-base has very clear and unambiguous rules about who can sign for you. It would be he

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Scott Kitterman wrote: There are domains out there that cannot do the NS delegation trick. Today. Whether there are any alternative tricks that they can perform is speculation. Given what I've seen proposed, I see no reason for encouragement. What we do have a good chance for is to screw

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Dave Crocker wrote: Wietse Venema wrote: > There is no need for the signing party to acquire a secret key from the author party. To delegate signing from example.com to isp.com, with d=example.com as a first-party signature: There is an administrative choice, here. One can delegate a

Re: [ietf-dkim] Keys vs. Reputation

Damon wrote: This is _exactly_ the direction I would like to go, and so far, I don't see a technical issue with it as long as we _do not_ say, 3rd parties can sign for me even if I don't want them to. Nobody to my knowledge has taken that position. Mike

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Scott Kitterman wrote: OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I agree it's better, but there are operational frictions that will impede this approach in some cases. What I believe that we've discovered is that this isn't nearly simple as some people hoped. Do

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

Hector Santos wrote: So let's send this from mailinglist.com through their authorized submission server: From: [EMAIL PROTECTED] Sender: mailinglist.com DKIM-signature: d=isp.com; First, the presumption here is that [EMAIL PROTECTED] has subscribed to some mailing list where he should

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Scott Kitterman wrote: On Friday 18 August 2006 20:04, Michael Thomas wrote: Scott Kitterman wrote: On Friday 18 August 2006 16:32, Jim Fenton wrote: Scott Kitterman wrote: What security problems are there with a list of authorized signing domains that are not

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Scott Kitterman wrote: On Friday 18 August 2006 16:32, Jim Fenton wrote: Scott Kitterman wrote: What security problems are there with a list of authorized signing domains that are not equally applicable to the the NS delegation/operator signs with the author's domain approach? I'm unc

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Hector Santos wrote: - Original Message - From: "Paul Hoffman" <[EMAIL PROTECTED]> To: Sent: Friday, August 18, 2006 4:07 PM If that is what the OA domain (FROM) declares, sure. Good. Glad we can have a shorter description. But first he has to first declare he allows

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Wietse Venema wrote: I think it is a mistake to attach significance to the author-domain (rfc822.from) unless there is a reason to trust the signing-domain for this purpose (for example, scenarios 1a or 1b above). Trust is probably the wrong concept here. If a domain advertises A records in

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Dave Crocker wrote: In other words, I suggested that use of classic DNS sub-domains provides the delegation features that cover the interesting cases for DKIM. I continue to be unclear what is superior about having SSP invent a new mechanism that creates security problems and additional adminis

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Dave Crocker wrote: Michael Thomas wrote: As was already discussed in the comments to the requirements draft, not all DNS providers give their customers the ability to do subdomain level NS delegation and so while that approach is good for those who can do it, it leaves out a portion of the

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

Scott Kitterman wrote: On Thursday 17 August 2006 16:50, Dave Crocker wrote: This mechanism already exists, is notably simpler than the one being discussed, and does not suffer the security hole that has been noted. Simply stated: If the author's domain is to be used for assessment ac

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

Scott Kitterman wrote: On Thursday 17 August 2006 11:44, [EMAIL PROTECTED] wrote: Big gaping hole, I may assume that isp.com can determine the author/originator but how to differentiate or not sign a spoof? It gets back to is the signer controlled or uncontrolled. Only a controlled

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

Douglas Otis wrote: On Aug 17, 2006, at 8:44 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Big gaping hole, I may assume that isp.com can determine the author/ originator but how to differentiate or not sign a spoof? To achieve full isolation, sign all sources with a subdomain si

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

Scott Kitterman wrote: It seems to me that bringing a mailing list into the scenario changes the scenario slightly, but not in a significant way. I would envision two basic modes of operation for a signer: [] I think people are missing the subtlties of the attack; the basic problem is th

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

Jim Fenton wrote: Douglas Otis wrote: This seems like a minor change for the better. What weakness can't be fixed by the proper procedures followed by a signing domain? The one I described: the inability for a verifier to distinguish an author signature generated by the delegate from

Re: [ietf-dkim] Issue: Requirements #9 NOT REQUIRED for 1st party valid signatures.

Damon wrote: On 8/10/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Damon, There are some problems with your suggested statement. (Note: I'm not saying I'd agree with it if its fixed, but as of now its just not ready for the WG to consider.) Damon wrote: > The Protocol MUST NOT be required

Re: [ietf-dkim] Re: Requirements comment: Bigbank example description

Stephen Farrell wrote: Michael Thomas wrote: As he said it: "The protocol" MUST be either compatible with "resent mail", independent of the signing practices of a resending service, or explicitly explain why and when that's expected to fail. In non-chair

Re: [ietf-dkim] Re: Requirements comment: Bigbank example description

Stephen Farrell wrote: Michael Thomas wrote: Sorry folks, this was a very last minute deletion on my part. The version that Frank has is correct. Nope. Its my fault for not checking. > Suffice it to say, my read of the working group consensus was that the general sentiment of the

Re: [ietf-dkim] Requirements clarification: Standard for resource record name space collision

Scott Kitterman wrote: On Wednesday 09 August 2006 16:42, Michael Thomas wrote: Paul Hoffman wrote: At 1:02 PM -0400 8/9/06, Scott Kitterman wrote: *** *** 474,480 expectation is "few".] 3. Discovery mechanism MUST NOT overload se

Re: [ietf-dkim] Lean vs. Fat 'requirements'

Dave Crocker wrote: Michael Thomas wrote: so I erred on less controversy. Some of us believe, rather strongly, that this is a particularly important "bias" to the development of the requirements list. It occurs, to me, however, that it might not be clear whether there

Re: [ietf-dkim] Re: Requirements comment: Bigbank example description

Sorry folks, this was a very last minute deletion on my part. The version that Frank has is correct. Suffice it to say, my read of the working group consensus was that the general sentiment of the wg would have favored (9) in Stephen's, but I'm not sure it belonged in the requirements draft at t

Re: [ietf-dkim] Clarification: Section 5.4.6

Software, Inc. http://www.santronics.com - Original Message - From: "Michael Thomas" <[EMAIL PROTECTED]> To: "Michael Thomas" <[EMAIL PROTECTED]> Cc: "DKIM List" Sent: Wednesday, August 09, 2006 2:33 PM Subject: Re: [ietf-dkim] Clarification

Re: [ietf-dkim] Corrected copy - Requirements addition: Policy/Practice record for first party signatures

Scott --- Scott -- I think it's both explicit and specific in other requirements that the protocol must publish that data, and some of those are MUST strength. I really don't see why we need to restate that here. That and I don't think there is any explicit or implicit proscription here on w

Re: [ietf-dkim] Requirements clarification: Standard for resource record name space collision

Paul Hoffman wrote: At 1:02 PM -0400 8/9/06, Scott Kitterman wrote: *** *** 474,480 expectation is "few".] 3. Discovery mechanism MUST NOT overload semantics of existing DNS !resource records where name space collisions are possible. 5.2. Transpo

[ietf-dkim] RFC2822.Sender

Tony Hansen wrote: Damon wrote: --- 350,357 previous scenario. A receiver, on the other hand, may be able to take advantage of the knowledge the domain's practice of signing all mail in order to use it to bias filters against the unexpected !arrival of a piece of unsigned,

Re: [ietf-dkim] Clarification: Section 5.4.6

Following myself up with a clarification: Michael Thomas wrote: "In particular, a Practice or Expectation MUST NOT mandate any disposition stance on the receiver." The reason that I've written it in this way was purposeful on my part: the sender's expectation is th

Re: [ietf-dkim] Requirements clarification: Specification of domain holder

Done. Scott Kitterman wrote: *** 508,514 5.3. Practice and Expectation Requirements In this section, a Practice is defined as a true statement according !to the domain holder of its intended externally viewable behavior. An Expectation combines with a Practice to convey what

<    1   2   3   4   5   6   7   8   9   10   >