Subject: [keyassure] multi-application certificate RRs

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 17:35:55 +0100

Paul Wouters <[email-masked]> wrote:
>
> 2) Try to make a new DNS record that can be used by more then just one
>    application (eg not SSHFP) to avoid spamming the apex.

Isn't this contrary to RFC 5507?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. SHOWERS AT FIRST. MODERATE
OR GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 12:50:50 -0400

I would hope that if we get people to start using DNS for their keying
material that there would also be more widespread use of SRV. In
particular for Web Services applications since we are likely to end up
with several hundred thousand of those in the not too different
future.

So if we are going to have

_http._tcp.example.com SRV 1 1 1 www1.example.com

Wouldn't it make sense to use the exact same approach for the protocol
specific keying information?

_http._tcp.example.com SRV 1 1 1 www1.example.com
_http._tcp.example.com CRYPTO "blah .... blah"

Note that in the case of SSL the client receives the server cert
during the protocol negotiation. Thus the question is not 'what cert
should I use', it is the same question as in DKIM 'is this key
(certificate) valid'. And if we are using certs we can stick an
extension in the cert to give the prefix at which to find it.

In DKIM there are actually two separate records. There are key records
that state that a key is valid for the domain and there are policy
records that state that a message from a domain should have a
signature.

If we are going to provide decent application security we need the
same scheme here. So the protocol specific record is going to be the
policy record and the key record is going to be another record:

_http._tcp.example.com SRV 1 1 1 www1.example.com
_http._tcp.example.com OPTIONS "ALWAY USE SLL FOR THIS"
_2wefih223h2.example.com CERTHASH "digest=SHA1:wehwefkjhwkjfh"

Question: should we copy from DKIM as Stephen suggests or try to
create a fixed binary format label?

My experience doing DKIM is that we are not going to enumerate all the
possible requirements for the policy record first time and we probably
won't get the certhash record right first time either.

My preference is to follow the DKIM precedent but use new RRs (not
TXT) as we are assuming people are doing DNSSEC here.

On Thu, Aug 19, 2010 at 12:35 PM, Tony Finch <[email-masked]> wrote:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 13:18:50 -0400

SRV is a good idea, but maybe not exactly what we want here.  In a  
related vein, we've been discussing in the XMPP WG how to authenticate  
delegations of services (so that an outsourced server can authenticate  
as itself instead of its customer), and this is approach I'm  
advocating now:

_xmpp-client._tcp.example.com SRV 1 1 1 apps.example.net
_xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer

(Should have the draft out later this week.) Note, however, that this  
is a slightly different use case from what we're discussing here.   
Namely, the goal of the XMPP stuff is to enable some sort of  
authentication on the SRV in the absence of DNSSEC.  It helps the RP  
figure out what *name* to expect, not what key.

If you're assuming DNSSEC and want to bind a key to a name, you don't  
need to attach the CRYPTO/CERT/whatever RR to the SRV.  Since the SRV  
is DNSSEC-signed, the target host just needs to authenticate as  
itself, so you would want the key to go with the target hostname (or  
its A/AAAA record).

--Richard

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 19:02:50 +0100

On Thu, 19 Aug 2010, Phillip Hallam-Baker wrote:

> material that there would also be more widespread use of SRV.

RFC 5507 argues against SRV-style name prefixes because they interact
badly with wildcards. On the other hand it is rather complacent about RR
type exhaustion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 16:10:36 -0400

There are issues with wildcards that are very specific to DKIM.
Specifically, in DKIM you want to be able to create policy records
that bind to *.example.com.

I don't see that as a problem here. But it is not insoluble in any
case. It would be addressed by XPTR.

The bigger problem is with using prefixes as a substitute for
requesting a new record by overloading TXT. There you have the problem
that a wildcard for one purpose can clobber unrelated prefixes.

That is not a problem here because we are using a separate record.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 19 Aug 2010 23:43:26 +0200

> _xmpp-client._tcp.example.com CERT 1 1 1 http://example.com/xmpp.cer

why serve the cert over HTTP, when you can provide a fingerprint of the public key that you should expect via DNS (with DNSSEC) right away?

> If you're assuming DNSSEC and want to bind a key to a name, you don't need to attach the CRYPTO/CERT/whatever RR to the SRV.  Since the SRV is DNSSEC-signed, the target host just needs to authenticate as itself, so you would want the key to go with the target hostname (or its A/AAAA record).

+1

	jakob

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 00:47:32 +0100

> that bind to *.example.com.

There are other email-related policy proposals (e.g. CSV "client SMTP
validation") that have the same problem. CSV specifies tree walking to
deal with wildcard problems, but tree walking is also discouraged.

http://www.bbiw.net/CSV/index.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN: EASTERLY 5 OR 6 BECOMING SOUTHWESTERLY GALE 8 TO STORM 10, PERHAPS
VIOLENT STORM 11 LATER. ROUGH OR VERY ROUGH, BECOMING HIGH FOR A TIME. RAIN OR
SQUALLY SHOWERS. MODERATE OR POOR.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 19:53:58 -0400

Yes zone walking is really really bad. Let's not do that.

Sent from my iPad