Re: [stir] Interop related topics for STIR

Roman Shpount <roman@telurix.com> Tue, 13 July 2021 21:55 UTC

Return-Path: <roman@telurix.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F2E3A13DA for <stir@ietfa.amsl.com>; Tue, 13 Jul 2021 14:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com
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 CTeKbMoV_DH8 for <stir@ietfa.amsl.com>; Tue, 13 Jul 2021 14:55:43 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552433A13D1 for <stir@ietf.org>; Tue, 13 Jul 2021 14:55:43 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id o7so13200649vss.5 for <stir@ietf.org>; Tue, 13 Jul 2021 14:55:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zldtFGnKgHqotAQ3s9EDZaP7nLcN7qQjbWeMOJ69wNo=; b=wDNy+8kxDkfScALpIFNqRWWqJ0YGKzpSOvc7O1twxcTDPMkcVlKe6Z+hLtGINEAFyz H56z683Tfkh6XkZAt0KObdKQM7GP4wshRCQUbinxDWdu+WgGsOkdzEUwnqj9S7WlqQTD /mXV+56Y8me4j+BUwysSpHv6vV6VNrZ9tXY1k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zldtFGnKgHqotAQ3s9EDZaP7nLcN7qQjbWeMOJ69wNo=; b=QRI9posXnvcOlQtiSubQeUKXIVx5dwr5ubqdoY67bJk9rsGZM4XWppckn7/+LOVhmH 4dH+g1k3j0dco4pCJyXdPHvwG9Ln5I/WTmXOo8dBu6USQxAmdcu+R2nl8UYgJm62NiAP 36ukfBiXh3gIcdDy+89yXJu57nyGqHFShSUsKuUT3/bbEPbUQTraKXU4oQEiEp03MM3Y rUxFvYyenpqWinkLenMOD3zi6djzepV2FUSJx9eWL9CNFPGWmzopgiQiCcrNLShVxjXb tznWzr5BlHt/EzxA/y2Yf145spssinbLcEoGigwHi3Sfm9/d3RjPEg3MpcgzkHDehEOs +QBA==
X-Gm-Message-State: AOAM5320Djb4upt8gvuHmAc+62xYd9SEZ+hrQliDaa9mGNoOnPsO7970 Nf2B2+3T9jjxzAE9KgVVW7SFm2cbyekfLg==
X-Google-Smtp-Source: ABdhPJzmzd7qHBZESiQUQJ3H50c6Ab8o3FUbT77LWUlLdQOkdgf4Ye8ZbrqJcDYDUvm+BtkXY1MWPg==
X-Received: by 2002:a67:7dd0:: with SMTP id y199mr9177970vsc.11.1626213341521; Tue, 13 Jul 2021 14:55:41 -0700 (PDT)
Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com. [209.85.222.52]) by smtp.gmail.com with ESMTPSA id w203sm33136vkw.20.2021.07.13.14.55.40 for <stir@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jul 2021 14:55:40 -0700 (PDT)
Received: by mail-ua1-f52.google.com with SMTP id v22so9196451uaj.13 for <stir@ietf.org>; Tue, 13 Jul 2021 14:55:40 -0700 (PDT)
X-Received: by 2002:a25:9bc6:: with SMTP id w6mr9109108ybo.159.1626212816781; Tue, 13 Jul 2021 14:46:56 -0700 (PDT)
MIME-Version: 1.0
References: <2C876D56-5E92-462F-890D-383076B91233@vigilsec.com> <CAD5OKxtE=W=wg8FDOC=yOqB6cHEAf5hoLWArvs6ysoeaWsxZMQ@mail.gmail.com> <8C2E746A-2B02-44CD-99F0-CA55C4051818@vigilsec.com> <CAD5OKxsQ+WO6zPcF49_DZV+DdxuNZJbSVWJtaRCTUqHAf2t80g@mail.gmail.com> <62682C90-8635-42B4-8D04-A89243ED54FF@vigilsec.com> <20E31A90-44D4-4F55-B67E-6106DC9D9763@team.neustar> <HE1PR07MB444105CF3A1F1E8C22553AD093149@HE1PR07MB4441.eurprd07.prod.outlook.com> <DEA7B3ED-ABD9-4BE6-8CE7-207849B18D75@chriswendt.net>
In-Reply-To: <DEA7B3ED-ABD9-4BE6-8CE7-207849B18D75@chriswendt.net>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 13 Jul 2021 17:46:45 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsn4gEnNfnre9WNff7iPyvvHGC2Ryjc+8uBp=SgfQ2bmA@mail.gmail.com>
Message-ID: <CAD5OKxsn4gEnNfnre9WNff7iPyvvHGC2Ryjc+8uBp=SgfQ2bmA@mail.gmail.com>
To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>, IETF STIR Mail List <stir@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046075a05c7082ddb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/C0guYU6q-JuwNn2ZOzR6RLqcWhQ>
Subject: Re: [stir] Interop related topics for STIR
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 21:55:49 -0000

Regarding 2 (SIP Message Date header), since the signature date is
already present in the Full-Form Passport, the additional Date header on
the actual message is completely redundant. Also, the Date header can be
modified or removed by equipment down the line from the SIP signer, so the
SIP message can be verified even if the Date header is not present. I
cannot claim that I've participated in every interop event, but this issue
has caused problems with OpenSIPS, Kamailio, Asterisk, and Ribbon SBC
(which affected most of the large US LD carriers). A lot of singed calls do
not currently insert the Date header even though it is required.
_____________
Roman Shpount


On Tue, Jul 13, 2021 at 4:29 PM Chris Wendt <chris-ietf@chriswendt.net>
wrote:

> Agree with Jon and Christer's comments, 1 we all agree on as discussed in
> meeting, but 2-3 and 5 are news to me, 2 is an important part of replay
> attack, could it be done in other ways, perhaps, but i think it’s a little
> late for that conversation at this point.  In US at least, there is a
> highly significant percentage of calls being signed as we speak,
> particularly after the June 30 deadline and these issues haven’t surfaced
> in IPNNI discussions, interop forums and real-world usage to my knowledge
> and i’ve been paying pretty close attention to this :)
>
> -Chris
>
> On Jul 13, 2021, at 4:03 PM, Christer Holmberg <
> christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:
>
> Hi,
>
> Regarding 4), I agree with Jon. As I’ve said before, a SIP message can
> exceed 1300 bytes even without STIR. If the usage of TCP for SIP needs to
> be better explained, that belongs to 3261 (or, perhaps a generic
> TCP-for-SIP draft).
>
> Regards,
>
> Christer
>
> *From:* stir <stir-bounces@ietf.org> *On Behalf Of *Peterson, Jon
> *Sent:* tiistai 13. heinäkuuta 2021 22.35
> *To:* Russ Housley <housley@vigilsec.com>om>; Roman Shpount <
> roman@telurix.com>
> *Cc:* IETF STIR Mail List <stir@ietf.org>
> *Subject:* Re: [stir] Interop related topics for STIR
>
>
> I think 1 needs to be fixed as an errata; it’s an actual bug in the
> current spec.  From my perspective, 2 and 3 are more “it would be nice”
> sorts of issues that we’d explore if we had some more substantial
> motivations to do an rfc8224bis – I don’t think they are worth doing a bis
> for on their own merits, especially not given the current state of
> deployment. 4 is not really a STIR issue, just a 20-year-old SIP issue that
> STIR is the latest thing to exacerbate. And as for 5, I’m not sure what the
> issue is… elaborate?
>
> Jon Peterson
> Neustar, Inc.
>
> *From: *stir <stir-bounces@ietf.org> on behalf of Russ Housley <
> housley@vigilsec.com>
> *Date: *Tuesday, July 13, 2021 at 11:57 AM
> *To: *Roman Shpount <roman@telurix.com>
> *Cc: *IETF STIR Mail List <stir@ietf.org>
> *Subject: *Re: [stir] Interop related topics for STIR
>
> Roman:
>
> Assuming that others agree with the way forward, it seems that 1-3 are the
> start of 8224bis, and it seems that 4 might be a new Operational
> Considerations in 8224bis.
>
> Again, assuming agreement on the way forward, 8226bis should reflect real
> implementation.  That said, 8226 also envisions finer granularity than we
> have seen so far.
>
> I think a STIR Torture Test document would be very valuable.
>
> Russ
>
>
>
>
> On Jul 13, 2021, at 2:41 PM, Roman Shpount <roman@telurix.com> wrote:
>
> I am moving this into a new thread.
>
> So far the following RFC8224 issues were identified:
>
> 1. Errata regarding quotes in ppt value (Errata ID: 6519). Need to verify
> that both ppt values with and without quotes are supported when Identity
> header is received
>
> 2. Date header is required. It should probably be optional since the
> information there is redundant when the Full-Form PASSportT is used.
> Several known implementations omit it.
>
> 3. Should it be possible to omit ident-info and ident-info-params when the
> Full-Form PASSportT is used? All implementations I have seen include it,
> but there are occasional mismatches.
>
> 4. When SIP message is over 1300 bytes, the request MUST be sent using a
> congestion-controlled transport protocol such as TCP (
> https://datatracker.ietf.org/doc/html/rfc3261#section-18.1.1
> <https://protect2.fireeye.com/v1/url?k=903fe637-cfa4ded5-903fa6ac-86073b36ea28-33d90488cafd9ba9&q=1&e=0b2e7635-bc78-4316-8051-c8abb27c2107&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3261%2Asection-18.1.1__%3BIw%21%21N14HnBHF%21oAy6J5s7jZgI4_5_yZuq0vQqaQNof-Hm5As08cXc4f_4q6Ey-LKdpEIAy_v4cJVm6QTc4w%24>).
> Considering that the Identity header is typically around 1000 bytes, this
> requires all networks to start using reliable protocols which is not
> currently the case. There is a way to work around this for the private
> links where MTU is under vendor control, but for links over the public
> internet, this needs to be clearly stated and tested.
>
> 5. I do not think RFC8226 reflects the actual practices for STIR
> certificates.
>
> We should also consider an informational document with STIR Torture test
> messages as well as BCP.
> _____________
> Roman Shpount
>
>
> On Tue, Jul 13, 2021 at 1:57 PM Russ Housley <housley@vigilsec.com> wrote:
>
> I think that a SIPIT would be a very good thing, but that is not and IRTF
> activity.  That said, I would be very happy to use this list to know about
> a SIPIT once it is organized.
> Are there other interoperability or ops-orient topics about STIR that
> needed to be discussed?  If so, please start a thread.
>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>
>