Hi Dirk,
On Mar 4, 2009, at 1:40 AM, Dirk Meyer 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?
Another option would be to use a certificate enrollment protocol such
as CMC or SCEP, which would enable the holder of the password to get a
certificate, then to just use the cert as needed. The enrollment
protocols use public key encryption of the password and they resist
offline dictionary attacks (as does SRP and EKE). If certificates
are already an option, this might be a low-impact way to go.
David
Dirk
--
In the Beginning
It was a nice day.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
