IETF Logo Mail Archive

Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]

Carsten Bormann <cabo@tzi.org> Thu, 30 June 2022 04:45 UTC

Return-Path: <cabo@tzi.org>
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 D8BF5C15CF5E for <ipv6@ietfa.amsl.com>; Wed, 29 Jun 2022 21:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 dMaceY173wDB for <ipv6@ietfa.amsl.com>; Wed, 29 Jun 2022 21:45:07 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (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 67A65C15CF5D for <ipv6@ietf.org>; Wed, 29 Jun 2022 21:45:05 -0700 (PDT)
Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LYQjn11dmzDCcc; Thu, 30 Jun 2022 06:45:01 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: Scripting attacks [was Next step for draft-ietf-6man-rfc6874bis]
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <d3d9d68a-adff-b29b-4d1b-78f82e6bf282@gmail.com>
Date: Thu, 30 Jun 2022 06:45:00 +0200
Cc: Ted Lemon <mellon@fugue.com>, Stuart Cheshire <cheshire@apple.com>, Bob Hinden <bob.hinden@gmail.com>, 6man <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2DD6902-EF02-4EA4-80D3-18820B912DF1@tzi.org>
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> <5BEFA97B-CF09-44D7-8C10-017FEAE4C3A8@tiesel.net> <e6ff75e7-b6c6-ea03-2e10-b1ad95d650f0@gmail.com> <98D15BD9-A631-4D09-AE9E-9D4C750714C9@tiesel.net> <95c82ad3-2138-ab2a-7ba5-57ad80472964@gmail.com> <E5C368C5-9DAE-4C61-ADDE-B881EA11EDA0@tiesel.net> <6968ca7b-dac3-b192-41ed-a193adab7eb4@gmail.com> <529B863C-BCC9-40C1-A5B8-B0598E7DF17C@tzi.org> <bf8c5c54-d548-a40a-0381-0583ef946f26@gmail.com> <CAPt1N1=4wbqrrzvwdr4FD7awa6pkyffhwRZC3zAWLs7uzY3BJQ@mail.gmail.com> <86509E47-77CE-4210-A1B7-C1E9955D9672@tzi.org> <CAPt1N1kYBMSA5Y7BZLMd9o96tBxFY7SrRUxb9jxfBNvBiA_OJQ@mail.gmail.com> <d3d9d68a-adff-b29b-4d1b-78f82e6bf282@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/vKvth7QhYbfKa7XG0tJ8FsZnWrk>
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: Thu, 30 Jun 2022 04:45:11 -0000

On 30. Jun 2022, at 06:40, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> For the present draft, one thing my small experiment shows is that we won't make things worse by adding zone identifiers to URLs. They too have to be guessed by the attacker, and in modern Linux they are things like "enxb813ebc170a4" out of the box. That makes the attacker's job significantly harder.

Do you know how enxb813ebc170a4 is generated?  (I.e., is the 48-bit thing in there guessable?)

I think I agree with the conclusion (at least, that it is quite hard/costly/lengthy to mount an attack based on this), but I think that it would be good to get a clean argument for that in the security considerations.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email