Subject: RE: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Mar 2006 08:42:25 -0800

> From: Tony Hansen [mailto:[email-masked]] 

> So it sounds like their database *will* support the 
> additional RR values, it's just that they don't make it easy 
> to use them.

Not to a level that is remotely meaningful. If you cannot save the
information out of the database or query it using the standard tools you
have created an administration nightmare. When a system reboots the
configuration will change in unexpected ways. 

> Until they get their standard interface fixed, it sounds like 
> Microsoft (or a 3rd party) could provide an alternative 
> interface that additionally stored the RRs in a separate 
> database that would survive the reboot, and included a 
> service that ran at boot time that would reload those 
> additional RRs into the real database.

The problem is not just Microsoft, the problem is that this is typical of
the level of support in deployed infrastructure. The claimed level of
support for new RRs was 85%. The realistic level of support was measured at
somewhat less than 50%.

If Olafur had the numbers to back up his case he would not have taken the
approach he did. If he had the facts on his side he would have brought a
slide. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Mar 2006 10:46:40 -0800

> From: Jim Fenton [mailto:[email-masked]] 

> There's a different situation for key records and
> policy/practice/(petunia?) records.  The choice of whether to 
> use a new RR or a TXT key record should be retrieved is 
> something that can be represented in the signature (the query 
> type, q=, tag has been suggested which makes sense).

Absolutely, I have no problem with the idea of using binary key records for
future key formats.

My basic strategy here is as follows

1) Deploy DKIM based on technology that is 110% compatible with legacy DNS
infrastructure.

1a) Deploy a bunch of other technology on the back of DKIM such as secure
Letterhead that creates a compelling and highly visible use case for DKIM.

1b) Begin experimental pilot deployments of DNSSEC to begin build out of
necessary support infrastructure

2) Deploy DNSSEC using the need to secure DKIM records as the critical pain
point to be urgently addressed.

2a) Since DNSSEC requires deployment of infrastrufture that is capable of
handling new RRs the RR deployment issue is at this point moot

2b) Deployment of DNSSEC also effectively increases the maximum size of DNS
packets, even the3 Windows DNS servers have a default greater than 1K

2c) The value of moving from RSA 1024 to RSA 2048 or DSA 2048 is not as
great as the value of moving from RSA 1024 without DNS SEC to RSA 1024 with
DNSSEC. Ergo making DNSSEC a prior deployment requirement for deployment of
longer key sizes is not a concern to me.

3) Deploy options for additional cryptographic algorithms, possibly making
use of binary RRs.

In other words there is a deployment strategy for both phases. The first
phase creates the pain point that motivates the second deployment phase
which in turn enables the third deployment phase.

Any transition to use of binary policy records is in my view unnecessary and
likely to create more problems than it solves. It would be necessary to
publish the records in both formats during the transition period. The DNS
infrastructure makes extensive use of caching, Inconsistency and race
conditions are certain to result from such a switch.

The only drawback identified with prefixed TXT records is the fact that it
is not possible to specify a wildcard of the form _prefix.*.domain. As I
have demonstrated on several occasions this drawback is eliminated through
the use of a PTR record as an indirection wildcard.

The TXT architecture has the advantage of separating the definition of
policy semantics from the internal workings of the policy distribution
platform. The DNS area has repeatedly expressed its desire to avoid
contaminating the core DNS with individual protocol semantics. The
applications area shows a clear need for such semantics to be defined. The
TXT architecture achieves the necessary separation of concerns.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Mar 2006 12:46:57 -0800

Mark,

	Why would I bother to read the policy record at all if the message
is signed with a signature that meets my acceptance criteria?

	I am only going to care about the policy record if the message is
unsigned or the signature fails to validate. Only then am I going to read
the policy record and it is only going to be significant to me if it tells
me to expect a message that is different to the one I received, i.e. that it
should have a sig with a particular profile. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Thursday, March 30, 2006 3:24 PM
> To: [email-masked]
> Subject: Re: SSP RR vs TXT [was Re: [ietf-dkim] SSP and o= values]
> 
> On Thu, Mar 30, 2006 at 10:09:24AM -0800, Jim Fenton allegedly wrote:
> 
> > policy/practice/(petunia?) records.  The choice of whether to use a 
> > new RR or a TXT key record should be retrieved is something 
> that can 
> > be represented in the signature (the query type, q=, tag has been 
> > suggested which makes sense).
> 
> As a practical matter, I don't see how this can actually work 
> to eliminate the DKK then TXT sequence because you don't know 
> the capabilities of the verifiers. Can they fetch DKK? No one knows.
> 
> During transition, signers will be significantly at risk of 
> not being verifiable if they just use q=dkk. Hence, most, if 
> not all signers will likely use q=dkk,txt (or whatever the 
> syntax is) to explicity tell the verifiers to try both, which 
> in turn means the signer has to maintain both.
> 
> The net result is that signers will all be saying try DKK and 
> fall back to TXT.
> 
> The only true advantage to being explicit with q= is that it 
> lets TXT-only sites optimize away the failed DKK lookup, but 
> it adds no value to signers supporting DKK.
> 
> 
> Mark.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 30 Mar 2006 14:15:55 -0800

Let us consider the problem of interoperation in stages:

The record is published in DNS server A which is connected to the Internet
by some local network infrastructure travels over the backbone, travels over
some more network infrastructure which may or may not include a DNS server
to the application making the query B.

What is important for compatibility reasons here is the combination of the
infrastructure and A or B respectively. Lets call the combination of A and
the infrastructure connecting it to the open backbone A' and the same for
B'.

If you are operating A then you should know whether A' is or is not a viable
transit channel for new RRs. Either it is going to work or it is not going
to work. If it is not going to work then you SHOULD NOT sign using q=newRR
until you have fixed this.

If you are operating B you should likewise know the capability of your
infrastructure. Attempts to resolve the newRR over B' will either always
succeed or always fail. 

We clearly need to have at least one algorithm that A can use even if their
local infrastructure does not support newRR. RSA1024+SHA256 appears to be
that algorithm.  We are quite likely to want to upgrade to other algorithms,
including RSA2048 and DSA2048. It is quite hard to see how we can get the
base64 encoded key, necessary attribute info, packaging and a DNSSEC
signature into a 512 byte message.

Here we get to a bizare part of deployment strategy. It is much easier to
deploy a security patch than a new security infrastructure. If deployment of
a new DNS server was a precondition to deployment of DKIM it would be DOA.
Once that DKIM service is installed though it becomes much easier to put
deployment of DNSSEC and the necessary upgrades to the infrastructure on the
list.

Key records are different from policy records in another important wat.
Unless it is prefixed the policy record MUST be in the core DNS server. Key
records are much easier to move off to a different service - by design.

I can quite imagine a situation where a CA providing comprehensive support
for DKIM would provide a service providing full feature support in one
package. I.E. host the DNS key records DNSSEC signatures thereof. In that
case it may even be possible to publish under multiple schemes (TXT and
newRR).

> Sent: Thursday, March 30, 2006 4:40 PM
> > 3.  verifiers that see q=<newRR> SHOULD query for that RR but MAY 
> > query for the TXT.
> > 
> > Single query, no matter what the situation.  No failures, 
> so no fallbacks.
> 
> Right. I conflated the need to support both types by the 
> sender with the need for a fallback query. So the fallback is 
> eliminated, but the sender may need to support both record 
> types forever.
> 
> The next question is whether this is a good strategy for RR 
> adoption or not and whether that should be considered.
> 
> 
> Mark.