Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?

Roman Shpount <roman@telurix.com> Tue, 13 July 2021 04:58 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 AEE043A1433 for <stir@ietfa.amsl.com>; Mon, 12 Jul 2021 21:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IFVISTGOoJSL for <stir@ietfa.amsl.com>; Mon, 12 Jul 2021 21:58:37 -0700 (PDT)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 070B83A1429 for <stir@ietf.org>; Mon, 12 Jul 2021 21:58:36 -0700 (PDT)
Received: by mail-qv1-xf34.google.com with SMTP id c5so9746858qvu.11 for <stir@ietf.org>; Mon, 12 Jul 2021 21:58:36 -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=MIJ+hZdV78WpFS2QKGQqMQzE2jA9ge5c89gJj1D+RgE=; b=J3DHFL5DL8E+Q9CjZqkxCZ/ihGCKviWEkWnHV+3WnssATTPBcBFnca27KufM9plqbh MWFeWyIeYrKbdc3me4ES53lrEPL5B4iMLWTAp9kq8hJ0Xjkn7lc5i/bsrscBtAPrMcFo 8imVc6DU5UcXez8CCk4ynNS73K8gaHN1UOr80=
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=MIJ+hZdV78WpFS2QKGQqMQzE2jA9ge5c89gJj1D+RgE=; b=H7xJo+W6RXuvWZcyCuRI2B0hI8Fc6aeV3pOB32hQNGLZKmrNX4J9SlWAqWPOtYnaT4 /0XTLiRsu37cx5exqLu/zAb1sbap6HUYutG76lzvfZlzNuGWvaUYuQujiDa1TrxTg/iw uwP8sFAUeUFR+2SDgNPRr3LBNjcpILx0diA9oJMfLvFFYbdc9wbWUKpnhTWmPA3YZDcW li9h+5dFHtjrjGKfZeDXja6yt2axmZrsWX2ZbMymzfNn5dmViZUPjMIrJOMfUZBxv+N8 0bY6Tt8KM0c7vAMHbE+t9+pI5ZKXatVrh2qRe5N+ZBkpJu7u0IQ3tmd3SfR77K+uYvcE nYxQ==
X-Gm-Message-State: AOAM532VvlrzCvAAcocbedFixD+INTVtKtlrWCe+z6tbKNoucVS4K75e Vz0Lxv52CKZoEQmzOK2nVzFX2sA9CL8Dfw==
X-Google-Smtp-Source: ABdhPJxEYlrCoOorXQQnHTL8u+Yo6JYPve69YWrgM4YI6WJSGFQGThgNQzMP+8uqFH1eAFrjHcqLzw==
X-Received: by 2002:a0c:8ccf:: with SMTP id q15mr2912695qvb.12.1626152314969; Mon, 12 Jul 2021 21:58:34 -0700 (PDT)
Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com. [209.85.219.182]) by smtp.gmail.com with ESMTPSA id y26sm7366563qkm.32.2021.07.12.21.58.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 21:58:34 -0700 (PDT)
Received: by mail-yb1-f182.google.com with SMTP id a16so32769868ybt.8; Mon, 12 Jul 2021 21:58:33 -0700 (PDT)
X-Received: by 2002:a25:ef0c:: with SMTP id g12mr3432818ybd.116.1626152313684; Mon, 12 Jul 2021 21:58:33 -0700 (PDT)
MIME-Version: 1.0
References: <B0BBFDFA-4203-4660-A982-80A5B8DED746@contoso.com> <CAHBDyN57-8-ctw8L-5ob_ti2azBwEGqyEApGVSMwJgNM68Uscw@mail.gmail.com>
In-Reply-To: <CAHBDyN57-8-ctw8L-5ob_ti2azBwEGqyEApGVSMwJgNM68Uscw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 13 Jul 2021 00:58:21 -0400
X-Gmail-Original-Message-ID: <CAD5OKxsy3xODy2mXHJcKB=ihwdOeLLYiLaDpORa4B33j7TUuhw@mail.gmail.com>
Message-ID: <CAD5OKxsy3xODy2mXHJcKB=ihwdOeLLYiLaDpORa4B33j7TUuhw@mail.gmail.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "stir@ietf.org" <stir@ietf.org>, "acme@ietf.org" <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000020c9205c6fa17ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/rDGVnPVSGMo59oT3AK1iuqk2Urw>
Subject: Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?
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 04:58:42 -0000

Usually, with any new network protocols, the last 5% of deployment and
interop take 95% of the effort. STIR/SHAKEN is about 10% deployed, so there
is a lot of work to be done, including a lot of interop testing and likely
RFC update based on the deployment experience.

The RFC for Identity relies on JWT functionality which is not normally
present in the current SIP stacks. It is designed to be implemented using
standard web development technologies and falls slightly outside of the
normal telecom implementation expertise. Furthermore, the Identity header
more than triples the average SIP message size, which according to
standards, should trigger the protocol change from UDP to TCP. Bad JWT
implementation and network issues associated with the increased SIP
message size already affect the reliability of legitimate calls. Most of
the currently deployed SIP equipment has interop issues in their Identity
or TCP/TLS implementations.

This is compounded by the fact that SIP is, at this point, a legacy
protocol. Most SIP calls are sent over unecrypted UDP, which would not be
acceptable for any modern protocol. At the same time, SIP over TLS has many
performance and reliability issues that would need to be addressed before
it is ready for industry-wide deployment. Dealing with the fact that a lot
of telecom equipment is not routinely updated and relies on being isolated
from public access and mutual interop to operate makes deploying anything
new an excruciating process. The current set of standards was not exactly
designed to make deployment easier.

To summarize, currently, this is a bit of a mess. I would expect people
working hard to fix this, but very few people seem to care. It feels like
the whole industry is going through the infamous "Mission Accomplished"
moment.
_____________
Roman Shpount


On Mon, Jul 12, 2021 at 1:39 PM Mary Barnes <mary.ietf.barnes@gmail.com>
wrote:

> For what has been implemented right now (i.e., basic calls), all the
> specifications are RFCs.  AFAIK no one has implemented ACME for
> certificate management (yet).
>
> Regards,
> Mary.
>
> On Mon, Jul 12, 2021 at 11:59 AM Salz, Rich <rsalz=
> 40akamai.com@dmarc.ietf.org> wrote:
>
>> Linked from today’s front page of The New York Times:
>>
>>
>>
>> How Do You Stop Robocalls?
>>
>> An F.C.C. rule that went into effect last month is meant to help put a
>> stop to those relentless calls about your extended warranty, and others.
>>
>> https://www.nytimes.com/article/stop-robocalls-scam-fcc.html?smid=em-share
>>
>>
>>
>> It talks about Shaken/Stir by name a couple of times.  Someone want to
>> tell the reporter there are still IESG issues that needs be resolved?
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>