Subject: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt

From: Peter Koch <[email-masked]>
Date: Tue, 12 Aug 2008 12:06:08 +0200

Hello,

this is a review of <draft-cain-post-inch-phishingextns-05.txt>.  Its
primary purpose is identifying DNS related issues as input to further
review by the OPS and INT area directors.

Regards,
  Peter Koch

>  Extensions to the IODEF-Document Class for Reporting Phishing, Fraud,
>                           and Other Crimeware
>                  draft-cain-post-inch-phishingextns-05

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

This headline should be renamed "Syntactical Correctness ..." because
it could otherwise be perdevied to deal with the validation of the
report content.

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

> 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 to me what "domain used to source the lure" means.  Is
it the header or envelope From address of an email?

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

> 4.9.2.6.  DNSRecord element
> 
>    Zero or more values.  This element allows the reporter to duplicate
>    the DNS record data as defined by [RFC1034], and returned by the DNS.
>    Including this information allows for tracking, trending, and
>    identification of the very transient DNS mapping and structure of
>    crimeware domains.
> 
>    +----------------+
>    | DNSRecord      |
>    +----------------+
>    |                |<>--(1..1)--[ owner ]
>    |                |<>--(1..1)--[ type ]
>    |                |<>--(0..1)--[ class ]
>    |                |<>--(0..1)--[ ttl ]
>    |                |<>--(1..1)--[ rdata ]
>    +----------------+
> 
>              Figure 4.4 The DomainContacts element

I wonder why we do not already have an XML schema describing DNS RRs.

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

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

Not being an XML expert this still 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.

> 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/;

> 4.9.2.7.2.1.  Role attribute
> 
>    REQUIRED.  ENUM.  The role attribute is extended from the iodef:role-
>    ext attribute with values identified in [CRISP].  The role-ext value

The reference is broken. Also, the protocol's name is IRIS, not CRISP.

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

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

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

NIT: no longer an "internet-draft".

> 4.9.7.1.1.  Name element
> 
>    One STRING, representing the WINDOWS Operating System Registry Key
>    Name.

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

> 4.17.  EmailRecord element
> 
>    Extensions are also made to the iodef:Incident.EventData element to
>    include the actual email message received in phishing lure or
>    widespread spam emails.  The ability to report spam is included
>    within a PhraudReport to support exchanging information about large-
>    scale spam activities related to phishing, not necessarily a single
>    spam message to a user.  As such the spam reporting mechanism was not
>    designed to minimize overhead and processing, but to support other
>    widely-used spam reporting formats such as the MAAWG's Abuse
>    Reporting Format [ARF].
> 
>    Reporting of the actual mail message is supported by choosing one of
>    three methods.  First, an ARF message may be included.  Second, the
>    message may be included as one large string.  Third, the header and
>    body components may be dissected and included as a series of strings.

[...]

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

> Appendix B.  Example Virus Report

The examples in this appendix contains lots of non-RFC2606 domain names
and non-reserved IP addresses.
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Aug 2008 12:18:04 +0200

Thanks, Peter. 

I will forward this also to the IESG and will discuss with the INT and
SEC Area Directors what needs to be turned into clocking comments. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Koch
> Sent: Tuesday, August 12, 2008 1:06 PM
> To: Patrick Cain; David Jevans
> Cc: [email-masked]
> Subject: [dns-dir] review of draft-cain-post-inch-phishingextns-05.txt
> 
> Hello,
> 
> this is a review of 
> <draft-cain-post-inch-phishingextns-05.txt>.  Its primary 
> purpose is identifying DNS related issues as input to further 
> This headline should be renamed "Syntactical Correctness ..." 
> because it could otherwise be perdevied to deal with the 
> validation of the report content.
> 
> > 4.5.  FraudType attribute
> 
> 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.
> 
> It is unclear to me what "domain used to source the lure" 
> means.  Is it the header or envelope From address of an email?
> 
> 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?
> 
> "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.
> 
> > 4.9.2.6.3.  class element
> > 
> Not being an XML expert this still 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.
> 
> This tacitly assumes a "thin registry" model; 
> s/registrar/registrar or registry/;
> 
> Why have the attribute values been chosen to differ from 
> those defined in IRIS-DREG?
> 
> This doesn't appear in RFC 3982.  How is the "owner" 
> different from the "registrant"?
> 
> 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".
> 
> It's just identifiers, but "spoofed" and "forged" appear to 
> me as different scenarios.
> 
> Ouch;  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.
> 
> 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?
> 
> The examples in this appendix contains lots of non-RFC2606 
> domain names and non-reserved IP addresses.