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
> >
>