Subject: Re: [keyassure] Key linkage draft, -00 edition

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Aug 2010 09:13:43 -0400

DKIM uses a TXT record because it was designed to work with existing
DNS and inparticular with servers that do not support additional
records. For example the Windows DNS server where Microsoft presented
code from the server to dismiss claims to the effect that it could be
used to publish additional records.

There are multiple design choices here:

1) Use TXT vs a new RR.

In this case the use of a new RR is relatively unproblematic since we
are assuming or at least encouraging the use of DNSSEC to sign the
records and thus there is no need to support DNS servers that do not
support additional RRs.

Conclusion: New RR

2) Use of an ASCII format field with internal syntax versus DNS binary field

This is what I took Stephen to be suggesting. And I prefer this
approach since it means that we adopt a tag-value structure and
automatically gain the extensibility I believe is going to be
necessary to make this protocol work.

Those of us who have experience of DKIM know that this is going to
prove rather more complex than the fixed binary draft on the table. I
do not see a great value in trying to make the binary draft into an
extensible scheme, the savings in bits are rather trivial, the
complexity introduced into the code is considerable.

In particular, I really don't want to go for a scheme that introduces
yet another registry of code points to be registered for the tags in
the tag value pairs. Different protocols are going to have different
security requirements and some will require additional tags. In the
world of Web Services, protocol designs are going to proliferate
rapidly and creating choke points for code point assignment is going
to discourage use of the scheme.

Conclusion: Use ASCII

3) Use of existing DKIM tags versus new tags

Reuse of the DKIM tags is a tricky question, it would be a good idea
if we are going to use the same architecture and the tags can have the
same semantics. Since we require different semantics I would prefer to
use different tags since the same person is likely to be configuring
both sets of tags and confusion is going to be rather likely.

Here another design choice of DKIM may be significant, the choice of
single letter tags in a UNIX style command line format. I dislike this
approach as it means I have to always consult a manual to look at what
the tags mean.

Conclusion: Use different tags to those employed in DKIM

4) Use prefix records or per-protocol records.

As we have seen, the fact that a key is acceptable for one protocol
does not mean that it is acceptable for another. Consider a site that
has a payment invoicing application and a Web site on the same domain
name. We don't want to have the cross site scripting vulnerabilities
in the Web site enabling an attacker to start authorizing invoices for
payment (that would be bad).

Here the question is whether we are only going to support a limited
number of protocols or design something that can be used as generic
infrastructure for Web Services.

We already have several thousand Web Services in use. Protocols that
involve humans tend to be rather limited in number. Anyone can write
their own mail protocol, but people only want to use one mail
application. So once SMTP appeared there was no room for new
protocols. That constraint does not apply to Web services, payment
gateways typically support a different protocol per payment processor
(allegedly there is a standard - not).

If we accept that there will be tens of thousands of Web Service
protocols, burning a RR per protocol is clearly unacceptable.

The objection made in the IAB options draft had to do with wildcards
and prefixing TXT as a substitute for a new RR. These do not apply
here since we are using a new RR and the wildcard issue is fixable if
relevant.

Conclusion: Use SRV style prefixes

Putting these together, I see the following as the simplest example:

_http._tcp.www.example.com OPTIONS "ssl=offered
certh=sha256:0b92c7808b91f7dc1cadaf8f9afe4d9834372adcc3e18f1d
4df6704768eea870"

If we have more than one cert:

_smtp._tcp.example.com OPTIONS "ssl=offered"

cert1._smtp._tcp.example.com OPTIONS
"certh=(3e8e64500a2ac1ea38203ef943c5e3188e1e537076b7846219996aa225e76c0e)"
cert2._smtp._tcp.example.com OPTIONS
"certh=(a7fc2dcd765f94801bc06edd6420aad6cfe7fbfaa38113a5
e860a00607343b0d)"

Where the certs have the corresponding labels cert1 and cert2 embedded
as part of the issue process.

On Thu, Aug 19, 2010 at 10:59 AM, Paul Hoffman <[email-masked]> wrote:
>>Quick question: did you consider DKIM key records for this?
>>(With a new "s=" value in the TXT RR.)
>>
>>If so, why don't they rate a mention? If not, maybe worth a
>>look?
>
> First off, the idea of TXT RRs without _label prefixes has been mostly deprecated in the IETF. Second, the idea of saying "this isn't DKIM, it's this new thing" by changing "s=" is begging for trouble. There are enough tricky semantics in the DKIM spec (not as many as in PKIX, but it sometimes feels that way) that reusing it would likely prevent us from having the freedom we want.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 22 Aug 2010 22:26:48 +0200

> There are multiple design choices here:

The choices where actually CERT vs TXT vs new RR.

> records and thus there is no need to support DNS servers that do not

There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Aug 2010 16:39:18 -0400

> The choices where actually CERT vs TXT vs new RR.

CERT seems sub-optimal to me since in most connection oriented
protocols the cert is passed in band. That is the case for both SSL
and SSH and for WS-*. The only protocols I know of where the certs
need to be pulled out of band are email messaging and the world has
already rejected that approach for S/MIME.

Using CERT RRs means that the size of the messages will inevitably
spill over the 512 byte DNS boundary and will be close to the 1500
byte Ethernet MTU.

Yes we can back off into TCP, but that does not work very well through
firewalls. I think we have a much cleaner approach using a new RR.

> There is more than serving unknown RRs - one should also consider the provisioning side of things and the client API.

This was the deciding factor in DKIM.

While I think that there is a use for DNS key assurance without
DNSSEC, mine is a minority view and my support for unsigned key
assurance is strictly to try to hook them on using DNSSEC anyway.

If we are expecting DNSSEC, I think we can expect there to be an
assumption of some degree of flexibility for provisioning. And this
whole effort will require a new API set. Instead of gethostbyname, I
would see us using getserviceconnection call that takes the name and
protocol label as criteria and returns a trust path for evaluation.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Aug 2010 17:08:33 -0400

> spill over the 512 byte DNS boundary and will be close to the 1500

Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Aug 2010 19:19:14 -0400

> Which is why the discussion has been to publish the fingerprint / hash and not the key / cert itself... You get key and validate that FP matches...

So in the context of TXT, CERT or new RR, you are agreed that this
cannot be done with the CERT record?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Aug 2010 17:32:16 -0700

>cannot be done with the CERT record?

Not at all; see <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 22 Aug 2010 21:35:46 -0400

OK, I had forgotten that 4398 had introduced URL types for certs. So
the principle that the cert record contain certs is already gone.

Do existing servers support adding new CERT types any more easily than new RRs?

How about storing a cert URL plus a hash? Two CERT records with the
same tag or define a new subformat to contain both parts?

As a practical matter we may have a bug in the standards process here
since according to RFC 4398 creating new CERT types requires a
standards action while assigning a new RR does not.

Rereading 4398, it is really not apparent how a relying party gets
from an SSL session initiation to a DNS cert record. It appears that
the tag field was intended for this, but I don't see how it can work,
the explanation is certainly rather vauge.

I would suggest combining the CERT record with the protocol specific
prefixing approach taken in DKIM.

---

From: Anthony Iliopoulos <[email-masked]>
Date: Sun, 22 Aug 2010 20:38:54 -0500

> Not at all; see <http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>.

I was actually about to respond that the CERT RR is extensible enough
to accommodate the fingerprint easily; just allocate a new type value
and the corresponding semantics, reserve one byte for the hash algorithm
type and the rest of the cert section is the fingerprint, but apparently
I had TLSFP in the back of my head.

Reading through the draft again, I wonder what is the motivation behind
including a TCP/UDP port number field. Although there is the provision
for specifying that the FP is valid for all ports, what purpose is that
field meant to serve ? It is introducing an additional authorization
layer/dimension to the TLS process. What is the consumer of this restriction
expected to be ? What if this needs to be more fine-grained e.g. allow
only a specific transport, or a transport other than TCP/UDP ?

Regards,
Anthony

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Aug 2010 15:05:41 +0200

> already rejected that approach for S/MIME.

SAML and IMI (aka information card) uses quite a bit of XML-DSIG both in
trust establishment and in the protocol flows (as I believe you know
;-)) and the world hasn't rejected those yet.

	Cheers Leif