Subject: Re: Alternative to TXT or new RR was: Comments on draft-ietf-marid-core-01 xml use

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Jun 2004 11:58:48 -0700

On Thu, 2004-06-10 at 23:15, Michel Py wrote:
> > Douglas Otis wrote:
> > Looking to simplify an aspect of deployment must consider
> > the entire process. To premise a design based upon an
> > architecture where SMTP rarely enters without a bridging
> > component may place too much emphasis on this aspect over
> > perhaps more pressing matters having to do with the overall
> > integrity of the system.         
> 
> No argument here, has to see the big picture.
> 
> > There is a problem in that the "core" proposal is adding
> > restrictions on a TXT record where few exist but stops short
> > of ensuring further changes occur as a result of a standards
> > process.
> 
> A very valid point indeed; however I think you do not put it in the
> right context, and here's why:
> 
> In _appearance_, we are facing the following decision to make: pick one
> out of the following three:
> 
> 1. We do it quick and dirty with TXT.
> 2. We do it right and slow with a new RR type.
> 3. We say that we'll go with 1 as a temporary measure and with 2 in the
> long run.
> 
> Two problems here:
> a) All three have major shortcomings: 1 is dirty, 2 is too slow, and 3
> is a bastard that leaves us with having to support both.
> b) This "choice" is something we have only in _appearance_. In reality,
> we don't have a choice and here's why:
> 
> - If this WG leans towards 1, there will be enough opposition about the
> solution being dirty (and for good reasons) to stall the process and
> never achieve the "quick" part of it.
> 
> - If this WG leans towards 2, a schism that will split the SPF community
> will inevitably happen, and everyone loses. Not only the SPF spinoff
> will deploy much sooner, likely making MARID irrelevant due to
> time-to-market issues; but even worse the "old-new" SPF will still put
> whatever they see fit in TXT outside of any IETF standard, which was
> your fear in the first place.
> 
> - If this WG leans towards 3, it pleases no-one and goes nowhere. I have
> seen enough "3 month temporary" solutions that are still in service 10
> years later to believe in this one.
> 
> 
> There is a way out of this, IMHO. This way is as follows:
> 
> I. We use the TXT RR for SPFID, because we need it now and not in 5
> years.
> 
> II. At the same time, we obsolete the RFCs describing the
> TXT RR and replace them with new text that says:
> 
>   i) The TXT RR is now reserved for SPFID and you can't put
>      anything you want in it anymore; anything that would go
>      into the TXT record needs to be cleared by MARID first.
> 
>   ii) We create a TXT1 RR that will fulfill the role
>       previously assigned to the TXT RR.
> 
> 
> Comments?

There is an alternative to a hostile take-over of the TXT record as I
mentioned.

Use a token such as "MARID-1" and follow this with a CRC-32c checksum
(good Hamming distance and code used in SCTP) of the entire record where
the checksum field is treated as zero.  Such as "MARID-1[FD034A45]..."
or perhaps "FD034A45_MARID-1...". See RFC3309 for an example of language
and code.  As it may be improbable a TXT record would start with the
token or checksum, but with the checksum it would take several lifetimes
of random text files before there should be a conflict.  The token would
also create a foundation for other future uses of the TXT record without
requiring a new record invented. This would be an alternative to the use
of the label to indicate revisions as would be a problem with SPF if its
label was replaced with an asterisk.

-Doug

> Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 11 Jun 2004 13:37:48 -0700

>>> Edward Lewis wrote:
>>> The TXT RR is used by ISC's dhcpd to record client
>>> identities in DNS. I haven't been able to track
>>> this back to any DHCP specification.

>> Michel Py wrote:
>> Is TXT RR the one for the domain itself or is there
>> one per host? If the later, I don't see any conflict.
>> Could you post an example?

> Markus Stumpf wrote:
> A receiving MTA cannot find out whether the RHS side
> of the @ in an email address is a host or a (sub-)domain.
> Just think
>    arneill-py.sacramento.ca.us
>    sacramento.ca.us
>    ca.us

You lost me. What is the relation with ISC's dhcpd?
Besides, why does it matter?

Michel.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Jun 2004 16:27:20 -0400

At 12:18 -0700 6/11/04, Michel Py wrote:
>>  Edward Lewis
>Is TXT RR the one for the domain itself or is there one per host? If the
>later, I don't see any conflict. Could you post an example?

This is from the dhcpd.leases man file:

# The ddns-text variable
#
# The ddns-text variable is used to record the value of the client's TXT
# identification record when the interim ddns update style has been used to
# update the DNS for a particular lease. 

  (I found a copy of it at 
http://linux.com.hk/PenguinWeb/manpage.jsp?section=5&name=dhcpd.leases)

This was from a message in an archive somewhere:
    (http://www.seattlewireless.net/pipermail/dev/2001-November/004968.html)

# A note about using TXT records and dhcpd servers (in this case
# ISC dhcpd 3.0):

# When  the DHCP server issues a client a new lease, it cre-
# ates a text string that is  an  MD5  hash  over  the  DHCP
# client's   identification   (see  draft-ietf-dnsext-dhcid-
# rr-??.txt for details).   The update adds an A record with
# the  name the server chose and a TXT record containing the
# hashed identifier string (hashid).   If this  update  suc-
# ceeds, the server is done.
#
#
# Sure enough, when running in ddns-update-style interim these records
# are added:
#
# nitrous                 TXT     "313fe40368e0c95848c336d33f7dd03bc7"
#                         A       10.100.3.252

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 11 Jun 2004 13:52:00 -0700

> identities in DNS. I haven't been able to track this
> back to any DHCP specification.

On a per-host (vs. per-domain) basis, it appears. I'm sorry, but I fail
to see your point here?

Michel.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Jun 2004 16:54:19 -0400

>On a per-host (vs. per-domain) basis, it appears. I'm sorry, but I fail

My point was that MARID can't rule out others from using the TXT.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 13 Jun 2004 19:00:10 -0700

> Whether there are too many people maintaining the registry information
> is separate concern from whether a registry is needed.  
> Moving Protocol
> Number Assignment to a function of the IETF rather an IANA is 
> a decision
> well beyond the scope of this group.  A registry is a vital function
> that must be employed to ensure the function of past and future
> protocols.

Designing protocols to minimize the load on IANA has always
been a concern in the ietf.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 10:11:35 -0400

At 14:24 -0700 6/11/04, Michel Py wrote:
>>  I know of other experimental uses of the TXT RR, for one,
>>  opportunistic encryption. There is an RFC in preparation to
>>  document that. So, MARID can't claim the TXT for it's own
>>  - others already use it.
>
>If they are using a well-known set of attributes, I don't see why. Part
>of the spec could be acknowledging the other attributes already in use.

The issue is that, as ISC does, anyone at anytime can take up using 
the TXT record for any purpose.  My point, which I've done a poor job 
of stating, is that if documents are relied upon for specification 
enforcement is also restricted to document space.  The IETF does not 
have a specification enforcement capability, adherence is voluntary. 
Through specification you can't guarantee no one else will squat on 
the TXT records.

Once again making a case for $MARID RR, if that is defined, then the 
protocol will restrict the use of the RR to the rules set forth for 
it.  The enforcement is then in the "on the wire protocol".  The 
enforcement is limited to the syntax and handling of the record in 
DNS, not the use, that is true - a non MARID app can use it, but the 
implementations would bound its use to one that is compatible with 
the definition of the $MARID RR.

>This is too strong; what I meant is that we should have a list of known
>attributes for the TXT record. Anyone wanting to use an attribute should
>register it. Would this make the TXT record palatable for PS if
>attributes were reserved for SPFID?

To do this, there's a need to establish a registry of TXT contents, 
most likely an IANA registry.  This would be a change one of the 
original (RFC 1035) types, so I'm sure it's undergo a thorough 
review.  I'm doubtful this would be doable, honestly, but one can 
always try.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: "MW Mike Weiner \(5028\)" <[email-masked]>
Date: Mon, 14 Jun 2004 16:10:46 -0400

> I'll use hotmail.com as an example. You can see the information at:
> http://www.lessspam.org/CallerIDPolicyWizard/?domain=hotmail.com
> [37 records snipped]
>
> The information occupies 537 bytes without tags.
> In binary, that would be 185 bytes: 5 binary octets * 37 records.

Hotmail's email policy in:

XML: 1040 bytes
SPF: 776 bytes (XML * 1.32)
byte-compiled:  240 bytes (XML * 4.33, SPF * 3.23)

Thanks whomever posted that URL, very handy.

Thank you
Michael Weiner

---

From: "Sauer, Damon" <[email-masked]>
Date: Mon, 14 Jun 2004 16:58:42 -0500

HEY! (tongue being inserted in cheek)

 Snippet from the WINZIP FAQ-

 By contrast, some types of data (such as text files and picture files
in the BMP format that the Microsoft Paint program uses) (insert)<SPF or
Caller-ID records> can often be compressed by 90% or more; some types
(such as program files) are often compressed by 50%.

 Let's just ZIP'm

;)

 Call it.
 aRRGzip
 StuffItXML
 ZIPSPIF
 JustZIPitMardid

Regards,
Damon Sauer

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hallam-Baker,
Phillip
Sent: Monday, June 14, 2004 5:31 PM
To: 'Luis Bruno'; [email-masked]
Subject: RE: Alternative to TXT or new RR was: Comments on
draft-ietf-marid-core-01 xml use

Why on earth are we even discussing this?

There is no difference whatsoever between a 1 byte packet and a 500 byte
packet. Either data fits in a packet or it does not. Only the number of
packets has significance when considering the impact on the network.

The hotmail policy is an outlier, there are perhaps ten ISPs of similar
scope. Nobody disputes the fact that most policies will easily fit in a
single packet - even without dns extensions.

Once read the hotmail policy will be cached for at least 24 hours. 

If AOL has a thousand servers accepting mail then worst case the
difference between binary and text amounts to 1 packet a day on their
external network and maybe a couple of thousand on their internal
network. Thats less than a single powerpoint attachement.

This is control information we are discussing here. This is a tiny
fraction of the message data volume.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Luis Bruno
> Sent: Monday, June 14, 2004 1:20 PM
> To: [email-masked]
> Subject: Re: Alternative to TXT or new RR was: Comments on 
> draft-ietf-marid-core-01 xml use
> 
> 
> 
> I'd like to hear comments on this, even flames or pointers to threads 
> I've missed. If this discussion is in any way out of order now, I 
> apologise; but do tell me to shut up in that case.
> 
> Hector Santos wrote:
> > I don't know why the TXT vs. RR is an issue.
> 
> From my point of view, creating a new RR type is the correct approach.

> The problem lies with Microsoft's existing design, which makes the 
> deployment of a new RR type harder.
> 
> It's actually a moot point; my personal peeve is the representation of

> the MARID information: you could place the binary information in a TXT

> record, as I see it.
> 
> I'd like to have the MARID information in a binary representation; the

> current design favors a textual representation, with a lot of 
> overhead.
> 
> The work on representing prefix lists has already been made
> by RFC3123.
> As I see it, it supports the SPF a, mx, ip4 and ip6 mechanisms. Each
> of the prefixes in that list can be negated.
> 
> I think this is a better way to publish the MARID
> information. If we use
> TXT for that or not, it seems irrelevant. As I understand it, we could
> use TXT to publish binary information: RFC1035 seems to allow 
> arbitrary
> information in TXT RDATA.
> 
> -- 
> Luis Bruno                                UTM: 29T 629481E 
> 4511776N 576m
> 

*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you received this in error, please contact the sender and delete the material from all computers. 113