Re: Gen-ART LC review of draft-ietf-siprec-protocol-16

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 01 June 2015 19:39 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6281B3262; Mon, 1 Jun 2015 12:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.211
X-Spam-Level:
X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk7bEPUnAWpL; Mon, 1 Jun 2015 12:39:14 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137671B31DD; Mon, 1 Jun 2015 12:39:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2923; q=dns/txt; s=iport; t=1433187550; x=1434397150; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+nOaXhcB6+KDAhQ8MG41DTmYSlzICvMk9nKSh3uGxE=; b=l0KY19PbLd3pmRyKHwx8CXbeW1982ZCtg4v/0EkZPxpZzF6+PmOnGnYR 22i1whVPb46/WFY7pPL8NpYaFIdj7SLqqexEnXx3ZyXSNUuea0MWHFGk0 IgYnYzQB08j2dg8VnFO9xHQGrbfUqVMJGPEkZW1LrRrjdeZfoitxqU7uy M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlBACutGxV/4YNJK1SCoMQgTIGvlYJh1ECgTY4FAEBAQEBAQGBCoQiAQEBBG4LDAQCAQgRBAEBKAcyFAkIAgQBDQWILdhTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pBgQKEKV0HBoQnAQSMDIcEixaBK4NzjkGDWSNhgxdvAYFFgQEBAQE
X-IronPort-AV: E=Sophos;i="5.13,534,1427760000"; d="scan'208";a="155239689"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 01 Jun 2015 19:38:49 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t51Jcn7X026653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 19:38:49 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 14:38:49 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, Jari Arkko <jari.arkko@piuha.net>, Peter Yee <peter@akayla.com>
Subject: Re: Gen-ART LC review of draft-ietf-siprec-protocol-16
Thread-Topic: Gen-ART LC review of draft-ietf-siprec-protocol-16
Thread-Index: AQHQj4a8XKigFBYwJE2LvgVrGDgmTJ2Og7YAgAIbyICAB2UUgA==
Date: Mon, 01 Jun 2015 19:38:48 +0000
Message-ID: <D191FCEE.4E6FE%eckelcu@cisco.com>
References: <D17BB964.10F58%peter@akayla.com> <3E5AFFC4-59B0-44EB-BE2B-180D99C7A8FF@piuha.net> <9F33F40F6F2CD847824537F3C4E37DDF1E773ABA@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E773ABA@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.1.150515
x-originating-ip: [10.154.176.27]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B109BA3566F019409ED76DE6FAE19520@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5fR1yUtI0AsT2cA4dgeLqNVDPO0>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, "draft-ietf-siprec-protocol.all@tools.ietf.org" <draft-ietf-siprec-protocol.all@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 19:39:16 -0000

Great comments. Please see comments inline.

On 5/27/15, 12:43 PM, "Hutton, Andrew" <andrew.hutton@unify.com> wrote:

>Thanks for the commens see below.
>
>Regards
>Andy
>
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko@piuha.net]
>> Sent: 26 May 2015 12:31
>> To: Peter Yee
>> Cc: draft-ietf-siprec-protocol.all@tools.ietf.org; gen-art@ietf.org;
>> IETF Discussion Mailing List
>> Subject: Re: Gen-ART LC review of draft-ietf-siprec-protocol-16
>> 
>> Thank you for your extensive review, Peter.
>> 
>> Authors, do you have thoughts on Peter's questions? FWIW
>> I thought these at least were important points:
>> 
>> > Page 21, section 8.1.5, 2nd paragraph, 1st sentence: by "content" do
>> you
>> > actually mean "context"?  Or do you mean to the content of a SIPREC
>> > recording?
>> ...
>
>I think this should really be "context" so should be changed.

Agreed. It is actually occurs in two places, in section 8.1 and as noted
in section 8.1.5. I will fix in both places.
 
>
>
>
>> > Page 38, section 12, 2nd paragraph, 3rd sentence: perhaps the word
>> > "effective" would be more appropriate than characterizing it as an
>> > "automatic" downgrade?
>> >
>
>Good comment "effective" would be a better wording.

Changed to ³effective security downgrade².

>
>
>
>> > Page 38, section 12.1, 1st paragraph, 2nd to last sentence: just
>> because
>> > an SRS is compromised does not mean that it cannot be authenticated.
>> It
>> > may very well be operating "correctly" and be able to authenticate,
>> yet
>> > the compromise allows the attacker to obtain the (decrypted) RS.
>> > Authentication does not imply that the SRS you are talking to is not
>> > compromised.  It only indicates the SRS possesses some form of
>> credential
>> > that appears to identify it correctly.
>
>Cannot argue with that and probably we should remove the sentence
>starting "The risk of not authenticating the SRS...".

The two sentences expanding on the impact of the SRC and SRS not
performing mutual authentication are as follows:

"The risk of not authenticating the SRS is that the recording may be sent
to a
   compromised SRS and that a sensitive call recording will be obtained
   by an attacker.  On the other hand, the risk of not authenticating
   the SRC is that an SRS will accept calls from an unknown SRC and
   allow potential forgery of call recordings."


Rather than removing, what if I change to the following:

"The risk of not authenticating the SRS is that the recording may
be sent to an entity other than the intended SRS, allowing a sensitive
call recording to be received by an attacker.  On the other hand,
the risk of not authenticating the SRC is that an SRS will accept calls
from an unknown SRC and allow potential forgery of call recordings.

Cheers,
Charles

>
>
>
>> 
>> Jari
>