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?
Dirk
--
In the Beginning
It was a nice day.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
