Re: ESSID ietf-v6only at IETF 100 - security

joel jaeggli <joelja@bogus.com> Tue, 14 November 2017 07:32 UTC

Return-Path: <joelja@bogus.com>
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 812D0124B18 for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 23:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 gV3cFr6DvC2O for <ipv6@ietfa.amsl.com>; Mon, 13 Nov 2017 23:32:09 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDE21294A1 for <ipv6@ietf.org>; Mon, 13 Nov 2017 23:32:06 -0800 (PST)
Received: from dhcp-88cf.meeting.ietf.org (dhcp-88cf.meeting.ietf.org [31.133.136.207]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAE7W223030901 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Nov 2017 07:32:04 GMT (envelope-from joelja@bogus.com)
Subject: Re: ESSID ietf-v6only at IETF 100 - security
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Warren Kumari <warren@kumari.net>
Cc: IPv6 <ipv6@ietf.org>
References: <acd854c7-8bd2-781e-6d0d-b15bb62c48e2@gmail.com> <CAHw9_iKoYrfuf_UjBeVw+=cCD9Kuc4+zPPsR1kqrxAAza59qXg@mail.gmail.com> <88d14301-f417-da89-a526-954f44149af8@gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <15e70479-ea25-6031-dec6-01189a233a37@bogus.com>
Date: Tue, 14 Nov 2017 15:31:28 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <88d14301-f417-da89-a526-954f44149af8@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QbLuB3qgE_43NuiwoQXpfTHVEJs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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 Nov 2017 07:32:10 -0000

On 11/14/17 14:59, Alexandre Petrescu wrote:
> 
> 
> Le 14/11/2017 à 07:24, Warren Kumari a écrit :
> [...]
> 
>> ​Nope. We have the legacy SSIDs because some people apparently had
>> issues connecting to encrypted SSIDs (because of old OS / broken
>> wpa_supplicant, etc) - this wasn't issue with certs, but rather
>> providing a solution for those who are unable to do WPA enterprise /
>> have old cards, etc.
> 
> Well - sorry, but all these reasons seem light for me.
> 
> I have Windows 7 which is not old.  Updated regularly from Microsoft and
> from employer IT.

Mainstream support ended January 13, 2015. It works, if you were looking
for a more streamlined experience, the user experience has improved a
bit since then, it has not been backported.

> The WPA_supplicant comes from original.  It is widely accepted at many
> other hotspots.
> 
> My laptop is very well able to do WPA enterprise, and WPA2 Enterprise.
> 
> The laptop is a Dell E7440, 2 or 3 years old.  I dont accept to call
> that old.  What makes laptops old is when they break; they often break
> because of mechanically moving parts like hd, but this one is SSD.
> 
> Rather, I suspect there is a preference at the Access Point to favorise
> Macintosh variations of WiFi Clients, rather than Windows.

There's no obvious basis for that assertion.

> I also wonder why my Windows complains that the cert emmitted by IETF is
> "not configured as a valid anchor".  Should I manually install that
> cert?  If so, that is little reasonable to ask.
https://tickets.meeting.ietf.org/wiki/IETF100network
https://802.1x-config.org/?idp=137&profile=101

> Alex
> 
>>   There was an assertion made that some people were not using nat64
>> and were using ietf-legacy were easier, and so there should be parity,
>> and so the ietf-nat64-unencrypted was created.
>> We are changing the name of the ietf-legacyXXX network at each meeting
>> because we don't people who connected to it at a previous meeting to
>> become sticky to it and keep joining -- it requires a specific action
>> at each meeting for the user to choose the unencrypted network -- we'd
>> all prefer that people use the encrypted network...
>>
>>
>>
>>     And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
>>
>>
>>
>>
>>     Alex
>>
>>
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     <https://www.ietf.org/mailman/listinfo/ipv6>
>>     --------------------------------------------------------------------
>>
>>
>>
>>
>> -- 
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>     ---maf
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>