Subject: [ietf-dkim] New Issue: New resource record type

From: Scott Kitterman <[email-masked]>
Date: Sat, 14 Oct 2006 11:14:39 -0400

This draft mentions the posibility of requiring a new resource record type.  
It isn't clear from the draft if the mention is in reference to the idea of 
using a new RR type in parallel with TXT for some period or if the idea is 
possibly deployment exclusively in the new RR type.

If it's the latter, I think that this would be an extraordinarily bad idea.  
In my opinion, if this protocol is going to require a new RR type to go 
forward, it will never get deployed.  

Recommend a new requirement that the protocol MUST NOT depend solely on a new 
DNS RR type just so there won't be any confusion on this.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Oct 2006 22:13:04 +0200

> DNS RR type just so there won't be any confusion on this.

I would suggest that whatever approach SSP uses be consistent with what
has been done with the base protocol.

Eliot

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 15 Oct 2006 16:24:25 -0400

On Sunday 15 October 2006 16:13, Eliot Lear wrote:
> Scott Kitterman wrote:
> > This draft mentions the posibility of requiring a new resource record
> > type. It isn't clear from the draft if the mention is in reference to the
> > idea of using a new RR type in parallel with TXT for some period or if
> > the idea is possibly deployment exclusively in the new RR type.
> >
> > If it's the latter, I think that this would be an extraordinarily bad
> > idea. In my opinion, if this protocol is going to require a new RR type
> > to go forward, it will never get deployed.
> >
> > Recommend a new requirement that the protocol MUST NOT depend solely on a
> > new DNS RR type just so there won't be any confusion on this.
>
+1.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Sun, 15 Oct 2006 19:31:26 -0700

> has been done with the base protocol.
The considerations aren't quite the same.  In the case of the base
protocol, the signature can tell (via the q= tag value) what method to
use, including which record type, to retrieve the key.

In the case of SSP, there's nothing to tell the verifier how to retrieve
the SSP record.  If there is more than one way to publish SSP, then the
verifier has to try each one until they find a record or run out of
methods.  This makes it a much bigger burden, both on the verifier and
the infrastructure, to have more than one lookup method.  The question
then becomes whether that method should be a TXT record (presumably with
some prefix) or some other RR (not necessarily with a prefix).

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 15 Oct 2006 22:36:38 -0400

On Sunday 15 October 2006 22:31, Jim Fenton wrote:
> >> type. It isn't clear from the draft if the mention is in reference to
> >> the idea of using a new RR type in parallel with TXT for some period or
> >> if the idea is possibly deployment exclusively in the new RR type.
> >>
> >> Recommend a new requirement that the protocol MUST NOT depend solely on
> >> a new DNS RR type just so there won't be any confusion on this.
> >
OK.  That makes sense.  

It takes a long time to get deployment on a new RR.  IMO, going to a new RR is 
closely equivalent to cancelling SSP.  By the time a new RR is widely 
useable, things will have moved on.

My vote is use TXT with "_".  If a new RR type is going to be used, we may as 
well quit and go home now.

Scott K

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Oct 2006 07:58:21 +0200

Jim,

Fair points.  One possibility, by the way, is that we use the SAME
prefix but simply with new attributes.  That way you get the whole thing
in one shot.

Eliot

---

From: Jim Fenton <[email-masked]>
Date: Mon, 16 Oct 2006 04:18:17 -0700

> prefix but simply with new attributes.  That way you get the whole thing
I'm not sure what you have in mind here.  One of the benefits of using a
new RR type is that it may allow us to get away from the use of a prefix
entirely, which in turn may shorten the search process by detecting
nonexistent domains more easily.  I'm not certain how well this
mechanism works, but you can see what I'm talking about in
draft-allman-dkim-ssp-02.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Mon, 16 Oct 2006 05:51:33 -0700

From a requirements standpoint, I'd just assume we not go into this level
of detail. The high level bits of deterministic number of lookups and other
things seem fairly uncontroversial, but the engineering/deployment 
considerations
of the RR problem require a lot more detail and/or experimental evidence 
to be
examined. I don't think that a requirements document is the right venue 
to run
that debate.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Oct 2006 09:17:51 -0400

Any design the requires a new RR type is not deployable anytime soon.

As I said before, if a new RR type is the path we are going down, then we may 
as well quit and go home now.

To put it in requirements language, I think it is a requirement that SSP be 
deployable with the same DNS infrastructure that supports base (this is 
independent of where in the namespace the record goes - as long as it's 
somewhere in TXT we can design the details later).

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Oct 2006 15:21:22 +0100

Scott,

The last time we met we had this same issue wrt key records
with the result shown below (excerpted from [1]).

I don't personally know if SSP records are in any way different
from key records, but it does seem to be the case that there is
some general opposition to (re-)using TXT.

And we won't really be able to have the discussion with the DNS
folks (which will be necessary) until we have a concrete protocol
to discuss with 'em.

So I'd suggest that we leave this issue [2] open for now, and come
back to the topic when we've got a concrete protocol on which we
can base the discussion.

Does that sound ok for now?

Stephen.

[1] http://tools.ietf.org/wg/dkim/minutes?item=minutes66.html
[2] https://rt.psg.com/Ticket/Display.html?id=1382

"Bellovin on the DNS directorate issue: question about TXT vs other RR 
for _domainkey. Spent 45 minutes at DNS directorate. Steve not chair, 
but consensus. Quoting:

"The DNS directorate is unhappy with using TXT records this way. Some of 
the reasoning is spelled out in draft-iab-dns-choices-03.txt. At the 
least, a registry of _ names is needed, with provision for subtyping, 
but subtyping RRs has long been known to be bad . In general, TXT 
overloading can be likened to using HTTP as the universal transport 
protocol; see RFC 3205 for why that's a bad idea.

A more specific problem for this situation is the issue of wildcards. 
Briefly, you can't have a wildcard _domainkeys record; given that email 
is the major place where wildcards are used, this is a serious issue."

DNSSEC signing records at least may be found below _domainkeys and other 
RRs deliberately or by accident.

Olafur: If doc says "do not use wildcards" that'd be good. Proposes an 
experiment to acquire a new type if the WG want to try that (a fast 
process apparently).

Doug - eai may expand record as well as longer keys. Suggests that 
alternative to TXT might be good for that.

Crocker: Question to Bellovin: Would DNS directorate assert a DISCUSS. 
Bellovin: No-one said DISCUSS, but unhappiness. On the plus side, its a 
special record and we don't have to contend with other TXT records.

Way forward: WG will only specify a TXT for keys for now."

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Oct 2006 10:32:48 -0400

> Does that sound ok for now?
If that's the best I can get, OK.

I was serious when I said that if we are going to have to cut and deploy a new 
RR type for SSP we may as well stop now.  By the time that happens the 
internet ecosphere will have routed around the protocol.

>From my perspective a new RR type is a showstopper problem.  I'm not sure what 
a more concrete proposal for a new RR type might do to change that.  

However you want to handle it is fine though,

Scott K

---

From: wayne <[email-masked]>
Date: Mon, 16 Oct 2006 11:31:27 -0500

> some general opposition to (re-)using TXT.

This very discussion came up on the namedroppers list not too long
ago.

There are many DNS folks that seem to think that because they have
created RFCs that allow for new record types to be created "easily",
and because some name server software has been updated to support
this, and because there have been a few new RR types created for
systems that have almost zero deployment, that there really isn't much
problem with making everyone use a new RR type.  Basically, because
the low-level stuff is there, the problem has been solved.

Scott, on the other hand, has long dealt with a very high level
problem of keeping track of which DNS hosters actually support even the
long established TXT record type.  Most likely due to SPF deployment,
the number of hosters that support TXT records have increased
significantly, but there are still lots that don't.  Support for other
DNS records, such as NS or SRV records is almost non-existent.

So, if you run your own DNS and use non-braindead up-to-date
resolvers, supporting new RR types is easy.  If you are a smaller
domain that uses something like godaddy to host your DNS and use
Microsoft products, you are in for a very rough time.

I guess it largely depends on who the target users of DKIM is.  If it
is mostly large companies that send lots of email, a new RR type isn't
going to be too much of a problem.  If the target is for everyone, a
new RR type is a showstopper.

-wayne

---

From: wayne <[email-masked]>
Date: Mon, 16 Oct 2006 11:47:26 -0500

> some general opposition to (re-)using TXT.

Oh, one more point.

For SPF, we were able to obtain acceptance of TXT usage very
grudgingly by giving fairly strong evidence that SPF records are
almost always short and in cases where they weren't short, you can
publish SPF records of "v=spf1 redirect=_spf.%{d}" to put the long SPF
record somewhere else.

For DK/DKIM, the key records are long, but the SSP records ususally
aren't.

We *may* be able to get acceptance of the reuse of TXT for SSP
records.

-wayne

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Oct 2006 16:22:17 -0400

I'd be satisfied if the requirements draft were to say:

The protocol MUST NOT require use of a new DNS RR type.  The protocol MAY 
allow for optional use of a new RR type.

I understand others may not like that and so I guess we leave it open for now.

Scott K

On Tuesday 17 October 2006 16:11, Michael Thomas wrote:
>  From the requirements standpoint, I'd just assume that we avoid this
> topic. There are some pretty deep engineering and political tradeoffs and
> absent actual proposals, it's really hard to imagine that a requirements
> draft would
> finesse this topic correctly.
>
>        Mike
>
> Scott Kitterman wrote:
> >I was serious when I said that if we are going to have to cut and deploy a
> > new RR type for SSP we may as well stop now.  By the time that happens
> > the internet ecosphere will have routed around the protocol.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Oct 2006 21:32:29 +0100

> allow for optional use of a new RR type.

But wouldn't that decide the issue in that the consequence of the above
would be that the protocol MUST mandate use of TXT (or some other
existing) records? Maybe I'm missing something though.

If so, I think that silence on this in the requirements draft is best,
but keeping the issue open in the tracker so we do have the debate later
on.

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Oct 2006 13:11:42 -0700

From the requirements standpoint, I'd just assume that we avoid this topic.
There are some pretty deep engineering and political tradeoffs and absent
actual proposals, it's really hard to imagine that a requirements draft 
would
finesse this topic correctly.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Oct 2006 16:48:02 -0400

On Tuesday 17 October 2006 16:43, Michael Thomas wrote:
> First off, I apologize for an almost word-for-word repeating of myself in a
> previous post -- it's fairly obvious that my mail reading habit is fifo
> based :)
>
> My feeling is that deferring this argument until the design phase won't
> likely hurt, while getting it wrong in requirements phase certainly
> will. If we
> can just be patient until then, I think there will be plenty of opportunity
> to work this issue through. I personally agree that this is an important
> issue, but I'm also very interested in real experience which will support
> the various conjectures about how the discovery mechanism should work.

OK.  I'll sit down now.  Let's just keep the issue open for now and move on.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Tue, 17 Oct 2006 13:43:00 -0700

Mike

Scott Kitterman wrote:

>>>>From my perspective a new RR type is a showstopper problem.  I'm not sure
>>>      
>>>
>>>>what
>>>>        
>>>>

---

From: "david repking" <[email-masked]>
Date: Tue, 17 Oct 2006 23:05:04 +0200

> allow for optional use of a new RR type.

And then nobody will use the new (optional) RR type, if there's an alternative.

IMHO, new types of data MUST require new types of RR

If we would re-use RR types, why don't you wan't arbitrary numeric
values on A records (like telephone numers, extensions, system IDs,
etc) ???
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Oct 2006 17:16:27 -0400

> values on A records (like telephone numers, extensions, system IDs,

Reuse of TXT in an underscored subdomain is benign. 

It all depends on if you actually want SSP to be deployed or not.  If we have 
to wait for a new RR type to be broadly useable, then SSP goes nowhere out of 
the starting gate.

An optional new RR type would be there to provide a path away from TXT if one 
should be required.  Get started now and deprecate reuse of TXT in the far 
future if there proves to be operational value in doing so.

I guess we'll get to argue about this again later.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Oct 2006 14:42:10 -0700

> Reuse of TXT in an underscored subdomain is benign.

Agreed.  Also there would not be an advantage using a new RR type  
when there is an association made using query labels as might be done  
with designated domains, clients, or local-part policies.

For example:
  <base32(sha1(some-element))>._some-policy.<some-domain>.

The use of policy discovery implies a desire to block non-compliant  
messages, rather than a desire to annotate messages that are  
compliant.  The latter mode provides greater security without  
requiring the search for policy records within parent domains.

-Doug