Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading
Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 25 July 2011 19:55 UTC
Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E4B21F8B87 for <sipcore@ietfa.amsl.com>; Mon, 25 Jul 2011 12:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.434
X-Spam-Level:
X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH0NrOozcdWd for <sipcore@ietfa.amsl.com>; Mon, 25 Jul 2011 12:55:13 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2FE21F8B85 for <sipcore@ietf.org>; Mon, 25 Jul 2011 12:55:13 -0700 (PDT)
Received: by vws12 with SMTP id 12so4035866vws.31 for <sipcore@ietf.org>; Mon, 25 Jul 2011 12:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M87kx6vJ4cI3sUk7Bd8tMkjyC6BavOjt6icHNGsTh0I=; b=KPKF1CfOylchXJKzXh64qDe7ePb9XRKKPpFHJKKZHjUCLYv4Zm7IOC5KOanp63gnYT YoVGpPPtHAAJnvPuJfWPEINV8/+eCiPUOp9T5X4U1r0kcKcwylJwUxygs5RTk0Tqt8KN yb1109grPTlqpfrlH89NODge279tuedgT3Esg=
MIME-Version: 1.0
Received: by 10.52.93.72 with SMTP id cs8mr4722700vdb.518.1311623712527; Mon, 25 Jul 2011 12:55:12 -0700 (PDT)
Received: by 10.52.167.34 with HTTP; Mon, 25 Jul 2011 12:55:12 -0700 (PDT)
In-Reply-To: <AANLkTimoriwsEvTTvmiX0_RSkzPUEiEJVXknnmz+O0nL@mail.gmail.com>
References: <064.81e343374deecdf821a6bab2507a302c@tools.ietf.org> <AANLkTimoriwsEvTTvmiX0_RSkzPUEiEJVXknnmz+O0nL@mail.gmail.com>
Date: Mon, 25 Jul 2011 14:55:12 -0500
Message-ID: <CAHBDyN7pPb7rxkMYKSYhRDBeM2qU2ppgvws7JsMiHy2HzSQ_MQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Cullen Jennings <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="20cf307cfdd476d3af04a8ea313b"
Cc: sipcore@ietf.org
Subject: Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 19:55:14 -0000
So, this is the issue that we were just discussing with regards to SEC-req-1. Note that the text and references are from RFC 4244). We did remove this text from the Security section and we should really just remove SEC-req-1. Regards, Mary. On Mon, Nov 8, 2010 at 12:14 AM, Mary Barnes <mary.ietf.barnes@gmail.com>wrote: > I agree. Removing this is consistent with some of the earlier text we > removed in terms handling and implications of missing information. > > Mary. > > On Sat, Nov 6, 2010 at 9:41 PM, sipcore issue tracker > <trac@tools.ietf.org> wrote: > > #44: 4244bis-02: security section misleading > > > > Section 9 says: > > With the level of security provided by TLS (SEC-req-3), the > > information in the History-Info header can thus be evaluated to > > determine if information has been removed by evaluating the indices > > for gaps (SEC-req-1, SEC-req-2). It would be up to the application > > to define whether it can make use of the information in the case of > > missing entries. > > > > No, TLS doesn't do that. TLS only guarantees you that the next-hop or > > previous-hop is who its cert claims it to be (assuming you trust its > > anchor), and prevents tampering by something in-between you and that > > previous-hop or next-hop. That doesn't mean that previous-hop or next- > > hop, or some upstream/downstream entity beyond it, did not modify the > H-I > > entries - including in ways which you cannot possibly detect. For > example > > it could have renumbered them, changed their content, etc. > > > > This section-9 paragraph is wrong, and we won't be able to satisfy the > > security requirements in appendix A.1 That's *OK*. We're not going to > > get better than that. In fact, we basically need that behavior, since > we > > need PSTN Gateways to be able to generate H-I entries based on ISUP info > > (even for numbers they don't own); and we need Diversion interworked to > > H-I too. > > > > -- > > > ------------------------------------+--------------------------------------- > > Reporter: hkaplan@… | Owner: > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > > Component: rfc4244bis | Version: 2.0 > > Severity: In WG Last Call | Keywords: > > > ------------------------------------+--------------------------------------- > > > > Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/44> > > sipcore <http://tools.ietf.org/sipcore/> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >
- [sipcore] rfc4244bis #44 (new): 4244bis-02: secur… sipcore issue tracker
- Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: s… Mary Barnes
- Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: s… Mary Barnes