[Security] TLS Certificates Verification

Dave Cridland dave at cridland.net
Tue Aug 19 15:01:35 CDT 2008


On Tue Aug 19 19:03:06 2008, Eric Rescorla wrote:
> What Dave is suggesting, I think, would be a garden variety TLS  
> handshake with
> whatever ciphersuites you already support and self-signed certs.  
> Then you'd run
> SASL with some challenge/response protocol and channel bindings  
> (you'd
> almost certainly want mutual auth here) and then on the basis of  
> the C/R
> note that you trusted the peer's self-signed cert

Right.

The interesting thing being that - assuming the shared secret  
mechanism is something like SCRAM - this could be the same mechanism  
we use to authenticate normally with the server - so there's really  
virtually no new code involved, potentially, and it makes the general  
operation even closer to "normal" XMPP channel setup.

[Note largely for Ekr - XMPP currently has MTI of DIGEST-MD5, and  
this obviously needs changing. I'd personally go for SCRAM as the  
replacement assuming it's ready in time, as it's a relatively simple  
to implement mechanism which provides reasonable security for the  
buck, and has been around for so long there's no chance of ikky IPR.]

I'll admit cheerfully this is not as strong, crypto-wise, as PAKE or  
even fingerprinting, but it's still reasonably strong, as as  
convenient to use for the user as PAKE, I think.

If a PAKE method that's definitively unencumbered shows up out of the  
blue, we can of course switch to that quite easily - at worst having  
a SASL EXTERNAL hoop to jump through.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


More information about the Security mailing list