Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP?
Iñaki Baz Castillo <ibc@aliax.net> Thu, 29 March 2012 11:58 UTC
Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC82821F89DD for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 04:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.623
X-Spam-Level:
X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rk97-m1YF7c for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 04:58:39 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 955CC21F84EE for <rtcweb@ietf.org>; Thu, 29 Mar 2012 04:58:39 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1620052vbb.31 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 04:58:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=NRIb9kRUh8qF9oU/SrEihKhvXhhzDaorSIYrjEVyt6c=; b=Rqc1qAlFVXboi9OpME3Zqcwuz9oEryQm7Yof5zw9muAWZ4xvOF+iNM1Z9kFMFtZ990 YWVXqnJSqCDVKUorVd1Dv+ssgzltW526qYiQn3/OX9RmeNbKw2XtzQ+X4rQxcGnRoIzO oyzzBsn9nhA2TW08XpiWz9PlK/g1+L9TJ2v5LLp+rZYZfYvtFnKUV1W88oJG2XJEbfQF ZlPkXwskxqHqI6Vy8+mz637eHu+182Q4VKT0yn+MH1m2se7pK+RuKujiWIG8RuYo7Lhh ukGXOPWYt3a8PvtE6ciaLMnEL2mmSHxR6DPCGUABk0W9AAldhUI/uV3nR7conzGf9601 pEWA==
Received: by 10.220.152.205 with SMTP id h13mr11857619vcw.12.1333022313876; Thu, 29 Mar 2012 04:58:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 29 Mar 2012 04:58:06 -0700 (PDT)
In-Reply-To: <4F7409C4.407@infosecurity.ch>
References: <4F73697D.5080006@infosecurity.ch> <CALiegfnF-8TCzkE9NiDsWz8PVNXtCtmpDKPYz65YLfdGVPQTqQ@mail.gmail.com> <4F7409C4.407@infosecurity.ch>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Thu, 29 Mar 2012 13:58:06 +0200
Message-ID: <CALiegf=czyTqs=PtkkEDWaEHLYju6K=hF35h00o6LzpqW2EM5A@mail.gmail.com>
To: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmy6l/XaRhCzuITSDbw3u+r6SGQ/pJbWmFT9fvSBDyw4dA2ULXkP+sl/h/VEXDURmH+/SoS
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DTLS-SRTP implementation diffusion: Why not SDES-SRTP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 11:58:40 -0000
2012/3/29 Fabio Pietrosanti (naif) <lists@infosecurity.ch>: > That's true, but it's also true that the "rtcweb world" will strictly > inter-operate with the "sip world". > > It would be reasonable to expect that current existing PBX software > would evolve also with support for Rtcweb, to provide Web phone systems. Right, but it also reasonable to expect that those SIP PBX do implement some security, at least SDES-SRTP. NOTE: I do know you are not talking about allowing plain RTP in WebRTC ;) > In particular all opensource software will setup the path for the > adoption of the standard, as we know history will repeat. > > It appear me as natural behavior of diffusion of implementation, and for > that reason i see the need to "easily" inter-operate with the SIP world > is a key value point. > > Creating an incompatible "media format" would require a lot of more > effort because the "amount of compatibility testing to be done with > DTLS-SRTP will be significantly higher than SDES-SRTP" . I agree. >> http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf > > I would like to strongly argue against the SLIDE 3 statement that > "DTLS-SRTP meets RTCWEB's technical requirements" . > > DTLS-SRTP doesn't meet the RTCWEB's technical requirements because: > > - It does NOT provide inter-operation with existing SIP endpoints > > This is confirmed by the October 2011 SIPit data, with 80% of > participants supporting, with good interoperability, SDES but with 0% > supporting DTLS-SRTP . > > In order to try to "try to improve it's non-interoperability issue" the > DTLS-SRTP is re-proposing him-selves as DTLS-SRTP-EKT . > > To speaking about the fact that even EKT draft explain that: > " Today, Security Descriptions [RFC4568] is used for distributing SRTP > keys in several different IP PBX systems and is expected to be used > by 3GPP's Long Term Evolution (LTE). " > > http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-01#section-6.1 > > So: > - Internt is using SDES-SRTP > - 3GPP LTE is using SDES-SRTP > - WebRTC is going to use DTLS-SRTP > > I do not really see how we can rationally accept to follow this > different direction. Well, AFAIK the decision for WebRTC is one of the following options (assuming that plain RTP is not allowed, for which there was consensus yesterday in Paris): 1) Mandate DTLS-SRTP(-EKT?) implementation and dissalow SDES-SRTP. 2) Mandate DTLS-SRTP(-EKT?) implementation and allow SDES-SRTP (optional). 3) Mandate DTLS-SRTP(-EKT?) implementation and also SDES-SRTP. I vote for option (3) so WebRTC can *already* interop with well tested SDES-SRTP environments. Is option (3) good for you? > The argument that DTLS is *more secure* must face the reality that > no-one is using it and that SDES-SRTP is *widely diffused and > interoperable*. > > All Internet operators will have to introduce Protocol Gateway. > All mobile operators will have to introduce Protocol Gateway. It's worse than that. If you read slides 34 and 35 in http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf, the "Media Gateway" MUST be also a *signaling* B2BUA (cannot be a proxy) since it needs to generate re-INVITE in one leg (for crypto key updates) !! I hope I will not need that annoying stuff in order to make WebRTC to interoperate with SIP networks (assuming SDES-SRTP in those SIP networks, of course). > So definitely the choice to go for DTLS-SRTP is imho a wrong choice, > against any rationale for the diffusion of WebRTC standard, introducing > artificially complexity where it may be possible to keep it simple. Worse, it's not just choosing a non tested standard, but creating a new specification. The slide 39 says: ------------------------ Do part of DTLS handshake in ICE connectivity checks – draft-thomson-rtcweb-ice-dtls ----------------------- So if that *new* spec is mandatory for WebRTC, then forget interoperability with any other network. Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
- [rtcweb] DTLS-SRTP implementation diffusion: Why … Fabio Pietrosanti (naif)
- Re: [rtcweb] DTLS-SRTP implementation diffusion: … Iñaki Baz Castillo
- Re: [rtcweb] DTLS-SRTP implementation diffusion: … Fabio Pietrosanti (naif)
- Re: [rtcweb] DTLS-SRTP implementation diffusion: … Iñaki Baz Castillo
- Re: [rtcweb] DTLS-SRTP implementation diffusion: … Igor Faynberg
- Re: [rtcweb] DTLS-SRTP implementation diffusion: … Randell Jesup