Extensions to the IODEF-Document Class for Reporting Phishing
draft-cain-post-inch-phishingextns-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Lisa Dusseault |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2010-04-05
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-04-05
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-04-05
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-04-01
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-03-25
|
07 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-03-25
|
07 | (System) | IANA Action state changed to In Progress |
2010-03-24
|
07 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2010-03-24
|
07 | Cindy Morgan | IESG has approved the document |
2010-03-24
|
07 | Cindy Morgan | Closed "Approve" ballot |
2010-03-24
|
07 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2010-03-23
|
07 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault |
2010-01-15
|
07 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2009-12-04
|
07 | Pasi Eronen | [Ballot comment] Couple of nits: - Section 5.9.2.6.2: the UML for iodef:Contact doesn't match RFC 5070 (some multiplicities, attribute types, attribute names don't match) - … [Ballot comment] Couple of nits: - Section 5.9.2.6.2: the UML for iodef:Contact doesn't match RFC 5070 (some multiplicities, attribute types, attribute names don't match) - Section 5.10: the UML should have (1..*) for iodef:System (version -06 had this right). - Section 5.11.2.1: "One Value of STRING": should be INTEGER - Appendix B.2: the contents of phish:Message seem to be garbled. For example: - The " to: ..." line following Return-path seems weird (is it intended to be part of the Return-path header?) - The "Type" header seems strange -- should it be "Content-Type"? But that body is not actually multipart/mixed type... - It's not quite clear where the header ends and body text starts. If the last header line is "X-Spam-Level", then the first ~10 lines of the body text aren't actually the same as in B.1. - Appendix C.1/C.2: The URL and date in email in C.1 arent't the same as in the report in C.2. - The schema should *NOT* have any schemaLocation URLs pointing to www.iana.org. |
2009-12-04
|
07 | Pasi Eronen | [Ballot discuss] |
2009-12-04
|
07 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-11-24
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-11-24
|
07 | (System) | New version available: draft-cain-post-inch-phishingextns-07.txt |
2009-10-28
|
07 | Tim Polk | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Tim Polk |
2009-08-16
|
07 | Pasi Eronen | [Ballot discuss] [Updated for version -06] I think this is a potentially very valuable document, and version -06 is a big improvement over the previous … [Ballot discuss] [Updated for version -06] I think this is a potentially very valuable document, and version -06 is a big improvement over the previous ones. However, I think the following issues need to be addressed one way or another before this is ready to be published: The document should use the extensibility mechanisms already present in iodef:System and iodef:Contact instead of copying the types. The explanation given in Section 5.2 (and schema comments) seems wrong -- the extensibility mechanisms already present (AdditionalData) seem totally adequate for adding the confidence information (which has to be an element instead of an attribute, though). The example in Appendix C.2 is not even well-formed XML (so obviously can't validate with the schema). Minor clarifications and nits: - Title: the document seems to be mainly for reporting phishing incidents (not other types of fraud -- e.g. there's draft-mraihi- inch-thraud for transaction fraud); the title should reflect this. - It seems reporting of spam incidents was removed in version -06, but couple of places haven't been updated accordingly: the abstract, Section 5.17.3, and Section 6 (1st paragraph). - Section 5.9.2.6 doesn't say how the DNS records are represented. There's a reference to RFC 1034 (which suggests DNS on-the-wire encoding), but that's highly unlikely to be correct (especially since the XSD data type is iodef:MLStringType). Probably the intent is the master file format from RFC 1035. - Section 5.9.4: the list matches neither RFC 3982 (which has "other", but not "unknown") nor the schema. - Section 5.10.3: "One iodef:System" does not match the UML. - Section 5.17/5.17.2: element name doesn't match the schema. - Section 5.17.2 is still very vague about what exactly this element contains. Probably the intent is "One email message (header followed by body) as specified in [RFC5322]" (but that means any SMTP envelope data has to be converted to message headers -- and it seems the examples in Appendix B/C do exactly that). - Section 6.1, it's not quite clear how one would supply more information than is possible. - Section B.2: the contents of psish:Message seem to be garbled in the XML (it's nowhere near a valid email message). - Appendix C: The examples should use domain names and phone numbers reserved for documentation use (see RFC 2606 and http://en.wikipedia.org/wiki/Fictitious_telephone_number). - Schema, PhraudReport/@ext-value: should not have 'fixed=""' - Schema is missing types for WindowsRegistryKeysModified/Key/Name and Value - [RFC3688] probably doesn't need to be normative reference. - There's bunch of elements/attributes with type xs:string that probably should be iodef:MLStringType (basically, most places that contains user-entered free-form text). |
2009-07-01
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-07-01
|
06 | (System) | New version available: draft-cain-post-inch-phishingextns-06.txt |
2008-08-28
|
07 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2008-08-28
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-08-28
|
07 | Mark Townsley | [Ballot comment] Support Dan's comment about the DNS review comments not being addressed. |
2008-08-28
|
07 | Pasi Eronen | [Ballot discuss] I think this is a potentially very valuable document. However, currently it looks very much like work-in-progress, and clearly needs more work. However, … [Ballot discuss] I think this is a potentially very valuable document. However, currently it looks very much like work-in-progress, and clearly needs more work. However, given its potential beneficial impact, I think it's definitely worth our time to work on this and get things right before publication. I have quite large number of comments, and I expect that more than document revision will be needed. Listing major issues first: The document really needs a terminology section, needs to be more consistent in its use of terminology, and needs to keep distinct concepts more clearly delineated. To give couple of examples: - Probably the five terms "collection point", "collection site", "credential collection point", "data collection site", "collector site" intend to mean the same thing. - Applying the words "phishing"/"phisher"/"phish", "fraud"/"phraud", and similar to spam incidents is highly confusing. - I found using the "phish" as a noun confusing (What's a phish? Is it the email message I get, or the whole phishing attack/incident, or something else?). - Calling all this a "PhraudReport" is also confusing (especially since we have other IODEF profiles for different types of fraud); having PhishingReport and SpamReport, and describing these in separate top-level sections of the document, would IMHO be much clearer. - The semantics of "lure" and "lure source" probably need some clarification as well (in some cases, you get the impression the "lure" is e.g. the email message; in others, some malware, etc.). The ballot writeup says "The XML defined in this document was validated using multiple XML tools by more than one party." Despite this, the XML schema isn't actually a valid XML schema, and even after fixing the obvious fatal error (missing xs:import), neither of the examples are actually valid. Sections 4.5 and 4.6: The use of FraudParameter with different FraudTypes probably needs some clarification. it's not quite clear how a malware would be identified here; e.g. "malwareemail", "dnsspoof", "keylogger", "ole", and "cve" all seem to include some form of malware, and they're not obviously distinct categories (but a PhraudReport contains only one FraudType value). Section 4.9.2.7.2 defines a new phish:DomainContact type to add new role values, and confidence attribute. These should be done using the extensibility mechanisms present in iodef:Contact (ext-role and AdditionalData). However, the text and schema about DomainContact aren't quite consistent (probably result of changing something from earlier versions). Section 4.9.3 probably needs some advice on the difference between 'spoofed' vs. 'innocent-hijacked', and also 'fraudulent' vs. 'innocent-hacked'. Section 4.9.5.2: just import DigestMethod/DigestValue from xmldsig; that way you get algorithm agility, too (current schema doesn't even allow definining new hash algoritms). Section 4.9.6: This wouldn't work if file names contain commas (a valid character in file names on e.g. Windows and Unix), and doesn't match the XML schema anyway (which uses spaces as separates -- even worse, since that's more common character in file names than comma). Section 4.11.2/schema: defines a new phish:System element; it should probably just use the extensibility mechanisms in iodef:System. Section 4.13.1: should describe the semantics of these types (couple of words per type). Section 5.1/5.2: this section probably needs some clarification about the mandatory elements. When first reading it, I thought it's just summarizing the requirements from RFC 5070 and elsewhere from this document. But it seems it's actually placing new requirements as well in couple of cases (e.g. iodef:Assessment/iodef:Confidence, iodef:Contact/iodef:ContactName). If this isn't the intention, the text needs fixing; if placing additional MUST-level requirements is intended, they should be listed separately. Several places in the schema could benefit from defining extension points. Minor clarifications and nits: - Title: the document seems to be mainly for reporting phishing and spam incidents (not other types of fraud, or other crimeware). - Section 3.1, "ext-pupose" -> "ext-purpose" - Section 3.2, "as defined in A" -- sentence ends unexpectedly - Section 4.1, PhraudReport UML, "CorrelationData" is misspelled - Section 4.5.1, "REQUIRED" does not match {0..1} in UML. - Sections 4.5/4.6.1: malware don't really have CVE identifiers; they might have CME identifiers, though. - Section 4.9, "REQUIRED. One value." does not match {1..*} in UML. - Section 4.9.2 and 4.9.2.5, "Nameserver" is misspelled - Section 4.9.2.5.1, "Zero or more values" does not match schema - Section 4.9.2.6.1, "superior" is probably not correct here. - Section 4.9.2.6.5, how is resource data encoded? (there's a reference to RFC 1034, which suggests DNS on-the-wire encoding; but no reference to RFC 1035, which would specify the master file format). - Section 4.9.2.7.1: "One iodef:DNSNAME", there's no such type in iodef. - Section 4.9.2.7.2.1, "with the values identified in [CRISP]" is not accurate; some of these don't seem to occur in CRISP? - Section 4.9.4, "The below enumerated list is taken verbose from..."; no such list seems to exists in RFC 4933 (it seems to come from RFC 3982 only). - Section 4.9.5.3: having both "string" and "binary" seems redundant here. - Section 4.9.5.3.3: type should be hexBinary, not string. - Section 4.9.5.3.3: the default value is highly unobvious (the default of "00...0" would be what most folks would expect, I think), so I'd suggest either changing it, or making the attribute mandatory. - Section 4.9.7: since this is specific to Windows, I'd suggest renaming it to WindowsRegistryKeysModfiied - Section 4.9.7.1.2: encoded how? (same way as in Windows REG files, plus a reference to Microsoft KB article 310516, would be one option. As base64binary/hexBinary would be another.). - Section 4.10.1: acronyms IDS, IPS, and ISP should be expanded (especially since ISP probably means something else than "Internet Service Provider" here). - Section 4.10.3, "One iodef:System" doesn't match the UML. - Section 4.11.2, "either the email address .." should the sentence continue with "or <...>" part? - Section 4.13: there are two distinct elements named "ArchivedData" (both the container, and the child element) -- that's very confusing, and incorrect in the UML. - Section 4.13.2, this doesn't seem to allow any other forms of archives that gzip -- that's probably not intentional. - Section 4.17.2.1/4.17.2.3.1.1/4.17.2.3.2: encoded how? as RFC2822 message? (or would the envelope be present, too)? - Section 4.17.2.1 and 4.17.2.4: is one of these sections redundant? - Section 4.17.2.2: does this mean draft-shafranovich-feedback-report-05? If so, a reference is needed. - Section 4.17.2.2 "should be encoded as a character string" sounds extremely vague. - Section 4.17.2.3.1.1 "the header element contains a sequence of email header lines" probably should be "contains a single email header line"? - Section 4.9.4, when reading this text, I got the impression that the field would contain e.g. value "reservedDelegation" (and the " - permanently inactive" part was just a comment/description). This doesn't match the schema, though. - Section 5.1/5.2, "" misspelled element name - Section 5.2, typo "iodef:Incdent" - Section 5.3, it's not quite clear how one would supply more information than is possible. - There's bunch of attributes with type xs:string that probably should be iodef:MLStringType (basically, most places that contains user-entered free-form text). - The schema and examples shouldn't contain unnecessary namespace references (xsi, ns, hfp, ds), or commented out declarations from earlier versions (one instance of "xs:redefine"). - [ARF] is a normative reference. - [RFC3688] probably doesn't need to be normative reference. - FIPS 180-1 has been superceded by FIPS 180-2. - Schema is missing types for RegistryKeysModified/Key/Name and Value - Section B.2: is using the same IP address for LureSource and OriginatingSensor intentional? - Section B.2: the contents of psish:Message seem to be garbled (e.g. line breaks are missing). - Section C.1: the body of the email seems to be garbled (it should be HTML, but isn't), - Appendix B/C: The examples use domain names, telephone numbers, and IP addresses that exist and belong to someone. Probably should use names/numbers/addresses reserved for documentation use instead. |
2008-08-28
|
07 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-08-28
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-08-28
|
07 | Chris Newman | [Ballot comment] I support Lisa's discuss. Some problems with XML schema are explained in BCP 70 section 4.7. Here's one excerpt: o Protocols may … [Ballot comment] I support Lisa's discuss. Some problems with XML schema are explained in BCP 70 section 4.7. Here's one excerpt: o Protocols may or may not insist that all corresponding protocol elements be valid, according to the validity mechanism chosen; in either case, the extensibility design should be clear. What happens if the data is not valid? |
2008-08-27
|
07 | Chris Newman | [Ballot comment] I support Lisa's discuss |
2008-08-27
|
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-08-27
|
07 | Cullen Jennings | [Ballot comment] I'm not sure that voip is the fraud type you want in section 4.5. It seems that all of these schemes can happen … [Ballot comment] I'm not sure that voip is the fraud type you want in section 4.5. It seems that all of these schemes can happen on a telephone call regardless of if it is voip, pstn, or some other type. It is often hard for the sensor to even know what type the call was orignated as. I think you should consider changing voip to telephone and I support the idea of an actually extensible registry for these. |
2008-08-27
|
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-08-27
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-08-27
|
07 | Lisa Dusseault | [Ballot discuss] DISCUSS: Shouldn't there be an IANA registry for FraudType values? So far values include things like "phishemail", "im", "malwareemail", "fraudsite" and "voip". Although … [Ballot discuss] DISCUSS: Shouldn't there be an IANA registry for FraudType values? So far values include things like "phishemail", "im", "malwareemail", "fraudsite" and "voip". Although there are values for "other" and "unknown" it seems pretty likely that this list will be extended. When ENUMs like FraudType are extended, will implementations break? XML Schema is not good when used for validating XML documents containing extensions. The "company.com" domain in appendix C.1. Received Lure, actually exists, and is registered to "Company.com, Inc.". The domain "nospa.us" is not registered but could be. I'm particularly concerned about the implication that company.com is a phisher. COMMENTS: The diagram in figure 2.1 has a link from "Collection point" back to "Fraudster". I can't make sense of it. |
2008-08-27
|
07 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
2008-08-27
|
07 | Ron Bonica | [Ballot comment] I support the DISCUSS from DNSOPS/Dan |
2008-08-27
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-08-27
|
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-08-27
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2008-08-26
|
07 | Dan Romascanu | [Ballot comment] 1. 3.3. Correctness of Fraud Activity Reports The Fraud Activity Report MUST pass XML validation using the schema defined … [Ballot comment] 1. 3.3. Correctness of Fraud Activity Reports The Fraud Activity Report MUST pass XML validation using the schema defined in [RFC5070] and the extensions defined in of this document. The title of this subsection should be renamed "Syntactical Correctness ..." because it could otherwise be perdevied to deal with the validation of the report content. 2. Section 4.4 - REQUIRED. STRING. The version shall be the value 0.04 to be compliant with this document. [This value will be changed to "1.0" when this document progresses.] This should be marked as a note to RFC Editor and s/progresses/is approved/ 3. There are several ENUM attributes (FraudType, Role, Confidence, SystemStatus, OrigSensorType) that place 'other' or 'unknown' values at the end of the enum list. The better practice is to place such special values at the begining, so that if and when the model or report is extended in the future such special values do not find themselves in the middle of the enumerated lists. 4. 4.5. FraudType attribute 5. dnsspoof. This choice does not have a related FraudParameter. This is used for a spoofed DNS (e.g., malware changes localhost file so visits to www.example.com go to another IP address chosen by the fraudster). DNS spoofing is usually to involve forged DNS responses, not manipulating the resolution path. It could be argued that in the case described here, DNS doesn't even get used. 5. 4.9.2. DomainData element Zero or more element values. The DomainData element describes the registration, delegation, and control of a domain used to source the lure. Capturing the domain data is very useful when investigating or correlating events. It is unclear what "domain used to source the lure" means. Is it the header or envelope From address of an email? 6. 4.9.2.6.1. owner element REQUIRED. One String Value. This element identifies the superior node in the DNS hierarchy. "Superior node" is either a wrong description (Is "example.com" superior to "www.example.com"?) or an outright misunderstanding of what a "DNS owner name" means. 7. 4.9.2.6.3. class element Zero or one value of a STRING. This field contains one value from the IANA DNS Domain System Class Registry. The value will be the two character representation of class, instead of a decimal number to ease data entry from standard DNS tools. The default value for this field is "IN" to note the Internet. This seems to be in conflict with the schema defined later, which makes this mandatory. Also I'm not sure why and how anything else but "IN" would come into play. 8. 4.9.2.7.1. SameDomainContact REQUIRED. One iodef:DNSNAME. The SameDomainContact element is populated with a domain name if the contact information for this domain is identical to that name in this or another report. Implementors are cautioned to only use this element when the domain contact data returned by the registrar is identical. This tacitly assumes a "thin registry" model; s/registrar/registrar or registry/ 9. 4.9.3. SystemStatus attribute REQUIRED. ENUM. The SystemStatus attribute assesses a domain's involvement in this event. Domains are elements in a name space, not acting parties. How can a domain be "involved" in anything? The IETF should resist the temptation to standardize colloquial abuse of the meaning of "domain". 1. spoofed. This domain or system did not participate in this event, but its address space or DNS name was forged. It's just identifiers, but "spoofed" and "forged" appear to me as different scenarios. 10. 4.9.4. DomainStatus attribute ENUM. The DomainStatus attribute describes the registry status of a domain at the time of the report. The below enumerated list is taken verbose from the 'domainStatusType' of the Extensible Provisioning Protocol[RFC4933] and "Domain Registry Version 2 for the Internet Registry Information Service" internet-draft [CRISP]. See the other comment about the [CRISP] reference and note that the document is no longer an Internet-Draft, but an RFC 11. 4.17.1. EmailCount s/enumerates/contains/ 12. I support Lars's DISCUSS about the need to clarify that the Anti-Phishing Working Group is not an IETF WG. |
2008-08-26
|
07 | Dan Romascanu | [Ballot discuss] The DISCUSS and COMMENT are partially based on the DNS Directorate review by Peter Koch. The issues raised in the review were not … [Ballot discuss] The DISCUSS and COMMENT are partially based on the DNS Directorate review by Peter Koch. The issues raised in the review were not answered by the authors. 1. The structure of a DomainData element is as follows: +--------------------+ | DomainData | +--------------------+ | |<>----------[ Name ] | |<>--(0..1)--[ DateDomainWasChecked ] | ENUM SystemStatus |<>--(0..1)--[ RegistrationDate ] | ENUM DomainStatus |<>--(0..1)--[ ExpirationDate ] | |<>--(0..*)--[ Nameservers ] | |<>--(0..*)--[ DNSRecord ] | |<>--(0..*)--[ DomainContacts ] +--------------------+ Figure 4.3 The DomainData element 4.9.2.1. Name REQUIRED. One value of iodef:MLStringType [RFC5070], Section 2.4]. The Name element is the domain name used in this event. How is usage defined here? Also, judging from the following, if the authors believe that the domain name should be modified to just cover the "registry level", they should make that explicit: If "www.example.com" was "used", would "www.example.com" or just "example.com" appear in the report? 2. [CRISP] reference is broken - the name of the RFC is different, the protocol is IRIS and not CRISP. 3. of the role attribute should be used, with the role-ext attribute value chosen from one of the following values: 1. registrant. This identified Contact is the domain registrant. 2. registrar. This contact identifies the registrar of this domain. 3. billing. This entry is the billing or financial contact. 4. technical. This contact deals with technical issues. 5. administrative. This contact handles administrative matters for this domain. 6. legal. This entry deals with legal issues for this domain. 7. zone. This entry controls the DNS zone information. 8. abuse. This entry accepts abuse issues. 9. security. This entry accepts security issues. Why have the attribute values been chosen to differ from those defined in IRIS-DREG? 10. domainOwner. This lists the owner of the domain. This doesn't appear in RFC 3982. How is the "owner" different from the "registrant"? Even though the scheme seems to already be used, the duplication is confusing from a DNS perspective and should be either explained or eliminated. 11. ipAddressOwner. This entry identifies the assignee of the IP address space. Which IP address space? 12. hostingProvider. This contact is the hosting provider of this domain. At best, this should be _a_ provider, not _the_. 4. 4.9.7.1.1. Name element One STRING, representing the WINDOWS Operating System Registry Key Name. shouldn't the document then at least have a reference to such Key Names' syntax? Better yet, no OS would be preferred over others and this be redefined as "vendor specific key" or similar. 5. 4.17.2.2. ARFText Zero or one value of STRING. The Messaging Anti-Abuse Working Group (MAAWG) defined a format for sending abuse and list control traffic to other parties. Since many of these reports will get integrated into incident processes, the raw Abuse Reporting Format [ARF] may be inserted into this element. This seems to suggest a normative reference to the "Abuse Reporting Format", but the [ARF] reference is informative only and, more importantly, is MAAWG eligible for normative references at all? |
2008-08-26
|
07 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2008-08-25
|
07 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
2008-08-22
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-08-15
|
07 | (System) | Removed from agenda for telechat - 2008-08-14 |
2008-08-12
|
07 | Pasi Eronen | State Changes to IESG Evaluation - Defer from IESG Evaluation by Pasi Eronen |
2008-08-11
|
07 | Lars Eggert | [Ballot comment] Section 4.4., paragraph 1: > REQUIRED. STRING. The version shall be the value 0.04 to be > compliant with this document. … [Ballot comment] Section 4.4., paragraph 1: > REQUIRED. STRING. The version shall be the value 0.04 to be > compliant with this document. [This value will be changed to "1.0" > when this document progresses.] Is the text in brackets an RFC Editor Note, i.e., should the RFC Editor change 0.04 to 1.0? |
2008-08-11
|
07 | Lars Eggert | [Ballot discuss] > D. Jevans > The Anti-Phishing Working Group DISCUSS-DISCUSS: I'm a bit concerned that the name of the "Anti-Phishing Working Group" … [Ballot discuss] > D. Jevans > The Anti-Phishing Working Group DISCUSS-DISCUSS: I'm a bit concerned that the name of the "Anti-Phishing Working Group" here and in the contributors section (where it is even abbreviated as "APWG") makes it sound like this is an IETF activity when it's not. I'd like to discuss if an IESG Note should be added to clarify this? |
2008-08-11
|
07 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-07-30
|
07 | Tim Polk | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk |
2008-07-30
|
05 | (System) | New version available: draft-cain-post-inch-phishingextns-05.txt |
2008-07-29
|
07 | Tim Polk | Placed on agenda for telechat - 2008-08-14 by Tim Polk |
2008-07-29
|
07 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
2008-07-29
|
07 | Tim Polk | Ballot has been issued by Tim Polk |
2008-07-29
|
07 | Tim Polk | Created "Approve" ballot |
2008-06-25
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes. |
2008-06-20
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-06-12
|
07 | Amanda Baber | IANA Last Call comments: Action #1: Upon approval of this document, the IANA will make the following assignments in the "NS" registry at http://www.iana.org/assignments/xml-registry/ns.html ID … IANA Last Call comments: Action #1: Upon approval of this document, the IANA will make the following assignments in the "NS" registry at http://www.iana.org/assignments/xml-registry/ns.html ID | URI | Registration Template | Reference iodef-phis-1.0 | urn:ietf:params:xml:ns:iodef-phish-1.0 | | [RFC-cain-post-inch-phishingextns-04] ---- registration template ----- o XML Namespace URN/URI: * tf:params:xml:ns:iodef-phish-1.0 o Contact: * Patrick Cain pcain@coopercain.com * David Jevans dave.jevans@antiphishing.org o XML: * None. ---- registration template ----- END Action #2: Upon approval of this document, the IANA will make the following assignments in the "Schema†registry at http://www.iana.org/assignments/xml-registry/schema.html ID | URI | Filename | Reference iodef-phis-1.0 | urn:ietf:params:xml:schema:iodef-phish-1.0 | | [RFC-cain-post-inch-phishingextns-04] The schema is in appendix A of the document. We understand the above to be the only IANA Action for this document. |
2008-05-30
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2008-05-30
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Richard Barnes |
2008-05-23
|
07 | Amy Vezza | Last call sent |
2008-05-23
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-05-23
|
07 | Tim Polk | State Changes to Last Call Requested from Publication Requested::AD Followup by Tim Polk |
2008-05-23
|
07 | Tim Polk | Last Call was requested by Tim Polk |
2008-05-23
|
07 | (System) | Ballot writeup text was added |
2008-05-23
|
07 | (System) | Last call text was added |
2008-05-23
|
07 | (System) | Ballot approval text was added |
2008-05-22
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-05-22
|
04 | (System) | New version available: draft-cain-post-inch-phishingextns-04.txt |
2008-05-14
|
07 | Tim Polk | State Changes to Publication Requested::Revised ID Needed from Publication Requested by Tim Polk |
2008-03-20
|
07 | Tim Polk | Area acronymn has been changed to sec from gen |
2008-02-29
|
07 | Tim Polk | Responsible AD has been changed to Tim Polk from Sam Hartman |
2008-02-25
|
07 | Cindy Morgan | PROTO file for draft-cain-post-inch-phishingextns-03.txt, which has been waiting for the completion of "The Incident Object Description Exchange Format", RFC 5070. Template … PROTO file for draft-cain-post-inch-phishingextns-03.txt, which has been waiting for the completion of "The Incident Object Description Exchange Format", RFC 5070. Template for the Document Shepherd Write-Up for individual submissions via the IESG. (1.a) Who is the Document Shepherd for this document? Tony Hansen Has the Document Shepherd personally reviewed this version of the document Yes and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes (1.b) Has the document had adequate review both from key members of the interested community and others? Yes. This document was generated within the INCH working group and had completed WG last call. Incorporation of comments received coupled with a dependency on the base INCH WG document caused the document to not be revised in time before the WG closed. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. As the goal of the document is to define a format for reporting fraudulent activity amongst CSIRT teams, organizations, ISPs, and law enforcement agencies, the document has had substantial non-IETF review. The document had four revisions within the INCH WG, has been reviewed by WG members, has been commented on by the Anti-Phishing Working Group, various Internet registries, and members of the CSIRT community (via the FIRST organization). (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? The INCH working group itself was small, with about half of its active members behind the effort on this document. Support for the document was also expressed within the Anti-Phishing Working Group, various Internet registries, and members of the CSIRT community (via the FIRST organization). There are a handful of CSIRTs and fraud-repository organizations who have agreed to share data using this format. There is no known opposition to the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) N/A (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Yes. The only warnings are two erroneous ones about two example version numbers being mistaken for IPv4 addresses, the note saying that the reference to RFC-IODEF needs to be updated, and a comment about the reference to the SHA NIST document. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes (1.h) Has the document split its references into normative and informative? Yes Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No. (The reference to RFC-IODEF needs to be updated now that it is in the RFC Editor queue.) If such normative references exist, what is the strategy for their completion? N/A Are there normative references that are downward references, as described in [RFC3967]? No If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. N/A (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes Are the IANA registries clearly identified? Yes. The IANA consideration section is verbatim to what exists in the base IODEF document to ensure consistency. Since that document was acceptable, we expect that this one is appropriate. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. N/A If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. The XML was validated by the Document Shepherd. The document author also validated the XML using multiple tools. (The same author/tool combination was used to validate all the other INCH WG schemas.) (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are specified in XML and are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. Working Group Summary Testing and implementation of this document in the INCH WG had major impact on the base IODEF Document as these tests were the first time that portions of IODEF were used. Document Quality The Anti-Phishing Working group, and Sparta, Inc (under US gov't funding) have independent implementations that create and accept the formats defined in this document. There are a handful of CSIRTs and fraud-repository organizations who have agreed to share data using this format. The XML defined in this document was validated using multiple XML tools by more than one party. |
2008-02-25
|
07 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2007-10-25
|
03 | (System) | New version available: draft-cain-post-inch-phishingextns-03.txt |
2007-08-24
|
02 | (System) | New version available: draft-cain-post-inch-phishingextns-02.txt |
2007-06-28
|
01 | (System) | New version available: draft-cain-post-inch-phishingextns-01.txt |
2006-10-17
|
00 | (System) | New version available: draft-cain-post-inch-phishingextns-00.txt |