[Standards] Unsigned DANE records for TLS assertions

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


-----BEGIN PGP SIGNED MESSAGE-----
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:
> 
> -----BEGIN PGP SIGNED MESSAGE----- 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>
>> <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

- -- 
Peter Saint-Andre
https://stpeter.im/


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

iQIcBAEBAgAGBQJSnvM2AAoJEOoGpJErxa2p+u4QALEXUryTkC/o8MTwpRSgs4B6
e3F38/tldTv/BvsjeyVL4vr2NhdqUpRK6DVGd3lCDklrPCImJmJ9bXhucYXD/lu5
scvpssgoIJNE/yeaJiHIZuXcPRySszIiYFO75atIrbv5aJb4AMWcQlqHaKCO8Xo8
gZDwOv6QRFwoiIYkBS/R5B1/fETTE3fmWEuqXv8vCtg6CB7i4GmksovAv6Sz+V4d
liPHI4bJgQGt5wcVwjrvOwypEW4TPcz2eg5PpnEzapI17pJ/WPUk8pxo2gBvJDOC
6oZKaMuspMCDw+Dvm3fBSlNSblkXHM9wMB1XxdzhIoIVPTo/F0AJ4yx0n4GPAK6J
4HbTfW3X00PdlC/BYh92H+QgV2nwrKz+hy1f6Q81y5c/Mw/vQCD5dMm1keGd1Rmt
NGsLUPJBkqHbm4RLp4Uarl2i5prwWk/SeU18ktJkLwg8ZBaDL/gghN698PeduCsk
UKAs/ZZfn45wgNpP0aeMtipQKP4wI6u6J3rVv0W4T+PJv+6RephGpBdaRKZdGnXS
w0QQnn6Nm51Jw2i0dgFbP35dU4vqSkEm9H97Ia10mEk1VFL6QRb7gJud/4r7JJg/
4VicHSaxqrNQxpmihKriCxZWzkM2VtwEjCQ+4BFZqx+wRgyfnzwfFReiFLtBdanO
3Tft20hKH4P+bQwGDCTU
=Qvsi
-----END PGP SIGNATURE-----



More information about the Standards mailing list