Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> Sat, 16 May 2020 16:50 UTC

Return-Path: <rifaat.s.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1753A0941 for <secdir@ietfa.amsl.com>; Sat, 16 May 2020 09:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tsAf0ntk-ZsI for <secdir@ietfa.amsl.com>; Sat, 16 May 2020 09:50:41 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4494A3A0940 for <secdir@ietf.org>; Sat, 16 May 2020 09:50:41 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id m185so915281wme.3 for <secdir@ietf.org>; Sat, 16 May 2020 09:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SBfB/vnnqeFl7yKOlhHI9G6bfAfUJRUeHTqIYGqTjgg=; b=b9WDO21SxaFu/ArBXZ+XOE6CTtTtk8/9M5K3V0OTBZ3UgcvZSh7XgLhB4OXcuMWjaJ f2+oepZu9ECcfb3bAJ0r719fBEuFVV6g4/HWrWS5gimWlOjEpKztzBvGllT5c/hsnrx1 07uz+VFKrcNUJzZkDlloIKQMmvdBeFkE3o1nCcHh3Tw8mfYDPccrEFFF/h2uLtPgLBmY 9jqYLp3GtXNRIELtrqWWduecmK120rOn9aziBt8j/WYQ/xlDLvgainZ9Ae893ZbskIDw 52Pdk1duxJuDKQxdUGEaWKRv8UOVQ2kwa3yAuTrL5dhSVi3BLmeDNGF0zSo7CKqiY51r etCQ==
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; bh=SBfB/vnnqeFl7yKOlhHI9G6bfAfUJRUeHTqIYGqTjgg=; b=UPtGDtliJWDBAeTJ0vXSpQ83/K7o97UrW0aUpoyM/M4uz5EjRc23SG+IWRv4/OYRAJ 296chxjUwy3ePNoQk0VzGaceXfeWk78bfEvAcJWQ0UCvm7RM5hLbDR/z0rrNc4dmIi+q lY3K6BLrlSL4TtBB/TqSIIGxsWKB1YRpQ7QM52UvNVBkz8vrTzzmInAILdyhEaCA7R5S 1mfvjYc0WFluEFxXzoqC2IG7aTOqqGB9MISCAlR6IMtdYJ/P79U+XtOULce2ebXbWGT8 xwmXmxUg+rA6AVfDR2156zhCBCGnOUYTIanTRZgWvEKWOQhicnN34TOT+NXz5oyudllE 0hsw==
X-Gm-Message-State: AOAM53144l8FzPkKREBqYgZy9XtbocL/+ByBFQoVdvef4nYx8bV/c/Cp fje1rv0Mvq36ZL+m7ReTDGmLqEV2Nhj5vdVeXloE+DvY
X-Google-Smtp-Source: ABdhPJy+qgO24U0n6H3FDLaRG55eJheXcp5fIhzks2LPbONKyk5BHNnawJyQt+u+HeOjBHKhhmBaNFaEsV/ykAM1mgA=
X-Received: by 2002:a05:600c:231a:: with SMTP id 26mr10558872wmo.59.1589647839240; Sat, 16 May 2020 09:50:39 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP8o+d4ivAacHQiXUk96F0gDqFe2Qa6rPQsCBgDr_=wHrQ@mail.gmail.com>
In-Reply-To: <CADNypP8o+d4ivAacHQiXUk96F0gDqFe2Qa6rPQsCBgDr_=wHrQ@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Sat, 16 May 2020 12:50:28 -0400
Message-ID: <CADNypP9hk+gpGuch0mxnePTVRMnn+GmCbpFpKYkVRV4C_FRUgA@mail.gmail.com>
To: secdir@ietf.org, mt@lowentropy.net
Content-Type: multipart/alternative; boundary="000000000000c6a63305a5c6ba51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/RAUttjtpPpKBvfanvuMjFRuGf9s>
Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-rfc7710bis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2020 16:50:43 -0000

Adding Martin.

On Fri, May 15, 2020 at 8:47 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
wrote:

> Hi  Martin,
>
> Sorry, I missed this message as I changed email address because some
> spammers have been sending spams with my email address as a sender, and as
> a result I would get angry emails from the spam targets.
>
>
> Here is a quote form the API document:
> "The hostname of the API SHOULD be displayed to the user in order to
> indicate the entity which is providing the API service."
>
> This seems to suggest that the user is expected to inspect the displayed
> name and make sure it is make sense in the context of whoever is providing
> that service.
>
>
> Here is a quote from this document:
> "An attacker with the ability to inject DHCP messages or RAs could
>
>    include an option from this document to force users to contact an
>    address of his choosing.  As an attacker with this capability could
>    simply list himself as the default gateway (and so intercept all the
>    victim's traffic); this does not provide them with significantly more
>    capabilities, *but because this document removes the need for
>    interception, the attacker may have an easier time performing the
>    attack*."
>
>
> Since this would be an easier attack compared to the interception attack,
> and IP address is still permitted, then an attacker might force the use of
> IP address to make it harder for the user to make sense of the displayed
> name.
>
> Regards,
>  Rifaat
>
> [adding back some lists]
>
> -Ben
>
> On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote:
> > What does "extra cautious" mean?  I assume that this is intended to apply to what a human might do, further implying that there is a role for a human decision.
> >
> > None of this architecture requires the involvement of a human in this way. Nor do I think that there is any meaningful distinction between an opaque string of characters (that might include confusables) and an opaque string of digits.
> >
> > I appreciate the sentiment here, but the fundamental problem is that once you decide that this information is not from the network, it is useless. If it is from the network, it is only of limited use. That use cannot depend on the identity of the server, so there is no value in any sort of caution.
> >
> > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote:
> > > [My unicast reminder got a unicast reply; forwarding to someplace at least
> > > vaguely useful.]
> > >
> > > -Ben
> > >
> > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote:
> > > > Thanks for the reminder Ben.
> > > >
> > > > Erik,
> > > >
> > > > Since this document allows the use of IP address to represent the portal
> > > > URI, I think it would important to add some text that explicitly states
> > > > that the user might be presented with an IP address instead of the hostname
> > > > of the API, and in that case the user should be extra cautious when this
> > > > happens.
> > > >
> > > > Regards,
> > > >  Rifaat
>
>
>
>