On Tue, Aug 19, 2008 at 2:38 PM, Jonathan Dickinson <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Dave Cridland >> Sent: Tuesday, August 19, 2008 11:31 PM >> To: XMPP Security >> Subject: Re: [Security] TLS Certificates Verification >> >> On Tue Aug 19 22:19:31 2008, Jonathan Schleifer wrote: >> > "Eric Rescorla" <[EMAIL PROTECTED]> wrote: >> > >> > There would be several changes needed as already stated on this >> > list. And new XEPs would need to be created. XEPs for stuff for >> > which >> > already XEPs exist. If that's not reinventing, I don't know. >> > > One far-out and crazy problem that we probably need to keep in mind is that > this stuff needs to be configurable, and the current XEPs don't really cut it. > > "Who cares if it's configurable?" I hear you say. Quantum computers are just > around the corner, and we will be sitting here in a few years time coming up > with new XEPs to deal with cryptography issues introduced by quantum > computers. Rather save ourselves the work now and make sure we can negotiate > other ways of encrypting data. > > Not only that, but what if someone figures out a blocker with the protocol we > decide on? Firstly, if it happens before 3290bis is out we can easily change > our direction with a new protocol (for example, SCRAM is found to be fatally > flawed). It just keeps us fluid.
So, I would definitely hope that any new protocol we decided on would have enough algorithm agility to let us upgrade to newer algorithms--though as the experience with TLS 1.2 showed, this is often easier said than done. That said, if Quantum Computing suddenly allows us to factor 1024-bit numbers in practical periods of time, we've probably got a huge problem and it's not clear how to salvage any of our protocols. -Ekr
