datatracker.ietf.org
Sign in
Version 5.6.2.p5, 2014-08-04
Report a bug

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

Yes
No Objection
(was Discuss)
(was Discuss)
(was Discuss)
(was Discuss)

Note: This ballot was opened for revision 04 and is now closed.

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

[Chris Newman]

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?

[Cullen Jennings]

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.

[Dan Romascanu]

Comment (2008-08-26 for -07)

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

[Lars Eggert]

Comment (2008-08-11 for -07)

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?

[Mark Townsley]

Comment (2008-08-28 for -)

Support Dan's comment about the DNS review comments not being addressed.

[Pasi Eronen]

Comment (2009-12-04 for -)

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.

[Ron Bonica]

Comment (2008-08-27 for -)

I support the DISCUSS from DNSOPS/Dan