On 3/4/09 2:40 AM, Dirk Meyer wrote: > > 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.
Dirk, you also mentioned in a private message that the XMPP client might need to initialize the TLS library in different ways. I don't know enough about existing TLS libraries to weigh in on that. > 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. Ideally, yes. The question is: what counts as a "special requirement"? As far as I know, both OpenSSL and GnuTLS now support SRP. I don't know whether they support channel bindings yet. It might help to make a list of the most common TLS libraries and figure out what features they support now and might support in future releases (e.g., perhaps the DotNet TLS layer will support SRP in the next release -- I have no idea). > 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-end > > I made something up that can provide this. I'd prefer not to build something homegrown, but we can work on this at the IETF. > But I'm not an expert, I may > have missed something. Is there anything in the IETF that could help us? I sure hope so. :) Peter
smime.p7s
Description: S/MIME Cryptographic Signature
