Re: [ietf-dkim] Consensus check: Domain Existence Check
modify (though I only slightly prefer that to keep) > Date: Thu, 29 May 2008 10:45:22 +0100> From: [EMAIL PROTECTED]> To: > ietf-dkim@mipassoc.org> Subject: [ietf-dkim] Consensus check: Domain > Existence Check> > > There has been considerable debate in the past few weeks > regarding the> need for a check for domain existence in ADSP.> > I think > we've had sufficient time for debating this, let's decide.> Please respond to > this by Friday June 6th.> > The text in question (from section 4.2.2 of > draft-ietf-dkim-ssp-03)> is as follows:> > 2. _Verify Domain Exists._ The > host MUST perform a DNS query for a> record corresponding to the Author > Domain (with no prefix). The> type of the query can be of any type, since > this step is only to> determine if the domain itself exists in DNS. This > query MAY be> done in parallel with the query made in step 2. If the result > of> this query is an "NXDOMAIN" error, the algorithm MUST terminate> with an > appropriate error.> > NON-NORMATIVE DISCUSSION: Any resource record type > could be> used for this query since the existence of a resource record> of > any type will prevent an "NXDOMAIN" error. MX is a> reasonable choice for > this purpose is because this record type> is thought to be the most common > for likely domains, and will> therefore result in a result which can be more > readily cached> than a negative result.> > There are three options that have > been actively discussed:> > a. Keep. Retain the current text as-is.> > b. > Modify, i.e. keep, but with a different set of records. It was> suggested > that the current NXDOMAIN is incorrect, and that MX, A, and> records for > the domain should be queried, with the existence of> any of these records > indicating a domain that is potentially used for> email. If we have consensus > for this option, then we may well need a> subsequent poll to decide the > details.> > c. Remove. Remove the text as being out of scope for the ADSP> > specification. Some text may need to be added pointing out the need for> a > domain existence check elsewhere. If the consensus is for removal,> then we > should consider what, if anything, the specification should> refer to for > performing the domain existence check.> > Please just answer "keep", > "modify", or "remove" in this thread, and use> a different subject line for > any discussion.> > Thanks,> Stephen.> > > > > > ___> NOTE WELL: This list > operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Keep your kids safer online with Windows Live Family Safety. http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_Refresh_family_safety_052008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] subdomain strawpoll
Remove > Date: Thu, 1 May 2008 09:11:08 +0100 > From: [EMAIL PROTECTED] > To: ietf-dkim@mipassoc.org > Subject: [ietf-dkim] subdomain strawpoll > > > Folks, > > We don't seem to be converging on this on the list, though I > also think that the recent (and quite good) debate should > mean that a lot of folks can express informed opinions. > > So Barry & I would like to do a strawpoll to see if there is > in fact rough consensus one way or the other. > > Your question for this week is therefore: > > Should we keep or remove text below? > > (from 4.2.2 of draft-ietf-dkim-ssp-03, but please be sure you > check the context before expressing an opinion) > > 3. _Try Parent Domain._ The host MUST query DNS for a TXT record for > the immediate parent domain, prefixed with "_asp._domainkey." If > the result of this query is anything other than a "NOERROR" > response with a valid ASP record, the algorithm terminates with a > result indicating that no ASP record was present. If the ASP "t" > tag exists in the response and any of the flags is "s" > (indicating it does not apply to a subdomain), the algorithm also > terminates without finding an ASP record. Otherwise, use that > record. > > Please just answer "keep" or "remove" in this thread, and use a > different subject line for any discussion. I'll summarise results > back to the list in one week from today (after May 8th). > > Since 5016 section 4.2 does (though admittedly somewhat vaguely) > call for inclusion of the feature, we think a close call should > come down in favour of keeping it in. > > If the consensus is for removal, then we can separately discuss what, > if anything, should go into the security considerations section that > covers the issue. Actually, even keeping it in, we should probably > add some new sec. cons. text derived from the recent discussion, but > let's see if we've consensus first. > > Thanks, > Stephen & Barry. > > > > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ In a rush? Get real-time answers with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_realtime_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please?
> To: ietf-dkim@mipassoc.org > From: [EMAIL PROTECTED] > Date: Thu, 1 May 2008 11:15:09 +0200 > Subject: Re: [ietf-dkim] forward movement, please? > > Arvel Hathcock wrote: > > > I propose that the side advocating maintaining the NXDOMAIN > > check as an actual algorithmic step agree to remove this > > from the algorithm description in favor of placement > > somewhere else. > > I favour to swap steps 1 and 2: > Looking for _adsp._domainkey.nxdomain.example. is a waste of > time when nxdomain.example. does not exist. I'd favour to > keep it in the spec., it is needed for result nxdomain. If > you nevertheless remove both (the step and the result) make > sure to tell Murray about it. > > Frank > +1 for reasons I have shared before. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Back to work after baby–how do you know when you’re ready? http://lifestyle.msn.com/familyandparenting/articleNW.aspx?cp-documentid=5797498&ocid=T067MSN40A0701A___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike domains like parent domains?)
> Date: Wed, 30 Apr 2008 15:12:34 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] forward movement, please? (was RE: Are lookalike > domains like parent domains?) > > > > Arvel Hathcock wrote: > > I propose that the side advocating removal of the NXDOMAIN check agree > > to language which makes this step AT LEAST a SHOULD and preferably a MUST. > > > Having the ADSP specification include normative text that calls for > validating > the From field domain name does two things: > > 1. Couples an entirely separate and more generally useful mechanism (checking > domain name validity) to one that is considerably more limited (ADSP). For reasons I have shared before I have to disagree. The check for domain existence is not unrelated. In short the check for domain existence tells you whether something is a D about which it is valid to search for a P. The fact that people may already be doing this elsewhere and that it is useful for other reasons doesn't have any impact on the fact that this check gives you a hard algorithmic boundary for what entitiies ADSP is intended to apply to. We have a specification that is currently intended to cover a narrow and well defined set of entities, that is domains, and a check to tell whether a given entity is such a thing. > > 2. Modifies SMTP. (Yes, really.) As I think has been pointed out before here is the definition of the domain portion of addr-spec from rfc2822. "The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]." Wouldn't something have to exist to meet this specification? Or does the term Internet domain include things that don't exist but maybe could? > > Having non-normative text that describes it serves to promote the idea but > not > couple it with the fate of ADSP. > > d/ > -- > >Dave Crocker >Brandenburg InternetWorking >bbiw.net > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Express yourself wherever you are. Mobilize! http://www.gowindowslive.com/Mobile/Landing/Messenger/Default.aspx?Locale=en-US?ocid=TAG_APRIL___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] protecting domains that don't exist
> To: ietf-dkim@mipassoc.org > Date: Mon, 14 Apr 2008 09:53:28 -0400 > From: [EMAIL PROTECTED] > Subject: Re: [ietf-dkim] protecting domains that don't exist > > John Levine: > > > As someone pointed out, you can interchange steps 1 and 2 in the > > > specification, putting the existence check first. And then, of course, > > > you > > > can decide that the existence check is done outside ADSP. If the > > > existence > > > check is removed, I would advocate putting in language that says an > > > existence > > > check SHOULD be performed before doing ADSP. > > > > That seems reasonable. My objection (and I think also Dave's) is not that > > it's a bad idea, but that it's not part of DKIM or ADSP. > > +1 > -1 I disagree. Having the NXDOMAIN check makes thh scoping boundaries of ADSP explicit in the discovery algorithm. That is why I advocated making it step 1. Anything that fails that test is explicitly outside the scope of what ADSP covers. Without this explicit scope boundary the behavios of different systems querying this data would become very unpredictable. With the scope boundaries as defined by step 2 it is unequivocal that any query for something that does not exist cannot be valid within ADSP. > It's unfortunate that DNS won't let us specify ADSP policies that > cover only non-existent originator domain names, but wishing for > such an ability does not mean that we suddenly can. > > The NXDOMAIN result for the originator domain cannot(*) correspond > with an ADSP policy (one of "unknown" / "all" / "discardable"), > and therefore it cannot be part of ADSP. > > Wietse > If this test were applied to every RFC then no RFC could ever formally state what set of data it applies to (since obviously that counter set would be something that would not have a valid response within that context). If we applied this same test to DNS for example would we even have NXDOMAIN (or "Name Error" as its called in rfc 1035) as a response code at all? Would it be better if "error" were a specifically defined result in addition to "unknown" / "all" / "discardable"? > (*) Otherwise we could declare 99.% ADSP deployment today. > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.htm _ More immediate than e-mail? Get instant access with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Date: Wed, 9 Apr 2008 11:27:27 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a > domain tree > > I believe the Step 2 query only makes sense for ADSP in the context of > covering > an entire sub-tree, but that ADSP does not describe the larger framework into > which Step 2 fits, for accomplishing that goal. > > d/ > -- >Dave Crocker >Brandenburg InternetWorking >bbiw.net Dave, I think this misstates what that query actually accomplishes. What step 2 tells you is whether the thing you are looking at even is a domain and thus a candidate to have a domain policy. In the example Eric gave the record he mentioned would still only cover example.com. If a.b.example.com existed and you wanted to cover an entire sub-tree a.b.example.com would still need to have its own policy. Since some.thing.example.com doesn't exist I am not sure it makes sense to say it is part of that sub-tree. Even as written there is no indication that anything about the policy of example.com covers some.thing.example.com nor even any indication that there is such a policy. What the spec says is to return an error. I think a cleaner way to express what I think you get out of step 2 (though a less efficient algorithm I suspect) would be to make step 2 step 1 and add some text around the error saying that searching for domain policies for anything that is not a domain is not within the scope of this document. Robert > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
> Date: Mon, 7 Apr 2008 14:32:25 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a > domain tree > > > > [EMAIL PROTECTED] wrote: > > Like others I am guessing that you are referring to section 4.2.2 step 2. > > Yup. > > >Since the domain doesn't exist the administrator can't have > > been expected to create a policy for it so error seems like the right answer > > to me. > > That presumes the goal of protecting an entire sub-tree. > > Absent that goal, the goal is to cover domains that have ADSP records. Very > different scope of effort. > I think I would describe my goal more narrowly than that. I don't think that any ADSP record should be protecting anything more than the exact domain the record is entered for. I also think it is worthwhile for it to be possible for a domain administrator to be able to cover everything within his administrative control with their own records if they want to do that. The case we're talking about here is not whether or not it is worthwhile to protect the whole domain sub-tree but what to do when encountering something that is definitionally NOT part of the domain sub-tree (remember we're talking about NXDOMAIN cases here only, not intuiting anything about any actual domains). Since these things are not domains then saying that searching for a domain policy for them returns an error seems entirely reasonable to me. Robert _ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
> Date: Sun, 6 Apr 2008 23:06:25 -0700 > From: [EMAIL PROTECTED] > To: ietf-dkim@mipassoc.org > Subject: [ietf-dkim] New Issue: protecting a domain name vs. protecting a > domain tree > > 3. At least one of the sub-tree mechanisms is attempting to glean > information > from the absence of publisher action. Let me explain: > > I believe the desire with checking the A record is similar to the idea > behind having ADSP in the first space. > Dave, Like others I am guessing that you are referring to section 4.2.2 step 2. In that step it explicitly says that you can check for any record you want and the semantics of the returned record itself are basically irrelevant only the existence of some response other than NXDOMAIN matters. In the case of an NXDOMAIN I didn't read that section as intuiting any policy. It just says to return an error which I read as something different than, return some specific result. Since the domain doesn't exist the administrator can't have been expected to create a policy for it so error seems like the right answer to me. Otherwise to create policies for all of my domains I would have to create policies not just for all existing sub-domains of that domain (which I personally would support) but all conceivable sub-domains of a domain (which I don't think I would). Robert _ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: the entire world will change their mail systems so that SSP sort of works
> Date: Thu, 24 Jan 2008 20:51:59 +> From: [EMAIL PROTECTED]> To: > ietf-dkim@mipassoc.org> Subject: Re: [ietf-dkim] Re: the entire world will > change their mail systems so that SSP sort of works> CC: [EMAIL PROTECTED]> > > >I'm not misrepresenting other peoples arguments at all. If the only> > >signature on the message is from a 3rd party and there is an> >opportunity > to check for the assertion of the purported From domain> >that is not taken, > that in fact is giving more weight ... to the> >signature of the third party > ...> > Right. Let's look at the message you just sent, and imagine that the> > list signed it with a mipassoc.org signature. Since I know that Dave> runs > his lists well, I'm done. The "opportunity" to check something> else is > irrelevant, as is the fact that the list would have broken> your signature.> So you've picked an example where you don't need to bother with SSP at all since you already have an existing trust relationship in place, and your existing systems give you what you would consider to be a valid answer given just DKIM and no policy or practices statements whatever. If your answer is, that given this example you are not going to use SSP (and as an engineer I would probably recommend not mucking with any cases where your systems already do exactly what you want them to) that is fine. But given that, how does this have any bearing on what people should be doing in cases where they decide they do want to use SSP? Let's modify the example a bit. Imagine that the message had been sent to you rather than through the mipassoc.org mailing list, but through some entity you knew nothing about, and that that entity had signed the message. Does the draft need to explain all the cases or reasons why someone might not bother to look up a policy at all? Robert _ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
> Date: Thu, 24 Jan 2008 13:31:48 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to > unsigned messages > > [EMAIL PROTECTED] wrote: > > > But I think there are a sufficient number of cases where domain owners > > may want to make statements not just about mail that is not signed, but > > about mail that is not signed by them. > > Are you kidding me? I am willing to bet that given the opportunity to > do so, they will immediately apply strong SIGNING requirements to their > mail, IFF the receivers are going to HONOR the policies. > I could be wrong, but I think we agree here. What I meant was, many domain owners will want their policies to apply to all mail not signed by them (which includes both unsigned mail and mail signed by third parties). Where we may disagree is in the other part of my stgatement, which isn't quoted here. I think limiting the SSP spec to a description of how to retrieve the data, and under what situations it is applicable is sufficient. I don't think we need to say explicitly what to do when you encounter a specific policy. I think most domain owners who want a strict policy will create one if they think it will help prevent problems with ANY receiver who is significant to them. > If we have such a relaxed mode of operation, bad guys just have to run > in legacy mode. No adaption required. > > We are erroneously presuming everyone are going to depend on DKIM being > tied to reputation services and my view, this is going to be the biggest > mistake we make here. > > > -- > Sincerely > > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > _ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to unsigned messages
> Date: Thu, 24 Jan 2008 08:18:32 -0800 > From: [EMAIL PROTECTED] > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP to > unsigned messages > > > > Stephen Farrell wrote: > >>> 1521Limit the application of SSP to unsigned messagesnew dkim > >>> Nobody0 [EMAIL PROTECTED]9 days ago9 days ago0 > >> > >>> Proposal: REJECT, but some wording changes may be needed for the next > >>> rev, thread is [4] I mainly saw opposition to the change suggested in > >>> the issue, and little support, but some text clarifying changes were > >>> suggested (e.g. [5]). [4] > >>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008424.html [5] > >>> http://mipassoc.org/pipermail/ietf-dkim/2007q4/008467.html > > > >> Would you please explain the basis for assessing that this topic got > >> sufficient discussion and that there was rough consensus on it? > > > > See above "I mainly saw..." > > > Summary of proposal: > > > All text that causes SSP to be applied to an already-signed message > > needs to be removed. > > > Folks, > > I've reviewed the thread that took place on this topic. Here are summary > statistics: > > Total postings in thread: 46 > > Number of different people posting: 14 > > Apparent REJECT of proposal: 4 > > Apparent ACCEPT of proposal: 5 > > > I would like to ask folks with an opinion about this proposal to post an > explicit note stating support or opposition. Some of the existing posts were > about substantive issues in the proposal, but did not clearly indicate > support > or opposition. > > Given that this issue goes to the core of a significant fraction of the > current specification's functionality and given that there is at least an > implied requirement for the functionality in the SSP requirements RFC, I'll > ask folks to do both a +1/-1 *and* to explain their reasons. > > I also do not find a record in the archive of working group agreement to add > the features in question. So an assumption that the features should be > retained unless there is a rough consensus *against* is problematic. Citing > the SSP requirements RFC is comforting, but questionable, absent any history > of group discussion and clear rough consensus about the matter. > > d/ > > -- > -1 . I would like to see us remove any text that implies a decision about what a receiver should do with that information, and maybe some text making it clear that a receiver may decide on a message by message basis to completely skip SSP processing for for reasons of local policy or because they have sufficient information to make a decision without checking SSP (though it seems a little odd for an RFC to say that when you are not doing X you don't need to worry about how to properly do X). But I think there are a sufficient number of cases where domain owners may want to make statements not just about mail that is not signed, but about mail that is not signed by them. _ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Seriously.
> From: [EMAIL PROTECTED] > At 10:40 22-01-2008, Siegel, Ellen wrote: > >If you have an authentic claim of responsibility from a trustworthy > >party (as per #1), why should it matter whether that party is > >represented by the From: header or the Sender: header? And why, if > >the authenticated party in the Sender: field is trustworthy, should > >it be required that the From: domain is authenticated directly? > > It doesn't matter if we trust that party but see example below. > > If example.com is a bank and example.net is an ISP who is a > trustworthy party, would you trust an email for which example.net > claims responsibility if the From: shows an example.com author? > I think my answer would be that for this purpose the scope of trust we're discussing is VERY narrow. It is "Do I trust this party to sign mail on behalf of other domains?" , not "Do I generally consider this domain trustworthy?". For the first question it is really unlikely that any ISP would meet that requirement for me given the fact that it would imply a level of control over their end users that would be very hard to meet. Even the best ISPs have to deal with people creating bogus accounts with stolen credit cards and customers whose accounts get compromised, and I am not aware of anyone who has come up with a completely effective way to proactively stop traffic from those accounts. If ISPs were widely considered trusted third parties for purposes of signing mail I think it would pushd the need for more domains to express "strict" policies. > See RFC 5016, Section 3.2 (Problem Scenario 2: Illegitimate Domain Name Use). > > Regards, > -sm > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> Date: Tue, 22 Jan 2008 11:16:31 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > [EMAIL PROTECTED] wrote: > > Agreed, and one of the things a domain owner knows in at least some > > situations is what policies they have set for users of that domain about > > how they are allowed to use that domain. Clearly this is not the case > > for a the majority of domains on the internet, but how many have to be > > able to make this assertion for it to be useful to have in the standard? > > If we have some differential statements of constituencies and scenarios to > which a given feature applies -- sometimes called an applicability statement > -- then we can make much more realistic statements about utility. > > Some constituencies are few in number but big in impact. That's fine. As > long as we can characterize them and convince ourselves that they will > benefit. > As is the case with pretty much any type of policy publication there are both publishers and consumers of that information. I think I could readily characterize instances where a domain owner could accurately publish a "strict" policy for their domain, both from personal experience and from the set of senders/domain ownders I regularly work with. That's clearly not the whole internet but would represent at least on constituency on the publishing side. Characterizing the consumer side accurately is slightly harder because this data is supplementary to whatever people already do and I don't think this data can really be accurately viewed in a vacuum but still should not be an insurmountable problem. Are you looking for descriptions of one of the above, both, or the interaction between the two? > > > By asserting that any mail that claims authorship from a domain I > > control must be signed by me I'm not making any particular assertion > > about why any other mail might not fit that policy. Just the fact that > > it does not. > > (just to make sure: "by me" means "by the same domain as listed in the > author > field?) > Yes, sorry resorted to putting myself in the place of a domain owner publishing a policy rather than remaining in the third person. The "me" refers specifically to the owner or administrator of the domain which appearts in the author field. > At any rate, phrased in the way that you have phrased it, I believe you are > correct. > > However, if you state that all mail claiming authorship from a domain is > signed by that domain, then there is an inescapable implication about > unsigned > mail claiming that authorship. There is not need to state the implication > explicitly. > > d/ > -- > Yes, that's true, but that implication is not the same as John's characterization of this statement as saying "I am a phish target". The implication I would get from that is if you get a piece of unsigned mail, or mail signed by someone other than that domain that it was not validly authored by that domain. That encompasses more possibilities than just "I am a phish target" and still requires that the receiver make a decision about whether they care that the mail was not validly authored by that domain given the information they have available about both the source that transmitted it to them, and the source that actually did sign the mail. Robert >Dave Crocker >Brandenburg InternetWorking >bbiw.net _ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
Date: Tue, 22 Jan 2008 15:17:12 -0500 > From: [EMAIL PROTECTED] > > But if you already have enough data to make a decision about a message's > > disposition in that case, you also have enough data to make a decision > > about that message's disposition regardless of any SSP policy that > > anyone might express. > > Right. That's another reason that "strict" is a bad idea, because it > gives senders the unwarranted impression that they control (or even > affect) things that we know they don't. > I suspect that the group of senders who think they can somehow mandate how a receiver treats their mail already have the belief independent of SSP, but I agree that the current wording of the document gives the impression that it is mandating a use of the data rather than just providing information and it could be clearer about that fact (the existence of the handling tags doesn't help here). To clarify this point a little more it is not even the sender who would be making this assertion, but the domain owner. Assuming we can make it clear that the domain owner's role is simply to provide information and that receivers will make use of that information or not however they decide it best serves their users then I still think this is a good policy to be expressible. > > So the question in this case really comes down to whether the policy we > > are discussing (or any particular SSP statement) is useful, or at least > > non-harmful, when you are evaluating a message for which your existing > ? policies do not provide a completely efficacious decision algorithm. > > Right again. That's where I say that statements about things about which > the sender has actual knowledge (e.g., "I sign everything") are far more > likely to be useful than statements about things that they don't. > I have got to disagree here. I think most cases where domain owners are likely to be able to make a "strict" assertion that information is likely to be extremely helpful. And if someone makes that assertion erroneously and I don't have enough information to make a decision independent of SSP and the mail is transmitted via someone who I don't trust to sign messages on behalf of others then it seems really unlikely that I'm going to miss that mail. Robert _ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> Date: Tue, 22 Jan 2008 14:19:20 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first > Author > > > By asserting that any mail that claims authorship from a domain I > > control must be signed by me I'm not making any particular assertion > > about why any other mail might not fit that policy. Just the fact that > > it does not. > > But here we go again. Why should anyone care about your policy? We don't > care about your policy, only about the mail that shows up here, and it is > most definitely not my job to enforce rules that you claim that apply to > your users. > > A message shows up on a mailing list with a From: address in your domain. > Your SSP says to discard it. Tough noogies, I won't. If an unsigned > message were otherwise dubious, and you said you signed everything, that > might tip the balance to filtering it, but not because you told me to. > > R's, > John But if you already have enough data to make a decision about a message's disposition in that case, you also have enough data to make a decision about that message's disposition regardless of any SSP policy that anyone might express. To a system implementing the receiver policy you outlined above SSP is only useful at all for the messages where you don't have enough information to make a decision. So the question in this case really comes down to whether the policy we are discussing (or any particular SSP statement) is useful, or at least non-harmful, when you are evaluating a message for which your existing policies do not provide a completely efficacious decision algorithm. In any case where your current policies about mail acceptance already work well and provide the answers you want why would you bother to layer extras on top anyway? Robert _ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> > 1) It sounds like you are saying that, unless I expect that a receiver > > is going to use that fact as a binary decision point to accept or reject > > a piece of mail it is not worth expressing > > Oh, no. I am trying to say that senders should stick to what they know > about. "I sign all my mail" certainly qualifies. > Agreed, and one of the things a domain owner knows in at least some situations is what policies they have set for users of that domain about how they are allowed to use that domain. Clearly this is not the case for a the majority of domains on the internet, but how many have to be able to make this assertion for it to be useful to have in the standard? > > 2) We have to build SSP assuming that people are only ever going to use > > this information by itself and that they for some reason do not have > > access to any other information about the sender. > > Actually, I feel quite the opposite, that receivers will make their > filtering decisions based on all sorts of useful information from multiple > sources. But I still don't understand why anyone expects "I'm a phish > target" from some random stranger to be useful. If you have access to a > lot of receiver data, e.g., a large ISP, you probably know way more about > that the sender does. > > R's, > John By asserting that any mail that claims authorship from a domain I control must be signed by me I'm not making any particular assertion about why any other mail might not fit that policy. Just the fact that it does not. _ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> Date: Mon, 21 Jan 2008 23:06:33 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first > Author > > > Sorry, I think I may have misunderstood your earlier point. When you say > > SSP applies only to unsigned messages were you talking about excluding > > valid third party signatures (I apologize if I misread that part of the > > email). > > Seems to me that no matter what we say, if a message is signed by someone > a receiver sufficently trusts, they're going to whitelist it, so it's > silly to try to tell them to do anything else. I'm inclined to completely > remove anything about what receivers do with mail with other signatures. > > R's, > John I agree with the part about not telling receivers what to do with a piece of mail but I think there are two assumptions built into the premise above that I have a problem with. 1) It sounds like you are saying that, unless I expect that a receiver is going to use that fact as a binary decision point to accept or reject a piece of mail it is not worth expressing Since I am avoiding making any assumptions about how people intend to use the data I think it is useful to be able to express a policy for how I expect domains I control to be used. If some people find that useful sometimes and irrelevant at others then I can't see that I'm worse off than I was before, or that the receiving system is. and 2) We have to build SSP assuming that people are only ever going to use this information by itself and that they for some reason do not have access to any other information about the sender. I understand the idea of keeping reputation out of scope, and not making assumptions about how people use the data. But the idea that all filtering decisions are now and wil be forever a set of hurdles someone has to pass over is just as big an assumption about how the data will be used, as assuming that they will look at the totality of data they have about a sender. The fact is that both cases exist already, and for the latter case any useful information you add to those models makes them better. We don't have to make assumptions (or worse prescriptions) about how people use the data to know that giving people extra information is helpful. Since there are a number of useful cases I can think of where domain owners could for valid reasons say "I expect all mail using my domain to be signed by me" I think this is a policy worth allowing in the spec (and no this is not limited to big commercial mailers, many small corporate environments, and environments with very strict legal regimes regarding how they archive their email both jump out as cases where it would be entirely reasonable to express that policy). I don't think this qualifies as telling anyone what to do. Just conveying my expectation of how certain domain owners expect their domains to be used. If receiving systems still end up accepting mail from third parties they trust that would be up to them. And, if you are using this data as a single hurdle in mail acceptance, then like virtually any other single hurdle most systems use, you're probably going to have some kind of whitelist for exceptions to that test , but again that is entirely a matter for RECEIVER policy and is independent of any assertions made byt the sender. Robert _ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> Date: Fri, 18 Jan 2008 16:37:53 + > From: [EMAIL PROTECTED] > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first > Author > CC: [EMAIL PROTECTED] > > >> Indeed. Does this mean you agree that SSP only applies to unsigned > >> messages? (Actual non-rhetorical question.) > > >I would agree here, except for one consideration. It makes it possible > >to trivially bypass someone's policy by inserting a completely bogus > >signature in all messages claiming to be from them. If anyone has a good > >suggestion for how to tell the difference between a signature broken in > >transit and one just made up ... > > As far as DKIM is concerned, there is no difference between a broken > signature and no signature. A message that arrives with a bogus > signature is unsigned. Sorry, I think I may have misunderstood your earlier point. When you say SSP applies only to unsigned messages were you talking about excluding valid third party signatures (I apologize if I misread that part of the email). If you are talking about third party signatures I guess it comes down to what you think the P in SSP stands for. If it is practices it is clear that I cannot usefully say anything about anyone else's practices. If it is policy I would say it is reasonable for a domain owner to be able to assert the policy that noone else is allowed to sign messages on their behalf. Whether it is wise to do so is really a matter for the domain ownder to decide for themselves looking at their terms of service, how their users (if there are any) actually use their domain, etc.. What a receiver does with this information is in my opinion out of scope for this discussion. It is essentially just one more useful piece of information to throw into the vast sea of information they already have available to help make decisions. If they choose to pick a set of third parties who they trust regardless of the originating domains assertion that would be up to them. SImilarly if they want to pick a list of originating domains they are completely unwilling to accept third party signatures for that is also up to them. The policy of the originating domain may be of some help in deciding if someone belongs in either of those categories. . - Robert > > R's, > John > > _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first Author
> Date: Thu, 17 Jan 2008 09:32:42 -0500 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [ietf-dkim] ISSUE 1525 -- Clarification about posting by first > Author > CC: ietf-dkim@mipassoc.org > > > Actually, all I was going to suggest was that if SSP purports to manage > addresses on the From: line, it should manage all of them rather than > arbitrarily giving N-1 of them a free pass. > +1 I think in the case of multiple From: addresses only checking one, or only checking the one that matches the sender seems to arbitrarily ignore the policy of other domains appearing in that header. As long as the document suggests a limit on how many checks to do I think John's approach makes the most sense to me. > > because simply SOMEONE taking responsibility for the message mandates > > the need to establish reputation of that someone > > Indeed. Does this mean you agree that SSP only applies to unsigned > messages? (Actual non-rhetorical question.) > I would agree here, except for one consideration. It makes it possible to trivially bypass someone's policy by inserting a completely bogus signature in all messages claiming to be from them. If anyone has a good suggestion for how to tell the difference between a signature broken in transit and one just made up out of nothing or copied from a different valid message apart from keeping a list of known mailing lists and forwarders who change message content, I'd be willing to change my mind. - Robert > R's, > John _ Climb to the top of the charts! Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author breaks email semantics
> From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first > Author breaks email semantics > Date: Wed, 16 Jan 2008 16:52:03 -0800 > CC: [EMAIL PROTECTED]; ietf-dkim@mipassoc.org > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > > > > Please translate your grouchiness into concrete suggestions on what > > if anything should change in draft. There are so many different issues > > being discussed here that your +1 one is essentially useless because > > it doesn't track to anything actionable. > > I think we should fall back to a minimal SSP that contains only the "I- > SIGN-ALL" policy, and we let the real-world deployment and desires for > additions control more in SSP than that. SSP2 can start in a year or > two, and then we see what is needed in the real world. We can even > have experimental things in the field to test them. > > Jon > I don't think I'd have a problem with only have a "I sign everything" policy. I think the bigger issue is, as a verifier, who is the "I" who I should be looking for that assertion from when I have an unsigned message. The options appear to be, check the domain of the Sender, check the domain of the first address in the From: (the currently defined behavior), or check all addresses in the From: . My personal preference would be the latter for the entirely selfish reason that, if any domains can make that assertion it immediately becomes useful. The same does not appear to me (at least yet) to be true for the Sender. Robert > > -BEGIN PGP SIGNATURE- > Version: PGP Universal 2.6.3 > Charset: US-ASCII > > wj8DBQFHjqa2sTedWZOD3gYRAoZhAKCCalYvImeJrhB07fv6jS59s8l3LACeM7TS > v7K/BLZqwg76skcocMPmaUk= > =LHa/ > -END PGP SIGNATURE- > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor breaks email semantics
> From: [EMAIL PROTECTED] > Date: Wed, 16 Jan 2008 09:07:18 +0100 > Subject: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by firstAuthor > breaks email semantics > > If "SSP strict" is bound to the "first author" it's DOA. :-( > > I fail to see why we should create an RFC only working for > PayPal & Co. - especially while they are still too timid to > use FAIL in their SPF or PRA policies. SSP "first author" > would be far more restrictive than anything SPF or PRA do. > > Frank You seem to be asserting here that saying " I know what MTA will deliver my messages to you" and "All mail for which the author is in my administrative domain" are semantically equivalent assertions. If SSP were intended to say something about who could validly transmit those messages I could see that but since it is a policy for how I expect mail from authors within my domain to behave I don't see a useful relationship between how confident someone can be in their SPF record and how confident they can be in their SSP assertions. _ Share life as it happens with the new Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Possible issue with Parent Domain logic in SSP
> Date: Tue, 8 Jan 2008 10:34:27 -0800 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] Possible issue with Parent Domain logic in SSP > > [EMAIL PROTECTED] wrote: > > So if I am bank.com and have a significant problem with misuse of that > > exact domain and want to use SSP to help mitigate that risk but I have > > allocated a subdomain to some third part (say thirdparty.bank.com) it > > looks like my choices come down to > > 1) Publish SSP with dkim=unknown until thirdparty creates their own > > SSP record for thirdparty.bank.com > > 2) Take thirdparty.bank.com back from thirdparty and manage the DNS > > for whatever services they provide myself > > 3) Publish ssp with dkim=strict and let mail for thirdparty fail to be > > validated > > There's a fourth option that is designed to cover exactly this case: > > 4) Publish ssp with dkim=strict and t=s and it will not apply to > subdomains like thirdparty.bank.com. > > Of course, when you do this, it applies to all subdomains (and > hostnames), not just thirdparty. > > Does this address your concern? > > -Jim > Yes, I think it does. Not sure how I missed that step. Thanks, Robert _ Watch “Cause Effect,” a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Possible issue with Parent Domain logic in SSP
I was rereading the validation algorithm last night and came across something that is either a good reason not to read these drafts at night, or a potential problem for some deployments. Among the companies I have worked with over the years it is fairly common practice to allocate a subdomain to some external party who manages some service for you. For example if you have transactional mails which you want to come from your domain but are actually managed by some third party who does billing for you you might point the NS record for billing.example.com to the third party so that they can manage the MX for that domain, the website, etc... In reading the verification algorithm, since it assumes an SSP record is intended to cover not only the domain in the Originator address but also the parent of that domain this seems like it would create an issue for companies in this situation. Basically to enable these companies to create a STRICT record for their top level domain, they now need to be able to make assurances about something that is not directly in their control, specifically about a domain that they created with the specific intent that it be managed by someone else. So if I am bank.com and have a significant problem with misuse of that exact domain and want to use SSP to help mitigate that risk but I have allocated a subdomain to some third part (say thirdparty.bank.com) it looks like my choices come down to 1) Publish SSP with dkim=unknown until thirdparty creates their own SSP record for thirdparty.bank.com 2) Take thirdparty.bank.com back from thirdparty and manage the DNS for whatever services they provide myself 3) Publish ssp with dkim=strict and let mail for thirdparty fail to be validated I understand the operation efficiency that is created by assuming that a record for a parent domain covers its immediate subdomains but assuming that the practices of one domain apply to another seems like it may create some issues for the quality of those practice assertions. Hopefully I have read this wrong or someone has a better solution than the three I outlined above. Robert _ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
RE: [ietf-dkim] Re: Issue 1530 - replace use of term "suspicious"
Sorry for joining the debate a bit late. My $.02 are below Frank Ellermann wrote: > Jim Fenton wrote: > > > My suggestion: "non-compliant"/"compliant". > > If "non-compliant" is actually a "Resent-* as > specified in 2822upd with a twist" (signature > didn't survive it), then that's rather strong. > > Why not FAIL ? FAIL is short, neutral, and > some folks are used to the idea that FAIL is > a defined term. > > Frank I think FAIL actually has a stronger connotation than non-compliant. To me non-compliant just says it didn't comply with the published policy. It is a factual statement of the outcome of comparing this policy to the piece of data you have in front of you. FAIL doesn't feel either as neutral or as factually descriptive as that (key word there being feel, other people may have an entirely different feeling for that term). If the concern is that people won't understand that Suspicious is a defined term and will bring their own connotative filter is that likely to be less true for FAIL? _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] On-line Registration Closing Sunday
This week is the last chance for attendees to register online for the International Conference on Network Security. For those interested in registering before time runs out please go to: www.networksecurity2006.com Conference Program Monday, April 17 TECHNICAL SESSIONS AND PANELS 8:45 - 10:30 am Opening Session Chair: Guy Copeland VP and Assistant to the President, CSC · Introduction Guy Copeland · Keynote Speech Andy Purdy Department of Homeland Security · Issues in Wiretapping Technologies Matt Blaze University of Pennsylvania Break (10:30 – 10:45 am) 10:45 am - 12:30 pm Panel: User Authentication Technologies Chair: Radia Perlman Sun Microsystems · PKI: It's not that hard. Why don't we have it? Charlie Kaufman Microsoft · Web Services/Liberty Approach to Single Sign-on Gerald Beuchelt Sun Microsystems · Is the Identity-based Crypto the Best Solution? Terence Spies Voltage Security · PKI: Let’s Make it Happen! Bill Burr NIST · SAML Comparison to Kerberos to Support a Centralized Authoritative Source for Authentication Hank Simon Lockheed Martin Lunch (12:30 – 1:45 pm) 1:45 - 3:00 pm Mesh Network Security Chair: Russ Housley Vigil Security, LLC · Status of 802.11 Mesh and Security Donald Eastlake III Motorola · Security Issues in 802.11s William Arbaugh, UMD Jesse Walker, Intel · More on 802.11s Robert Moskowitz ICSA Labs, Cybertrust Break (3:00 – 3:15 pm) 3:15 - 4:30 pm Defending Against Denial of Service Chair: Jim Hughes Sun Microsystems · Surviving Denial of Service Andy Ellis Akamai · MITHRIL: Adaptable Security for Survivability in Collaborative Computing Sites Von Welch, NCSA Jim Basney, NCSA Himanshu Khurana, NCSA · Investigating the Impact of Real-World Factors on Internet Worm Propagation Xiaoyan Hong University of Alabama 4:30 - 5:30 pm Panel: Legislative Aspects of Security · Pat Schambach Nortel · Robert Dix Jr. Citadel Security Software · Michael Aisenberg Verisign · John Morris Center for Democracy & Technology 5:30 - 6:30 pm Reception 6:45 - 7:45 pm Tutorial: Network Incident Response Presenter: Richard Bejtlich Tao Security Tuesday, April 18 TECHNICAL SESSIONS AND PANELS 9:00 - 10:30 am Software Security Chair: Charlie Kaufman Microsoft · Why Software Breaks Andrew Lee Eset · Federal Standards and Guidelines Developed by NIST Stuart Katzke NIST · Impact of NSTISSP-11 on the Current Certification Climate for Products and Technology Keith Beatty SAIC · How can we make products and deployments more secure? Eric Cole Lockheed Martin Break (10:30 – 10:45 am) 10:45 am - 12:30 pm Network Security Protocol Issues Chair: Hilarie Orman Purple Streak, Inc. · Introduction and Comparison of IPv4 Address Resolution Protocol, ICMP Router Discovery and ICMP Redirect; and IPv6 Neighbor Discovery Protocol Security Issues Michael Wasielewski Lockheed-Martin · The ability for the Warfighter to share critical information across and between networks without leakage Adele Friedel Tenix America · Availability and Security Tradeoffs Arun Sood Task Technologies Ltd. · Firewall Traversal: Security and Scalability David McGrew Cisco Systems · Updates on IETF Security Related Working Groups Sam Hartman MIT Russ Housley Vigil Security Lunch (12:30 – 1:45 pm) 1:45 - 3:00 pm Security for Wireless and Internet Mobility Chair: Bijan Jabbari Isocore · Optimizations to Support Secure AP Transitions in 802.11 WLANs Jesse Walker Intel · 3GPP2 Network Firewall Configuration and Control Michael Paddon Qualcomm · Proactive EAP-based handover key management for mobile wireless users Madjid Nakhjiri Motorola Break (3:00 – 3:15 pm) 3:15 - 4:30 pm Panel: Internet Infrastructure Security Chair: Hilarie Orman Purple Streak, Inc. · MPLS VPN Security Harmen van der Linde Cisco Systems · DHS and Internet Infrastructure Security Marcus Sachs SRI · Routing Security Sandra Murphy Sparta · Why Routing Protocol Security isn't Seeing Wide Adoption Russ White Cisco Systems 4:30 - 5:30 pm Web Browser Security Moderator: Darren Moffat Sun Microsystems · The Sad State of Evolution of Interface to User Security with a Focus on the Web Browser Eric Greenberg Netframeworks · XML: Salvation or Struggle Donald Eastlake III Motorola · Web Browser Security Frameworks Perry Metzger Piermont · Issues in Web Browser Security Sam Hartman MIT Wednesday, April 19 TECHNICAL SESSIONS AND PANELS 9:00 - 10:30 am DNS Security Chair: Donald Eastlake III Motorola · Why isn't DNS security deployed, and would we be safer if it was? Charlie Kaufman Microsoft · DNSSEC and FISMA Sc
[ietf-dkim] Network Security 2006
International Conference on Network Security 2006, April 17-19 Only, one week remaining to take advantage of Early Bird Specials. All those registering before April 1 receive a $200 dollar discount on registration. Register at: http://www.isocore.com/networksecurity2006/onlineregis.htm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] International Conference on Network Security 2006
Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at [EMAIL PROTECTED] www.networksecurity2006.com ___ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
