Dave, we are talking client 2 server only here for pinning. Not server 2 server.
That misunderstanding explains some of the other comments. I'm sorry if this was not clear. a. Yes, see my other email. DANE trusts the master root key and all other keys all the way to the server's sub domain. b. correct. c. See previous email. d. How is the jabber server admin in control when everyone has to trust the master root key and all subsequent keys up to the sub domain of the jabber server? That's not in the control of the jabber admin. ralf On Thu, Nov 14, 2013 at 5:07 PM, Dave Cridland <[email protected]> wrote: > On Thu, Nov 14, 2013 at 4:34 PM, Ralf Skyper Kaiser <[email protected]>wrote: > >> Pinning does not require a CA at all (private or public). Why use a >> feature (DANE) that requires a CA if it is possible to have the same level >> of security with Pinning; which requires no CA, works well with self-signed >> certificates, requires no infrastructure upgrade and which puts the direct >> trust into the hands of the server-admins? >> >> > I may regret asking, but how do you see this working with federation? > > So each server presumably makes an unattended leap-of-faith in order to > get your pinning info, and then every server has to store the pinning info > for every other server they ever contact? > > If the certificate was *also* signed by a CA, you'd at least limit the > initial LoF, and protect yourself against subsequent CA compromise - which > is basically the attack that Perrin et al consider. I hold that DANE > provides security against *initial* CA compromise as well, and obviates the > need to pinning as such - it certainly requires an infrastructure upgrade, > but provides a security upgrade as well. > > As such, I suspect your quote above has several flaws: > > a) DANE does not require a CA. > > b) DANE does work with self-signed certificates. > > c) DANE provides a higher level of security compared to mere pinning. > > d) DANE also puts direct trust into the hands of the service admin. > > Dave. > > > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
