On Wed, Mar 4, 2009 at 1:40 AM, Dirk Meyer <[email protected]> wrote: > Hi, > > sorry for the delay, I was busy the last two days. > > Eric Rescorla wrote: >>>> 2. The XTLS <security/> element enables a party to provide a hint about >>>> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >>>> methods are defined for that functionality. I could work with the >>>> authors of DTLS-SRTP to include something along these lines. >>> >>> How do they solve the problem of bootstrapping trust? We could force >>> x509 if we talk to SIP clients, e.g. a SIP client will always support >>> this methid and has no fallback. I know, that sucks. >> >> I'm not sure I understand what the advantage of this functionality is in >> any case. > > The idea behind the method exchange is to know in advance if X.509 > certificates will work or if we need SRP. For SRP the client has to ask > the user while X.509 works without any user interaction. > > We could just try X.509 and do an SRP re-keying later if we can not > verify the certificates. But at least my TLS lib does not support > this. Which reminds me of a problem: I talked to Klaus yesterday because > we both want to implement XTLS and do some interopts. He uses DotNet and > the DotNet TLS layer does not support SRP. Before Dave jumps in and > promotes channel bindings: they won't work either. As far as I > understand channel bindings you need the TLS Finished messages for > it. DotNet has no support for this either. > > What we need is a way to make the channel secure WITHOUT any special > requirements from the TLS lib. > > o It should be secure with a short password (e.g. four digests on a > keypad of a mobile phone) > o It MUST detect the end-to-end characteristic of the TLS stream by > either: > 1. Detect if there is a MITM, or > 2. Exchange the X.509 certificates used end-to-en > > I made something up that can provide this. But I'm not an expert, I may > have missed something. Is there anything in the IETF that could help us?
I must have lost the thread of what you're trying to accomplish here somewhere. The basic idea behind DTLS-SRTP (and connected identity) is that you trust the signalling channel (SIP or the XMPP channel you're using to set up the direct connection) to accurately convey the end-party's certificate fingerprints so they can be conveyed. There's no real intention to verify them independently of that because the niotion is that they are verified by RFC 4474 signatures from the proxy responsible for the relevant section of namespace. Now, that isn't to say that if you and I had some independent mechanism for verifying each other's identities we couldn't use it, but it's not the main thing we were trying to achieve because we figured that wasn't the common case. So, I'm not sure you need any external validation, especially if you use key continuity in the future. With that said, it's quite straightforward to build such a system usng information provided by nearly any TLS library: cryptographically bind the passphrase/PIN to the certificates exchanged by either side. Of course, this entails running the authentication exchange in the application layer which is a pain since TLS already has one, but... -Ekr
