Re: Next step for draft-ietf-6man-rfc6874bis

"Philipp S. Tiesel" <philipp@tiesel.net> Tue, 14 June 2022 13:54 UTC

Return-Path: <philipp@tiesel.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C050EC15949B for <ipv6@ietfa.amsl.com>; Tue, 14 Jun 2022 06:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiKdkB7Sf7mh for <ipv6@ietfa.amsl.com>; Tue, 14 Jun 2022 06:54:35 -0700 (PDT)
Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8852EC159485 for <ipv6@ietf.org>; Tue, 14 Jun 2022 06:54:32 -0700 (PDT)
X-Envelope-From: philipp@tiesel.net
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id 25EDsPZ01896326 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 14 Jun 2022 15:54:25 +0200
Received: from [193.155.137.3] (helo=smtpclient.apple) by x-berg.in-berlin.de with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <philipp@tiesel.net>) id 1o16zx-0005m5-0F; Tue, 14 Jun 2022 15:54:25 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: Next step for draft-ietf-6man-rfc6874bis
From: "Philipp S. Tiesel" <philipp@tiesel.net>
In-Reply-To: <149924f9-da30-fa79-0509-c01c439d1796@gmail.com>
Date: Tue, 14 Jun 2022 15:54:23 +0200
Cc: 6man <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Stuart Cheshire <cheshire@apple.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BEFA97B-CF09-44D7-8C10-017FEAE4C3A8@tiesel.net>
References: <164938402532.17740.11717866110301931501@ietfa.amsl.com> <b1780128-2069-b32e-7ca5-86977c119f0c@gmail.com> <11d4e419-11a9-8768-abf2-1335e5f1c3d8@gmail.com> <149924f9-da30-fa79-0509-c01c439d1796@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IbZuULaUUCl26v2JMnc6YnFPRrA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2022 13:54:39 -0000

Dear authors and WG,

based on this WG last call, I reviewed the document. Overall, it is well written and mostly ready to publish, 
but I have a) one issue with the Security considerations section and b) a possibly stupid question on usefulness in web context:

a) The Security Considerations Section states:
>    It is conceivable that this format could be misused to probe a local
>    network configuration in some way.  However, that would only be
>    possible for an attacker that had already gained sufficient control
>    of a host to originate HTTP messages.  Such an attacker could more
>    easily probe using basic mechanisms such as the "ping" command.
   Is this true? What prevents an attack from embedding scoped IPv6 addresses in HTML documents, e.g., as part of an AD.
   While the security model of the browser/device should prevent abusing it from taking action REST calls to your home router, including a well-known image from such a device should be possible and could be used to verify an identity by linking to the EUI64 address of your home router and verifying the image was loaded. This is far easier than “pinging” the router.  

b) Assuming a device has only link-local connectivity and a web interface, is there a way to reference “same interface as used for this connection”? If not, such a web interface could only use relative links and things like re-direction to https will become hard.

AVE!
  Philipp   

> On 11. Jun 2022, at 03:56, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Dear 6man-chairs (especially Jen),
> 
> The authors believe that this draft is now stable and we request a WG Last Call. It would be nice to get this done before the IETF meeting.
> 
> Regards
>   Brian Carpenter
> 
> On 19-May-22 12:52, Brian E Carpenter wrote:
>> There's been no more discussion for several weeks. Can we move
>> on to a WG Last Call?
>> Regards
>>     Brian Carpenter
>> On 08-Apr-22 14:29, Brian E Carpenter wrote:
>>> Hi,
>>> 
>>> This version reflects comments at the IETF and on the list.
>>> Change log:
>>> * Extended use cases (added Microsoft WSD)
>>> * Clarified relationship with RFC3986 language
>>> * Allow for legacy use of RFC6874 format
>>> * Augmented security considerations
>>> * Editorial and reference improvements
>>> 
>>> Note that some of the text about RFC3986 that Shang Ye
>>> suggested to remove has been retained, but modified. Further
>>> comments about this, or any other aspect, are very welcome.
>>> 
>>> Regards
>>>      Brian + co-authors
>>> 
>>> On 08-Apr-22 14:13, internet-drafts@ietf.org wrote:
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>>>> 
>>>>           Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
>>>>           Authors         : Brian Carpenter
>>>>                             Stuart Cheshire
>>>>                             Robert M. Hinden
>>>> 	Filename        : draft-ietf-6man-rfc6874bis-01.txt
>>>> 	Pages           : 13
>>>> 	Date            : 2022-04-07
>>>> 
>>>> Abstract:
>>>>      This document describes how the zone identifier of an IPv6 scoped
>>>>      address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>>>>      (RFC 4007), can be represented in a literal IPv6 address and in a
>>>>      Uniform Resource Identifier that includes such a literal address.  It
>>>>      updates the URI Generic Syntax and Internationalized Resource
>>>>      Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>>>>      obsoletes RFC 6874.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/
>>>> 
>>>> There is also an HTML version available at:
>>>> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01
>>>> 
>>>> 
>>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>> 
>>>> 
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--  
Philipp S. Tiesel
https://philipp.tiesel.net/