Subject: [dnsext] Advice sought on DNS file format for new RRs

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Nov 2010 16:53:44 -0500

All,

I am currently writing up a major revision to CAA which I hope to have
available as an ID in the near future.

The main outstanding issue is the mapping between the wire format and the
DNS file representation.

The ideal file format would be something like the following:

   $ORIGIN example.com
   .       CAA policy 1.3.6.1.4.1.35405.666.1

   .       CAA path MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe
                    XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA==

   .       CAA critical path

At a high level the syntax is

CAA "policy" <OID> | "path" <BASE64> | critical <string> | "unknown"
<BASE64>

Now I can convert this to EBNF as well as the next person. But I am trying
to think round the question of maintaining DNS servers. I have a subfield
encoding here with three different variations on the data type. Is this
acceptable?

The other thing that I was thinking about was that maybe using EBNF might be
too big a hammer here. LR(1) grammars were developed as a model for natural
language. They are not a good basis for programming language syntax and a
worse basis for data and protocol representations. A meta-encoding that
enforces some degree of regularity is generally superior. Has anyone else
been thinking along those lines?

I know that I can crib what I need from other RFCs, but there are good cribs
and bad ones. Which ones would people recommend?

I want to get this draft right first time if possible because it is cutting
across two separate standards area. The subject matter is deeply connected
to issues in the practices space and I am really sure that the IETF does not
want to get into that type of discussion. So I want to design a proposal
that allows the IETF to hand over a mechanism which can then be elaborated
endlessly by the lawyers if needed. If this is to work we need to allow IETF
and CABForum to decouple their efforts.

The other incentive for getting this right first time is that CAA has a very
powerful deployment incentive for the CAs and deployment only requires the
co-operation of about 20 parties. While there are 200 organizations that
represent themselves as CAs, many are white label to another CA. And even
though there are multiple roots in the browsers, most of the major CAs have
collected multiple roots. The bottom line here is that this is a feature
that can be presented as an immediate and important win that illustrates the
type of benefits that DNSSEC can realize for the Internet.

-- 
Website: http://hallambaker.com/

---

From: bert hubert <[email-masked]>
Date: Thu, 18 Nov 2010 23:35:36 +0100

> The main outstanding issue is the mapping between the wire format and the

Hi Phillip,

You are certainly doing something new here - no other RR I know of can
appear in different syntaxes. This alone will make 'CAA' special. All
RRtypes I know about have a rigid specification, and put their flexibility
in a label or text field (which has issues of its own!).

95% of all RRtypes have a remarkable symmetry between their wire
representation and their 'zone file format', to the extent that PowerDNS has
templated RRtype code which, depending on the operation required either
emits or consumes, wire format or 'representation format'.

For the SOA record, this looks like:
boilerplate_conv(SOA, ns_t_soa,
                 conv.xfrLabel(d_mname, true);  // true means compression
may be used
                 conv.xfrLabel(d_rname, true);
                 conv.xfr32BitInt(d_st.serial);
                 conv.xfr32BitInt(d_st.refresh);
                 conv.xfr32BitInt(d_st.retry);
                 conv.xfr32BitInt(d_st.expire);
                 conv.xfr32BitInt(d_st.minimum);
                 );
This is the *full* definition of how the SOA rrtype works in PowerDNS.
'conv' either reads or writes, either to/from a packet or to/from zone file
format.

Given the fact that this works so well for so many record types, it feels
like it is a Good Thing for records to display this symmetry.

> encoding here with three different variations on the data type. Is this

It would of course be acceptable, and PowerDNS will surely implement it. We
do NSEC3 too, which also required a lot of infrastructure (for the
bitfields).

However, if you care about widespread acceptance of your record, you may
find it advantageous to not be the first RRtype that can appear in three
wholly different forms (both on the wire and in zone representation).

I realise that this might turn CAA into 'another TXT record with formatting
rules', of course. But it also might pay not to be too special.

    Bert

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Nov 2010 07:41:28 -0500

> encoding here with three different variations on the data type. Is this

I'm trying to understand the motivation.  Why not use three different
RRTYPEs?

I haven't thought about it very hard, but my first reaction is that
this RRTYPE is not going to be eligible for assignment by expert
review.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Nov 2010 12:51:24 -0500

The semantics of the properties are inter-related.

I am attempting to define a mechanism that works with a bare minimum of
properties, but PKI is highly complex and that may not prove possible.

A layered architecture requires that the upper layers of abstraction be able
to express necessary data structures without the need for constant recourse
to extend foundation layers.

The community that is going to use the published information is about 50,
highly technical organizations who are only going to make use of the
information to effect additional validation checks within a precisely
calibrated legal process. The proposal does not directly affect the state
transitions or bits on the wire of DNS, DNSSEC or any Internet protocol.

If this type of work cannot be performed under the expert review approach,
then I don't think anything else can.

On Fri, Nov 19, 2010 at 7:41 AM, Andrew Sullivan <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Nov 2010 13:11:45 -0500

> The semantics of the properties are inter-related.

But not the same.  It seems to me that you have three different data
types here, and that maps rather nicely to three different RRTYPEs.
What's the problem with using three?  I don't get it.

> The proposal does not directly affect the state

I'm not so sure, but I'd have to see the use case for this.  In
particular, if the RDATA for this stuff changes between queries, then
you're going to have awfully funny effects with caching (and
especially funny interactions with DNSSEC).
 
> then I don't think anything else can.

We know of some things that have proceeded under expert review, so
your consequent is empirically false there.  The sticker is going to
be RFC 5395 (or successor) section 3.1.2 number 1.  The implementation
and evaluation of this RRTYPE with the variations seems to me to be
tricky to understand.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Nov 2010 13:44:28 -0500

Well given the feedback so far, I am thinking that for this particular
purpose it is looking like it is going to be better to have an RR that is
essentially a different RR code for a TXT field and use a sub-encoding.

The reason I was looking at the bit field format was that that had appeared
to be the sentiment at the start of DKIM.

The only downside I can see to that approach is that there will be a slight
loss of coding efficiency due to the use of Base64 encoding rather than
binary. But that is not a major concern for me as I don't expect ODIs to
ever be more than 50 bytes so the overhead is not a worry.

So instead of:

   $ORIGIN example.com

   .       CAA critical path

It would be:

$ORIGIN example.com
.       CAA "policy=1.3.6.1.4.1.35405.666.1"
.       CAA "path@=MDIGA1UEJQYJYIZIAWUDBAIBBCAXz"
            "JgPaoT7FeXaPzKv6mI2D0yilif+7WhzmhM"
            "GLe/oBA=="

There would have to be appropriate statements on how to cope with space
characters.

---

From: Michael Graff <[email-masked]>
Date: Fri, 19 Nov 2010 14:45:40 -0600

On 11/19/10 12:44 PM, Phillip Hallam-Baker wrote:
> The only downside I can see to that approach is that there will be a
> slight loss of coding efficiency due to the use of Base64 encoding
> rather than binary. But that is not a major concern for me as I don't
> expect ODIs to ever be more than 50 bytes so the overhead is not a worry.

Don't confuse the textual representation with what may be on the wire.

An example of this is the DS record, where the hash is displayed in hex
but the wire format is binary.  This means your first example is workable.

Ordering is not guaranteed, so I assume this would work with or without
a specific ordering of records.

I may be confused here as well but if there is a requirement for more
than one of these at a specific name, then either put all the data on
the same single record (making it complete) or add an ID number to line
up the policy with a specific path.

What I'm proposing is something like:

  . CAA (policy 1.3.6.1.4.1.35405.666.1
	 path MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe
	      XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA==
	 critical path)

--Michael

> So instead of:
> 
>    $ORIGIN example.com <http://example.com/>
> $ORIGIN example.com <http://example.com/>

Note that there is a big difference in a TXT record with those quotes
and without.

--Michael

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Nov 2010 16:50:29 -0500

Thanks,

The records are independent of each other, Each record specifies one
Authorization Entry and the set of RRs make up an Authorization Set similar
to an ACL but a set not a list.

We did have a concern raised for the possibility that a RR set would become
fragmented and a relying party might only get some of the records. In other
words there are 5 CAA records in a domain and the resolver only caches 3.
Would this really be an issue? I would have thought not since signatures are
over the full RR set.

What I am trying to do at this stage is to work out what the range of
options is here. I see the following choices:

1) Binary encoding with potentially different data types depending on the
sub tag.

CAA   policy <oid> | path <base64> | critical <string>

2) Binary encoding with a uniform data structure like in the CERT tag:

CAA <tag> <critical flag> <base64>

3) TXT style encoding in the manner of DKIM

CAA <tag>  <TXT data>

I think that there have been enough objections to 1 to exclude it. I am
willing to go with either 2 or 3 if there is a really strong opinion one way
or the other but would otherwise tend to go for 3 as that allows for a more
flexibility.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Nov 2010 17:34:09 -0500

On 19/11/2010 4:50 PM, Phillip Hallam-Baker wrote:
> Authorization Entry and the set of RRs make up an Authorization Set
> similar to an ACL but a set not a list.
>
> We did have a concern raised for the possibility that a RR set would
> become fragmented and a relying party might only get some of the
> records. In other words there are 5 CAA records in a domain and the
> resolver only caches 3. Would this really be an issue? I would have
> thought not since signatures are over the full RR set.
>

Impossible, DNS caches store either all or none.

> 1) Binary encoding with potentially different data types depending on
> the sub tag.
>

You are still confusing DNS wire format and DNS presentation format.

Wire format is always binary i.e. all base64 blocks are translated to
8bit binary, Text blocks are translated to a special text format, etc.

Work out what you want in the textual format of your record(s), and how 
the record(s) are used.
Then ask someone to help you convert that to DNS wire format.

> willing to go with either 2 or 3 if there is a really strong opinion one
> way or the other but would otherwise tend to go for 3 as that allows for
> a more flexibility.
>

Format 1 is fine if the records are dependent on each other (i.e. 
atomic), If the records are independent subsets you should use different 
types. Every time DNS has started using sup-typing we have run into 
problems.

	Olafur

>
> On Fri, Nov 19, 2010 at 3:45 PM, Michael Graff <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      >    $ORIGIN example.com <http://example.com> <http://example.com/>
>      > $ORIGIN example.com <http://example.com> <http://example.com/>
>     [email-masked] <mailto:[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Nov 2010 18:56:12 -0500

> Impossible, DNS caches store either all or none.

That was my belief, but I wanted to check.

> You are still confusing DNS wire format and DNS presentation format.

No I understand the difference.

The constraint here is that if I have a complex binary format, then DNS
servers are going to have to be able to parse a correspondingly complex
syntax to encode the data. That may not be desirable.

> 8bit binary, Text blocks are translated to a special text format, etc.

That is not the case in DKIM.

In DKIM the key blobs are encoded in base64 and that is how the data is
stored in the DNS TXT record.

> Format 1 is fine if the records are dependent on each other (i.e. atomic),
> If the records are independent subsets you should use different types. Every
> time DNS has started using sup-typing we have run into problems.
>

The TXT approach appears to work in DKIM because the records in question do
not affect the operation of DNS itself.

---

From: Michael Graff <[email-masked]>
Date: Sat, 20 Nov 2010 04:54:29 -0600

> syntax to encode the data. That may not be desirable.

I really hate to suggest this, but could you go back to basics?  What is
the data item you are attempting to transmit?  I admit I stepped into
this conversation in the middle, so if there are references I should be
reading kindly point me at TFM.

If a single block of data is the goal -- that is, the concept of "a key"
or "a certificate" or something, where you really don't want to split
the individual components of those items up, why split them at all?

With a custom type, you have to choose two things:  textual
representation and wire format. I would take the idea of using a TXT
encoding right off the table from the start so you are free to choose
more efficient wire format than a TXT-like encoder would typically use.

> stored in the DNS TXT record.

If they had used a custom type, that would not have happened.

TXT is the record they chose, and of course it's a literal translation
from what is in the zone file to what is on the wire.

> The TXT approach appears to work in DKIM because the records in question
> do not affect the operation of DNS itself. 

It appears to work, but each user who overloads TXT has to deal with all
the other crap that may be there, now or in the future.

--Michael

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 20 Nov 2010 14:06:46 +0100

> 	      XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA==

+1

I think, given the three pieces always stay together, that this would be the best solution.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Nov 2010 16:04:50 +0000

On Fri, 19 Nov 2010, Phillip Hallam-Baker wrote:
> calibrated legal process.

I expect that whether you like it or not, people other than CAs are going
to check the assertions in these records, and they are going to implement
these checks in widely-deployed software.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Nov 2010 11:42:40 -0500

I think that it is right that people will perform such checking, but to do
so on the basis of current CA issuing authorizations will lead to error.

When example.com changes from VeriSign to Comodo they would expect to change
their CAA record to revoke VeriSign's issue authorization immediately. They
would not want this to invalidate existing certificates.

Looking at the mechanics of Certificate management within enterprises, I
think it is going to be necessary for most sites to get their issue of certs
under control as a pre-condition for implementing client enforceable policy.

We had this experience with DKIM. It did not take as much time to write the
spec as people imagine. What really took the time was the fact that
deployment at the sites that mattered required a vast amount of effort to
catalog what was already deployed. From a technical standpoint, DKIM is very
easy to deploy, from an administrative standpoint it is really easy to
administer once it is installed. But going from not using DKIM to using DKIM
can require major changes to management processes and in some cases
centralization of concerns that had previously not been tracked at all.

That is why I think that we need to separate this part of the problem from
the rest and why I think we need a separate DNS RR.