-----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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> Dave Cridland <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> >> 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-----
