Extensions to the IODEF-Document Class for Reporting Phishing
draft-cain-post-inch-phishingextns-07

[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 ...

[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.

[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).

[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, "<iodef:contact iodef:name="">" 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.

[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 ...

[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.

[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?

[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 ...

[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?

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 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 | <see <br=""/>below> | [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 |
<appendix-a> | [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.