Subject: [dane] Reusing TLSA

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Sep 2012 09:51:57 -0700

I'm starting this as a new thread because Richard conflated two topics *and* missed the fact that there is already a WG document.

The question becomes what the registration of an RRtype "means". If it means the bits on the wire of the *response* and their semantics, then I think the S/MIME document can use the TLSA RRtype. If an RRtype also means the bits on the wire of the request and response, we can't.

Personally, I think that the RRtype is defined just by the bits in the response, so we could reuse, but others might disagree.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 18:55:32 +0200

Ok, yeah, I am really off today. 

FWIW, in case it wasn't clear, I am in favor of re-using the TLSA RR type for S/MIME (finding it under a different name).   That is, removing Section 5.1 from the WG document, which is mis-named anyway.

--Richard

-- 
Richard Barnes
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Monday, September 24, 2012 at 6:51 PM, Paul Hoffman wrote:

> _______________________________________________
> dane mailing list
> [email-masked] (mailto:[email-masked])
> https://www.ietf.org/mailman/listinfo/dane
> 
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 24 Sep 2012 17:06:46 +0000

> Personally, I think that the RRtype is defined just by the bits in the response, so we could reuse, but others might disagree.

In my naivete, I've interpreted the RRType to define the bits in the response.  Which explains why I've been confused why draft-hoffman-dane-smime can't re-use TLSA.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Sep 2012 19:12:46 +0200

[ Quoting <[email-masked]> in "Re: [dane] Reusing TLSA..." ]
> In my naivete, I've interpreted the RRType to define the bits in the response.  Which explains why I've been confused why draft-hoffman-dane-smime can't re-use TLSA.

The question does not even have the rdata part.

To me it looks if we are in violent agreement: re-use TLSA in dane-smime.

 Regards,

-- 
    Miek Gieben                                                   http://miek.nl

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 24 Sep 2012 13:36:03 -0400

On 24/09/2012 12:51, Paul Hoffman wrote:
> I'm starting this as a new thread because Richard conflated two
> topics *and* missed the fact that there is already a WG document.
>
> The question becomes what the registration of an RRtype "means". If
> it means the bits on the wire of the *response* and their semantics,
> then I think the S/MIME document can use the TLSA RRtype. If an
> RRtype also means the bits on the wire of the request and response,
> we can't.
>
> Personally, I think that the RRtype is defined just by the bits in
> the response, so we could reuse, but others might disagree.
>
> --Paul Hoffman
>

There are are two parts to TLSA reuse.

1) the RDATA format
2) The registries created for TLSA RR fields.
	a) TLSA Certificate Usages
	b) TLSA Selectors
	c) TLSA Matching Types

Reuse of the TLSA format under another name can specify a different set
of registries to use for the different fields.
Reuse of TLSA RR by a protocol means subscribing to supporting new
entries in the above registries and even allowing new entries in there
that only make sense in one context.

Current draft is silent on registry usage, which I take to mean that the
TLSA registries are shared/inherited.

Having said this I'm not sure if I care if TLSA is used or SMIMEA.

PaulW, there is nothing in RFC6698 that says that NON-TLS uses of TLSA
MUST use the same naming schema as TLS uses.

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Tue, 25 Sep 2012 00:32:22 +0100

> 	a) TLSA Certificate Usages

There are a few other semantics-related questions:

* Would sharing an RRtype lead to the DNS returning too much irrelevant
data in response to queries? In this case not, because we are using
prefixed labels to disambiguate.

* Would sharing an RRtype lead to useful code sharing between S/MIME and
TLS implementations?

> that only make sense in one context.

TLS is about authenticating peers. S/MIME is about encryption as well as
verifying signatures. So I would expect TLS records to be more about
digests of certificates (for brevity) whereas S/MIME records to contain
public keys or entire certs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Dan York <[email-masked]>
Date: Tue, 25 Sep 2012 15:06:52 -0400

> public keys or entire certs.

As I've been reading this whole conversation I've been struggling with this last kind of point in my brain, mostly because I think of this not in terms of "Using DANE with S/MIME" but rather in terms of "Using DANE with $foo" where S/MIME is merely one of hopefully many different protocols that could work with DANE. (My own personal interest, coming from the VoIP space, is in seeing how it might someday work with SIP.)

I keep coming to three questions:

1. What is the easiest option for developers creating applications?
2. What is the easiest option for infrastructure operators who may be barriers to having those applications work?
3. What is the easiest option for DNS hosting providers where DNS records may be entered?

My worry with #2 is that if we have a proliferation of RRtypes for each value of $foo, we'll wind up with a situation where some infrastructure components (ex. aggressive firewalls) may need to be changed to allow each RRtype to be allowed through.  Similarly for #3, a graphical user interface where people enter records would need to be changed to support each new RRtype.  Some DNS hosting providers might do this quickly, some wouldn't. Either way it's work they have to do.

Sticking with a single RRtype for any "DANE" usage would make these parts far simpler.  Get them to support the "TLSA" record and they're done.

Likewise, for application developers, the use of a single RRtype would potentially allow sharing of code between different $foo implementations.

BUT... to Tony's last point, are we in fact making it *harder* for developers by overloading the TLSA RRtype with different types of content?  Or is that adequately addressed by having the second left-most label in the domain name (ex. "_smimecert") be the way that a developer would know what is in the TLSA RR and therefore how it should be processed?

Still pondering all this,
Dan

-- 
Dan York  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 15:32:35 -0700

On Sep 25, 2012, at 12:06 PM, Dan York <[email-masked]> wrote:

> BUT... to Tony's last point, are we in fact making it *harder* for developers by overloading the TLSA RRtype with different types of content?  

No, because the types of content are identical.

> Or is that adequately addressed by having the second left-most label in the domain name (ex. "_smimecert") be the way that a developer would know what is in the TLSA RR and therefore how it should be processed?

That's not content, that's the request you used to get the content.

As Ben pointed out earlier, we need to make a few changes saying "where DANE talks about a chain sent by the server, this document is talking about a chain sent by the other party". But the contents are the same.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Sep 2012 09:46:05 +0100

> No, because the types of content are identical.

They are not, as I just pointed out in the other thread.

> As Ben pointed out earlier, we need to make a few changes saying "where DANE talks about a chain sent by the server, this document is talking about a chain sent by the other party". But the content…

You could argue that all RRs merely contain bytes, so their contents
are "the same". If they mean different things, then they're not
_really_ the same.

It could be that TLSA could be redrafted to fix this problem.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Sep 2012 07:56:09 -0700

> They are not, as I just pointed out in the other thread.

Unless I missed it (certainly a possibility), what you pointed out was different semantics for identical content. That is, where the RFC talks about the trust anchor for the server, and chains sent by the server, we need to change that to trust anchors used by, and chains sent by, the sending party. No bits on the wire change, right?

> are "the same".

No, you can't. The TLSA RR has particular fields with particular structure. That structure is identical in SMIMEA.

> If they mean different things, then they're not
> _really_ the same.

Nor do they need to be _really_ the same, just have the same format.

> It could be that TLSA could be redrafted to fix this problem.

It sounds like that a new RFC can update the TLSA draft. That's exactly what we are proposing. :-)

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Sep 2012 16:06:14 +0100

> It sounds like that a new RFC can update the TLSA draft. That's exactly what we are proposing. :-)

I am more than happy for our different brands of pendantry to coexist
in this case :-)

---

From: Dan York <[email-masked]>
Date: Wed, 26 Sep 2012 11:34:16 -0400

Paul, 

> public keys or entire certs.

To me it just seemed that there could be app developer confusion if in the one case the TLSA record is a digest of a certificate and in another case the TLSA record might be a full certificate.

Having said that, I've now gone back and re-read RFC 6698 and seen clearly that this is all covered with the Matching Type field in section 2.1.3 and so any "DANE implementation" needs to be able to understand both the digest and the full certificate.

So consider my comments withdrawn.... and thanks for the replies that forced me to deepen my understanding of the DANE protocol. :-)

Dan

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Sep 2012 10:04:08 +0100

Dan York <[email-masked]> wrote:
> > verifying signatures. So I would expect TLS records to be more about>
> > digests of certificates (for brevity) whereas S/MIME records to
> > contain public keys or entire certs.
>
> To me it just seemed that there could be app developer confusion if in
> the one case the TLSA record is a digest of a certificate and in another
> case the TLSA record might be a full certificate.
>
> Having said that, I've now gone back and re-read RFC 6698 and seen
> clearly that this is all covered with the Matching Type field in section
> 2.1.3 and so any "DANE implementation" needs to be able to understand
> both the digest and the full certificate.
>
> So consider my comments withdrawn.... and thanks for the replies that
> forced me to deepen my understanding of the DANE protocol. :-)

I think I agree with Dan. My comments were meant to be thinking out loud
rather than objections as such - just trying to enumerate what the
differences might be between TLSA and SMIMEA, in usage and semantics if
not syntax.

Tony.