Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
Eric Rescorla <ekr@networkresonance.com> Thu, 06 November 2008 05:04 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAAE3A68FE; Wed, 5 Nov 2008 21:04:52 -0800 (PST)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8EE3A687E; Wed, 5 Nov 2008 21:04:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level:
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+48l6EcuH+3; Wed, 5 Nov 2008 21:04:50 -0800 (PST)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5CA993A6842; Wed, 5 Nov 2008 21:04:50 -0800 (PST)
Received: from kilo-2.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id DBE096F59D2; Wed, 5 Nov 2008 21:04:22 -0800 (PST)
Date: Wed, 05 Nov 2008 21:04:22 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: sip@ietf.org, gen-art@ietf.org, suresh.krishnan@ericsson.com
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081106050422.DBE096F59D2@kilo.rtfm.com>
Cc: iesg@ietf.org
Subject: Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
> Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it > is a bit late, I would like to see a response to the "substantial" > concern that is raised. I have not taken the time to determine if > the man-in-the-middle attack is possible, and I hope the authors > can quickly tell if there is a concern or not. If there is a > concern, it needs to be corrected or documented in the security > considerations. I don't believe this is a serious issue. A response to Suresh's complete review is below. > Summary: This draft is almost ready for publication as Proposed Standard, but I have a few comments. > > Substantial > =========== > > Section 8.1: Responder identity > > When Bob does not respond with an UPDATE message, his identity is > not integrity protected. Absolutely correct. > The draft states that in such case, a MITM > attacker may tamper with the fingerprint but Bob would be aware of > this. It is not clear to me how Bob would be aware of this. Consider > the scenario where an attacker Eve (who can attack both the > signaling and media paths) has switched Bob's key fingerprint with > hers. She can receive encrypted media coming from Alice, decrypt it > for her own use and re-encrypt it for Bob and send it to him. How > will Bob detect this tampering? This is a classic single sided authentication situation. If Alice calls Bob and the attacker mounts a MITM attack, then it will not be able to impersonate Alice to Bob because it can't generate the correct RFC 4474 signature. Thus, either the attacker won't provide a valid signature (being anonymous from Bob's perspective) or it will produce a valid signature with its own identity. In either case, this isn't really a useful MITM attack since Bob thinks he's talking to the attacker, not to Alice. Note the analagous situation with SSL/TLS, where the attacker can mount an MITM attack, but only with an identity that doesn't match the identity that the client expects, so it's not useful. > Minor > ===== > > * draft-ietf-avt-dtls-srtp-05 needs to become a Normative reference instead of an informative reference. Section 6.10 has the following text > > "Implementations of this specification MUST support DTLS-SRTP" > > making it impossible to implement this spec without implementing DTLS-SRTP. This will also lead to a downref that needs to be called out. Good catch. It won't be a downref, though, since the other draft is also going to PS. > * Section 7: Call flow with STUN > > "Message (6): STUN connectivity-check response Bob -> Alice" > > Bob is responding to Message 5 instead of Message 3 as stated in the text. Please replace. > > Editorial > ========= > > * SBC (expand at first use) : Probably add reference to draft-ietf-sipping-sbc-funcs-07 > > * Section 6.10: s/less highly optimized/less optimized/ > > Typos > ===== > Section 1 Para 4: s/sigaling/signaling/ > > Section 6.7.2: s/appopriate/appropriate/ > > Section 6.9 Title: s/Encryptions/Encryption/ > > Section 7 Para 3: s/especialy/especially/ > > Section 8.6 para 2: s/taht/that/ > > Appendix A.3. : s/Reusage/Reuse/ > > Appendix A.18. : s/Negotation/Negotiation/ Thanks, I'll fix these. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Eric Rescorla
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Suresh Krishnan
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Eric Rescorla
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Suresh Krishnan
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Eric Rescorla
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Suresh Krishnan
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Eric Rescorla
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Suresh Krishnan
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Eric Rescorla
- Re: [Gen-art] DISCUSS: draft-ietf-sip-dtls-srtp-f… Suresh Krishnan
- Re: [Gen-art] [Sip] DISCUSS: draft-ietf-sip-dtls-… Dean Willis
- Re: [Gen-art] [Sip] DISCUSS:draft-ietf-sip-dtls-s… Schneider, Peter (NSN - DE/Munich)