Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)

Brian Rosen <br@brianrosen.net> Mon, 02 March 2020 22:24 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7370A3A097F for <ecrit@ietfa.amsl.com>; Mon, 2 Mar 2020 14:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 RCWnYegFOZJj for <ecrit@ietfa.amsl.com>; Mon, 2 Mar 2020 14:24:16 -0800 (PST)
Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 A576B3A12F2 for <ecrit@ietf.org>; Mon, 2 Mar 2020 14:24:15 -0800 (PST)
Received: by mail-yw1-xc2d.google.com with SMTP id y62so1403506ywd.13 for <ecrit@ietf.org>; Mon, 02 Mar 2020 14:24:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ToUKNo8rywA/VY1UgyWFz0vA27cCH+3zL8JSLDyta+4=; b=kguiLkBW8tGArQgrta9NjQBZOVOQzvYJP+tgwyjIV6y7Uw5NjX29HP+vU+YmX3amd6 O/ws9fd+k5r+2D5lXI6JFGvfr6QN38RTLQQj37v7f8+pD9DJSjkh6QXxXXp0y2Oe+mBM yq7gdYmdiCxuqHYxkKFPETfDM38QDqqHGxRTzz+ZUJz6jr/8mkbWjQf9csyNdBIde7Hq pbHzlq/48meTRkUNkTyVbR27QKKkjLcWoekcaVtUEyuDiSq/9hLTuCLxhvPC80JJ7mt/ y0e8OZKWGPG1ARh4/e0evBWT1hJeqb8Qly2lK5GNtMZ9tla5d6bnU/sQ6Y1b4haLKoib ZCKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ToUKNo8rywA/VY1UgyWFz0vA27cCH+3zL8JSLDyta+4=; b=bm92QzOv0KJ/dPNd5KdWegwbUmG05VKvoh67TpEiwBGP/LnZzwgxgcnAtzCoFtOJAY wrmlKwAZkgKI7M6rqPWXN9e6kgLxAoOLeZKErMPnsy5gIkQ2A0qTo1hrCRFgxgdokFTT VZD3RYorn7fdSX0NIAIuc10yUJA85tvvsMKJ5B4y5ta1HGYgWLY4tIqDasU8l9/wOuJO 4WS671DroUEdN72+Ku8fdpQBJcX19GbXH0EmNm50ryybeQq2wrpYybdM2ZsybdhcJHK8 xSPBxFKC9sPJZt71s053M7D6Q0OuNJvrvWBUmvs08dx9cqOAZMeatYzwuIjtIcMtXy4S 65ag==
X-Gm-Message-State: ANhLgQ2YTplIxXUQLzkHIes6V3jmCPg1I13ZjvmaBcbAqUfL+vuWwAyw 49p7vs65GCa46gErPFmuc4ArdA==
X-Google-Smtp-Source: ADFU+vtzRhz+gNzRa2FMOk5kbzq0q3S99W8AVTYmNiDPJVp/pVyanoYCSTczX5rymJiL2C53SQFgmw==
X-Received: by 2002:a25:2c49:: with SMTP id s70mr1218355ybs.359.1583187854709; Mon, 02 Mar 2020 14:24:14 -0800 (PST)
Received: from brians-mbp-2871.lan ([72.23.94.147]) by smtp.gmail.com with ESMTPSA id w15sm8852663ywg.1.2020.03.02.14.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2020 14:24:13 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <4C966190-8F2F-42EB-BD24-60D90C86F2EA@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6A29F059-C9D7-4253-B850-0212B91E00AA"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Mon, 02 Mar 2020 17:24:12 -0500
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand>
Cc: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>, Allison Mankin <allison.mankin@gmail.com>, "ecrit-chairs@ietf.org" <ecrit-chairs@ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org>, "draft-ietf-ecrit-data-only-ea@ietf.org" <draft-ietf-ecrit-data-only-ea@ietf.org>
To: Roman Danyliw <rdd@cert.org>
References: <158318494177.27467.10769075669362560529@ietfa.amsl.com> <227ba0d7-8ace-2ad2-c28c-e74996210c4e@nostrum.com> <359EC4B99E040048A7131E0F4E113AFC0216F60CEA@marchand>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/byrp0nbhFjCWaLRh-IRDdw0_uzk>
Subject: Re: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 22:24:19 -0000

I’ll add Adam’s suggested language.

WRT the first issue: URIs to untrusted entities, I note that there is no discussion of untrusted entities in Section 7 of RFC 3986.  There is discussion of misleading URIs.  If I added text to the security section that read:

When the CAP message is passed by reference, the recipients of the MESSAGE may not have a trust relationship with the sender.  Recipients MUST take precautions in retrieving the CAP message because the URI may point to a malicious actor.  

Would that satisfy your concerns?

I will also fix the nits.

> On Mar 2, 2020, at 4:51 PM, Roman Danyliw <rdd@cert.org> wrote:
> 
> Hi Adam!
> 
>> -----Original Message-----
>> From: Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>>
>> Sent: Monday, March 02, 2020 4:45 PM
>> To: Roman Danyliw <rdd@cert.org <mailto:rdd@cert.org>>; The IESG <iesg@ietf.org <mailto:iesg@ietf.org>>
>> Cc: allison.mankin@gmail.com <mailto:allison.mankin@gmail.com>; ecrit-chairs@ietf.org <mailto:ecrit-chairs@ietf.org>; ecrit@ietf.org <mailto:ecrit@ietf.org>; draft-
>> ietf-ecrit-data-only-ea@ietf.org <mailto:ietf-ecrit-data-only-ea@ietf.org>
>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21:
>> (with DISCUSS and COMMENT)
>> 
>> On 3/2/2020 3:35 PM, Roman Danyliw via Datatracker wrote:
>>> Section 9.  Per “To provide protection of the entire SIP message
>>> exchange between neighboring SIP entities, the usage of TLS is
>>> REQUIRED.”, can you please provide guidance on how to use TLS.
>> 
>> 
>> I think the strong implication here is that TLS is to be used in the same way
>> that TLS is used in other SIP applications (in the same way that an HTTP
>> document saying "MUST use TLS" is pretty clearly saying to use HTTPS as per
>> the existing HTTP RFCs).
>> 
>> Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all _over_ the
>> place, so there's not anything particularly comprehensive to point to. The
>> best that I think could be said would be something along the lines of "...the
>> usage of TLS, as described in section 26 of [RFC3261], is REQUIRED."
>> 
>> Would that satisfy your concern?
> 
> I can appreciate this difficulty.  Sounds good to me. 
> 
> Roman