Subject: [Ietf-not43] 3.2.6 Escrow Support and other thoughts

From: [email-masked] (Rick Wesson)
Date: Tue, 5 Nov 2002 23:03:38 -0800 (PST)

some more edits and language suggestions.

-rick

Since 3.2.6 is out of band and out of scope lets remove it. If an entity
wishes to use the schemas defined by crisp for escrow thats fine but
escrow has requirements unto its self that may be in opposition to the
requirements under discussion.

3.2.6 Escrow Support

   The service MUST provide a means to escrow data of domain registrars
   to an escrow entity using a common schema.  This escrow capability
   SHOULD be "off-line" and "out-of-band" from the normal operations of
   the service.

3.2.9 DNS Label Referencing

Is it the intent of section 3.2.9 to require that the information now
provided via the internic port 43 referal whois be published somehow in
the DNS? If that is not the intent please reprase this section as it is
not clear as to the intent nor the requirement.

4.7 Serialization Definition

lets strike data escrow from this section, as we are not doing
requirements for data escrow. Unless we update our charter to deal with
escrow and move those requirements to a seporate document.

7. Security Considerations

Please add the following to the end of section 7. Security Considerations

This document contains requirements for the distribution of queries
against a mesh of pariticpiants and the possable generation and
distribution of index hints both of which could be used in the development
of DDoS attacks against the entire mesh or used to create data minning
effors by Direct Marketers (see Section 2.4.7)

---

From: [email-masked] (Andrew Newton)
Date: Wed, 06 Nov 2002 10:20:44 -0500

Comments in-line.

> requirements under discussion.

I disagree.  Being able to support serialization for escrow purposes is 
a current problem.  I attended a meeting full of registrars not too long 
ago where they agreed that none used a common format.  And I've heard 
this requirement from stated many times in the past.

I would agree with some wordsmithing on the text though.  Perhaps the 
"to an escrow entity" should be removed.  I could see how some people 
might thing it implies a single escrow authority, which is not the intent.

> not clear as to the intent nor the requirement.

No, that's not the intent.  The intent is that DNS is used to find the 
authoritative server.  As I have asked on numerous occasions for new 
language specific to this requirement, my response to your demand is 
"send text".

> effors by Direct Marketers (see Section 2.4.7)

I'm not sure I agree with the DDoS portion of this statement.  Can you 
point to a security concern in a current RFC or draft that states a 
referral system or index hint is the vulnerability causing the DDoS?

I do agree with the data mining portion.  It should probably state that 
operators should take steps to prevent this according to the 
requirements of the appropriate sections.

-andy

---

From: [email-masked] (Rick Wesson)
Date: Wed, 6 Nov 2002 11:03:15 -0800 (PST)

Andrew,

Comments in-line.

> this requirement from stated many times in the past.

yea, i've been to alot of escrow meetings too; however escrow is out of
scope for this wg, and we MUST change the wg charter to address escrow and
and produce an escrow document if you want to continue down the escrow
argument.

> might thing it implies a single escrow authority, which is not the intent.

again, wordsmithing this requirement will not change the scope of the
working group.

> language specific to this requirement, my response to your demand is

If i better understood the intent I might be able to suggest text, maybe
we could spend some time on this in the meeting so we can clarify the
intent.

> referral system or index hint is the vulnerability causing the DDoS?

its of the same vein that a zone file is used to in a DDoS either using or
against dns servers. I know of no RFC or I-D documenting the attacks but I
sure have experenced them. The same goes for data mining using a zonefile
as a set of hints to mine from, which may appear as a DDoS attack against
underprovisined whois servers.

the mining that occurs on whois.crsnic.net is just mining because the
services is over so provisioned that mining doesn't impeed its regular
service and the opperator of whois.crsnic.net never publicly complains
about the mining.

> requirements of the appropriate sections.

i'm ok with that.

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 13:59:52 -0800 (PST)

>    SHOULD be "off-line" and "out-of-band" from the normal operations of

I have considered escrow support in scope largely because it seemed
like a good idea to have the same data structures which support CRISP
available as a schema for escrow.  The statement in the Charter that
"CRISP provides a uniform access to and view of data that may be held
in disparate backend servers" could be read to support that view.

On the other hand, the mechanisms by which escrow takes place are
clearly out of scope here, and I am inclined to agree that 
since a requirement here will not get specified in the crisp protocol
that we either leave it out or shift it to:

3.2.6

    The CRISP schema MAY be usable in other protocols or support
    systems.  As an example, a registrar MAY choose to use the 
    CRISP schema as part of an off-line, out-of-band escrow service
    in order to enhance the ability to reuse the escrowed data
    in systems with disparate backed servers" 

> effors by Direct Marketers (see Section 2.4.7)
  
This language doesn't seem quite right.  How about:

   This document contains requirements for the distribution of queries
   among a mesh of participating service providers.  Protocols proposed
   to meet these requirements must be able to protect against the use of
   that distribution system as a vector of DDoS attacks or unauthorized
   data mining.