Skip to main content

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