[Standards] Unsigned DANE records for TLS assertions

Peter Saint-Andre stpeter at stpeter.im
Wed Dec 4 09:17:42 UTC 2013

Hash: SHA1

On 12/4/13 2:13 AM, Dave Cridland wrote:
> On Wed, Dec 4, 2013 at 8:57 AM, Peter Saint-Andre
> <stpeter at stpeter.im <mailto:stpeter at stpeter.im>> wrote:
> 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>
>> <mailto:dot at dotat.at <mailto:dot at dotat.at>>> wrote:
>> Dave Cridland <dave at cridland.net <mailto:dave at cridland.net>
> <mailto: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 domain.
>> 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 <http://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.

I'm waxing sleepy because it's 2 AM here, but I don't see how we get
that level of trust with unsigned DNS records...


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Standards mailing list