[Standards] Unsigned DANE records for TLS assertions

Dave Cridland dave at cridland.net
Wed Dec 4 09:13:33 UTC 2013

On Wed, Dec 4, 2013 at 8:57 AM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> Hash: SHA1
> On 11/26/13 5:20 AM, Dave Cridland wrote:
> > On Tue, Nov 26, 2013 at 12:04 PM, Tony Finch <dot at dotat.at
> > <mailto:dot at dotat.at>> wrote:
> >
> > Dave Cridland <dave at cridland.net <mailto:dave at cridland.net>>
> > wrote:
> >>
> >> What I'm wondering is whether an initiator could use the
> >> presence
> > of a TLSA
> >> record to decide not to consider falling back to XEP-0220. In
> > other words,
> >> whether a domain could use them to assert that it has a valid
> > certificate.
> >
> > The DANE drafts that I produced (for mail protocols) specified
> > that clients should expect the server to have a valid certificate
> > and should not fall back to unauthenticated or unencrypted
> > connections.
> >
> >
> > Right, but that would assume the records are signed, correct?
> >
> > I'm vaguely trying to work out, too, the relationship between
> > XEP-0220 (which relies on an unspoofed DNS to operate) and unsigned
> > TLSA records. If, instead of XEP-0220, we used unsigned DANE, would
> > this work just as (in)securely?
> Why "instead of"? It seems that we have dialback and will have it
> forever, so why not build upon it and make it more secure via DNSSEC
> and TLSA records? That's what Matt Miller and I have been pursuing in
> draft-ietf-xmpp-dna.
Oh, sure. I'm deep into the land of theoretical pencil chewing. I think
XEP-0220 is a fine set of protocol building blocks, and when I say XEP-0220
I really mean classic dialback - ie, using db:verify to authenticate a

> > It's an interesting (to me) point, because going from unsigned TLSA
> > to either of signed TLSA (ie, proper DANE) or a CA-signed
> > authoritative certificate (ie, a proper cert) should be relatively
> > smooth.
> >
> > I suspect we still need to call back in the case of unsigned
> > records and self-signed certificates,
> Or something like anonymous DH?
That *certainly* needs a dialback, yes.

> > because otherwise an attacker could spoof the DNS and wouldn't need
> > to stage a server. If they can stage a server and spoof the DNS,
> > then they can already spoof XEP-0220.
> Correct.
> > I do not know whether it's harder to spoof two co-related unsigned
> > records within the same zone, though.
> >
> > I would note that an unsigned TLSA concept would implicitly mandate
> > TLS - as such, the right comparison is with XEP-0220 over TLS,
> > rather than "vanilla" XEP-0220.
> I'd be curious to hear what Tony or other DNS experts have to say.

Me too.

As I say, I'm waxing philosophical, here, but the concrete thing I'm really
aiming for is whether we can end up in a situation where my server can
automagically tell form *unisgned* DNS records that jabber.org claims to
have a valid certificate, and therefore not to fall back to classic
dialback if the proffered certificate is either untrustworthy or does not
authenticate the domain.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131204/42760df4/attachment.html>

More information about the Standards mailing list