Extensions to the IODEF-Document Class for Reporting Phishing
Note: This ballot was opened for revision 04 and is now closed.
(Tim Polk) Yes
Jari Arkko No Objection
(Ron Bonica) No Objection
Comment (2008-08-27 for -)
I support the DISCUSS from DNSOPS/Dan
(Ross Callon) No Objection
(Lisa Dusseault) (was Discuss) No Objection
(Lars Eggert) (was Discuss) No Objection
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?
(Pasi Eronen) (was Discuss) No Objection
Couple of nits: - Section 126.96.36.199.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 188.8.131.52: "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.
(Russ Housley) No Objection
(Cullen Jennings) No Objection
Comment (2008-08-27 for -)
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.
(Chris Newman) No Objection
Comment (2008-08-28 for -)
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?
(Jon Peterson) No Objection
(Dan Romascanu) (was Discuss) No Objection
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 <AppendixA> 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. 184.108.40.206.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. 220.127.116.11.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. 18.104.22.168.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.
(Mark Townsley) No Objection
Comment (2008-08-28 for -)
Support Dan's comment about the DNS review comments not being addressed.