Subject: meeting ietf-legacy ssid

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jul 2017 02:34:34 +0200

the noc sees a quite large number of associations to the unencrypted
ietf-legacy ssid as opposed to say the encrypted ietf ssid

some of us are wondering if those using ietf-legacy

  o do not realize it is completely unencrypted over the air, or

  o don't care as their threat model sees runnin' nekkid over the air as
    not a significant additional weakness, or

  o believe that they are using sufficient encryption at higher layers
    to meet their needs, or

  o other

these days, some meetings do not provide unencrypted wifi at all and
seem not to get complaints.  maybe their attendees are just geekier
and/or more security conscious.

clue bat, please.  unicast responses accepted too.

randy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Jul 2017 20:42:52 -0400 (EDT)

>  o other

Why should I trust anyone at the IETF? The security is out of my control,
so it is as good as unencrypted to me.

And of course, if you can't not trust your friends, who can you not trust?

Paul

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Jul 2017 02:59:51 +0200

Hi Randy,

It may be a side effect of some OSs. It seems that many of them remember the SSID, and they tend to use the first one that was learnt or the one that offers better signal, etc.

So, if the user chooses ietf-legacy in an OS, at some point and then later used ietf5ghz (just to put an example), the OS will “prefer” ietf-legacy, unless you go to your control panel and change the “order” of those SSIDs preference.

So, a simple way to avoid that, is to rename the ietf-legacy at each IETF meeting with the IETF meeting number, for example ietf-legacy99 for the next one.

At this way, the standard SSID (ietf5ghz in my example) gain the preference.

Same scheme of ssdi+ietfnumber, can be used to make sure that as many users as we wish, go to our “preferred” network (for example NAT64). We just need to change our actual mind to get used to it.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Randy Bush <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de julio de 2017, 2:34
Para: IETF Rinse Repeat <[email-masked]>
Asunto: meeting ietf-legacy ssid

    

    
      o other

    
    randy

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Jul 2017 11:00:55 +1000

Perhaps it's non-IETF people using what looks to be very high-quality, free wifi?

> On 12 Jul 2017, at 10:34 am, Randy Bush <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Jul 2017 21:35:55 -0400

> On Jul 11, 2017, at 8:34 PM, Randy Bush <[email-masked]> wrote:
> 

This is not the case for me.  I also run unencrypted at home but have
a large property where without a directional antenna you can not receive
my wifi.  If you put that much effort into it, it still may not work due
to trees.

I seem to recall (this may not be true) that ietf-legacy is also only
2.4ghz, so sometimes my device sees this first as there are fewer channels
to scan compared to the 5ghz + DFS frequencies while waiting for a beacon.

>    not a significant additional weakness, or

This is part 1.  Model covers unencrypted SSID as that’s commonly given
out at hotels and other venues.

>  o believe that they are using sufficient encryption at higher layers

This is happening, I’m using SSH, SSL and my DNS is tunneled through
a VPN (to a non dual-stack server, gah!)

> and/or more security conscious.

I tend to end up with all the SSIDs pre-programmed, including ietf-hotel
which is valuable as it permits me to not roam, but have a seamless user
experience.

My experience is with the conferences that encrypt WiFi 100% of the time,
I must re-enter the username/password or might not have them handy, or
my device says ACHTUNG regarding the certificate change and requires me to
take a manual action to join this seemingly “new” network, even if it’s
a familiar one.

This means I tend to have to force it once to rejoin the secure network,
but I’ve likely already fallen back to the insecure network first.

At least this is the way it’s generally presented to me via MacOS.  I have
also had mobile devices, including Raspberry PI type things that join the
wifi when I’m doing other experimental things.  They can be configured
to just join the first open SSID that is available.  This is nice as I don’t
have to do as much configuration work to make it happen, and I’m already
using SSH or some other transport to access the devices.

Related:

If the open SSID were to go away, I don’t expect there to be any issues
other than a few newcomers needing to learn what the passwords are.  This
caused me issues with one of my first meetings when presented with a non-
open wireless network, but I was able to ask what the password was and 
easily received it.

If Con is doing his statistics board again of the SSIDs, perhaps putting the
username/password there would also be of value should the legacy ssid be phased
out.

- Jared

---

From: George Michaelson <[email-masked]>
Date: Wed, 12 Jul 2017 12:10:47 +1000

>From time to time, my devices fail to bind adequately to the secure SSID.

When that happens, I find the unsecured one works.  Perhaps simpler
logic, perhaps different codepaths? I don't know. I observe that it
works more often than not.

So, I use it opportunistically, as a function of unknown failures in
cryptographically secured SSD binding logic, as exposed in OSX and
Android.

I don't use it by preference: I use it as a fallback.

When the SSID binding is fine, the DHCP/DHCPv6/slaac is all a
subsequent issue. I do still find that from time to time, the WiFi
decides not to have a default router. If you tcpdump your WiFi the
typical view at these times, is a million IETF people sending ARP. I
like to imagine the NOC looks like a herd of kittens with a large ball
of wool, desperately searching for an end, while simultaneously biting
each others tails.

-George

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Jul 2017 14:20:50 +1200

>     not a significant additional weakness, or

If you don't feel that way, there are millions of networks you can never
use, including most hotels, cafes etc.

>   o believe that they are using sufficient encryption at higher layers

If you believe that, you're probably wrong ;-)
 
>   o other

1) For whatever reason my Android 4.3 phone has always seemed allergic
to the ietf network (although after much torture, it agreed to connect
to eduroam). So it only knows about ietf-legacy and ietf-hotel.

2) On my laptop things are better, but I do have ietf-legacy lower in
the list as a fallback.
 
> and/or more security conscious.

...or they just don't care as long as it works. There's a lot of
that about.

Jordi is correct about the ordering of SSIDs in the list kept by the
o/s. If you don't manually push ietf-legacy down the list, it may well
be picked automatically.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 11 Jul 2017 19:45:36 -0700

I think that, as an experiment to see what the impact is, we should not have ietf-legacy at IETF99.

The IETF is telling the word it’s important to use encryption, we should be eating our own dog food.

Bob

> On Jul 11, 2017, at 7:20 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2017 02:55:06 -0000

>Perhaps it's non-IETF people using what looks to be very high-quality, free wifi?

We tend to fill up whatever hotel we're in do I doubt that's it.

I like the theory that our devices remember whatever networks we've
used and reconnect automatically.  My Mac certainly does, and I need to twiddle the
settings to push the better networks higher in the list.

R's,
John

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jul 2017 10:37:00 +0200

On Wed, 12 Jul 2017 07:38:20 +0200, a linux hacker wrote privately:
> 
> Ive used it because my linux laptop wouldnt bind to anything else. Not
> sure why.

this is a case that worries me deeply.  folk with issues should visit
the help desk in the terminal-less room or visit the noc.

On Wed, 12 Jul 2017 07:54:44 +0200, Eliot Lear wrote:
>
> Why not just turn it off and see what happens?

because the noc thinks of the attendees as those strange critters called
"customers."  this creates implications for service continuity.

On Wed, 12 Jul 2017 08:46:11 +0200, Christian Huitema wrote:
> 
> You may want to tabulate the OS version of the devices on the
> un-encrypted network. Can your DHCP server do that? That should give you
> some indication.

i proposed measuring a number of aspects of use of ietf-legacy, mostly
port use; wanting to get a feel if the use was protected above layer
three.  i specifically avoided proposing looking inside the packsts as i
do not have time to deal rigorously with the PII issues.  when i asked
if i could measure port use, i was asked to write up a formal project
description.  as this is not my paying $dayjob, i hit delete.

for me, the botttom line here is

   please try networks other than ietf-legacy.  if you have problems
   which drive you to legacy, please come to the noc and debug.

   this is something to be revisited when we know more.

thanks for the clues.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 12 Jul 2017 10:29:54 +0100

> o/s. If you don't manually push ietf-legacy down the list, it may well

At RIPE meetings, they work around this by having a unique legacy SSID
per meeting, which has driven down usage noticeably.

Nick

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Jul 2017 12:08:47 +0200

Hi Randy,

If you want to run experiments, I think that's fine, personally.  But as
to this:

> "customers."  this creates implications for service continuity.

The rest of the world who aren't engineers seem to manage ok with WPA. 
Unless there is an accessibility requirement hidden here.  Another
approach: turn -legacy into a hotel network and simply ask people why
they're not using the other.  Not the most secure way to go about
things, but again, we're supposed to have a clue.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jul 2017 12:23:50 +0200

> per meeting, which has driven down usage noticeably.

/me likes

should not break anyone; though takes thought starting up if you want to
run nekkid.  that's kind of a feature.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2017 09:04:36 -0400

> The IETF is telling the word it’s important to use encryption, we should be eating our own dog food.

Perhaps so, but if that's the case we might want to do real security and not universal-shared-symmetric-key security.   But I think the IETF generally takes the position that security is something that happens above layer 2, right?

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Jul 2017 14:09:08 +0100

> On 12 Jul 2017, at 09:37, Randy Bush <[email-masked]> wrote:
> 

This recent Apple support article is relevant, at least for iOS users :)

https://support.apple.com/en-gb/HT202831

>   this is something to be revisited when we know more.

The above Apple article suggests that once you do switch, your device will prefer the most recently used SSID.

Personally I use eduroam, and it’s preferred for me by iOS. The snag is that if some other SSID is auto-joined, it’s not clearly indicated on the device; you just see the WiFi indication in place of 3/4G.

Tim

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 12 Jul 2017 14:56:58 +0000

On 7/12/17, 4:37 AM, "ietf on behalf of Randy Bush" <[email-masked] on behalf of [email-masked]> wrote:

[JL] Fair enough. How about any traffic to that SSID pops a user message that says this is an old SSID and is being phased out, please change to another one now, etc. The CAPPORT WG may have some running code they can use to try this out. And as others have said, I would bet that most prior attendees have many IETF SSIDs in their config and turning one off will just result in the OS picking a different one on the list.

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jul 2017 17:06:26 +0200

> because the noc thinks of the attendees as those strange critters
> called "customers."  this creates implications for service continuity.
> [JL] Fair enough. How about any traffic to that SSID pops a user
> message that says this is an old SSID and is being phased out, please
> change to another one now, etc. The CAPPORT WG may have some running
> code they can use to try this out. And as others have said, I would
> bet that most prior attendees have many IETF SSIDs in their config and
> turning one off will just result in the OS picking a different one on
> the list.

ripe meeting solution, e.g. renaming the ietf-legacy ssid to
ietf-legacy##, for every meeting.

from the discussion so far, it is not clear that there are no folk
depending on legacy; excuse the double negative.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jul 2017 11:37:07 -0400

Lets face it, the whole WiFi connection thing is junk and it is a part of
the network that is not in a place where the IETF usually acts - the UI.

Well, that is fine because the IETF is part of ISOC and do you know what
else just became a part of ISOC? The Online Trust Alliance. And they are
all about security, trust and UI.

I think that we maybe should have a talk about this with some ISOC folk
because it is definitely an area where maybe we need a bit of 'joined up
standards making'. There are parts of this problem that lie in CABForum
space, OTA space and IETF space.

I presume that there will be ISOC people there. We should talk about what
parts of the problem should lie where. I am not happy with the fact that
the WiFi alliance has still not provided a secure user experience after all
this time and obviously sees no need for one.

This issue is becoming a very serious political issue and has been the
reason that I have been making trips to D.C. recently to speak to members
of Congress and their staff. With Congress gridlocked, the range of
legislation they can get through is small, the only thing that people can
agree on is the need for better cyber security. Do people want to have that
conversation under the ISOC umbrella or do I have to use congressional
staffers to jackhammer the obvious into people's management chains?

Yes, the WiFi thing is a problem. And yes we need to fix it. Maybe get
round a whiteboard with some beers. Think outside the box and this problem
solves itself: have a mechanism for the access points to say 'ietf-legacy
is also me' and the client can upgrade. But that is just one detail and we
won't solve the user's problem if all we do is solve each problem as it
presents itself, taking three years each. Lets just design something that
does not stink and to do that we have to admit some of the reasons that
Security Usability remains miserable.

The big problem that I see with the Security Usability folk is that many
think it fine to say, 'users can't understand security indicators' so we
don't do them. This is wrong for several reasons.

1) We spend an inordinate amount of time telling users they they should
take care online but not how to make themselves safe. A product that
refuses to even let the user see the information that would allow an expert
to make that determination is a bad product.

So that is the first thing to realize. If the research tells you that your
product stinks. Don't you dare use that research to say that the problem is
impossible. Because your bosses-bosses-boss might just end up in a hearing
next to me and he might just end up agreeing with me.

2) If we can't give useful advice now, we have to work out how to change
the protocol so that we can in future. Users cannot understand a
Certificate Transparency log or a PKIX cert chain. But they might just be
able to intuit that the older a certificate is, the more likely it is that
they might understand it. Hence my proposal for a 'First Issued' aka
'Member Since' extension for certs.

3) The alternative is allowing certain large Internet services to turn
parts of the net into gated communities. Having obstructed (or demolished)
all the infrastructures that could provide some security for users against
the attacks THEY care about (identity theft, not mass surveillance) they
will stick to the big names they know and trust to prevent them going into
the 'bad' parts of the net.

This is of course the old walled gardens issue but in a different form. Oh
and my is the US Republican Party onto that one. If you look at the
legislation some members that claim to be anti-regulation have proposed
recently, it is a real eye opener.

The people I am meeting with know what I am and what my roles are. The
reason they are giving me time of day is because they know that a gated
community run by two companies very strongly aligned with their opposition
is not in their interest. It is not in our interest either to have security
systems to be a part of applications and platforms that are welded in so
the user has no choice over them.

Microsoft recognizes this, that is why there is an API for anti-virus to
plug into and you can choose to use the Microsoft one or a different one.

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Wed, 12 Jul 2017 19:33:39 +0000

On Wed, 12 Jul 2017, Randy Bush wrote:

>the noc sees a quite large number of associations to the unencrypted ietf-legacy ssid as opposed to say the encrypted ietf ssid

My corporate laptop using any major browser, such as Chrome, Firefox or IE, fails to bind. The error message pops up a message something along the lines that cannot validate the SSL owner or certificate....And sadly, leaving no choice but to connect to IETF-legacy or IETF-Hotel. I will be happy to walk over to the NOC to help troubleshoot.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Jul 2017 14:13:14 -0600

I use "IETF Legacy" because 1) it is easy 2) if you think encrypting your traffic over the first 50 feet is all you need to do, well what can I say. (and of course I understand Randy and probably everyone else on this thread does not think that)

I'd use something else if it was as easy and worked as well - perhaps if we turned off Legacy, I would be forced to discover there was something I liked better but in general I am at IETF to get work done not to eat dog food. In general I think that the IETF has spent a good amount of time on "making it harder for the bad guys" but not enough time on making security "easy for the good guys". 

> On Jul 11, 2017, at 6:34 PM, Randy Bush <[email-masked]> wrote:
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Jul 2017 13:30:03 -0700

>    o believe that they are using sufficient encryption at higher layers

Given that it is likely that at least one of the 1200 open-participation 
IETF meeting attendees -- all of whom have access to the WiFi password 
-- sometimes indulges in bad actor behavior, then it might be worth 
clarifying exactly what the incremental benefit is, in having WiFi 
encryption, if one is already using TLS liberally.

(For extra credit, it would be interesting to see where this benefit is 
already documented on the net.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: [email-masked]
Date: Wed, 12 Jul 2017 20:31:37 -0700 (PDT)

> already documented on the net.)

This occurred to me too. There was another response that actually seemed to
indicate that there was incremental benefit even when using a VPN tunnel
solution. I'd like to hear about the benefits in that case as well.

				Ned

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Jul 2017 05:55:45 +0200

> This occurred to me too. There was another response that actually
> seemed to indicate that there was incremental benefit even when using
> a VPN tunnel solution. I'd like to hear about the benefits in that
> case as well.

defense in depth.  you do what you can on every link and layer.

and that ain't good enough.  had a raspberry pi pwned last night,
within a short time of it being on the wild net.  no, we have not
had time to RE yet.

randy

---

From: joel jaeggli <[email-masked]>
Date: Wed, 12 Jul 2017 23:08:07 -0700

> encryption, if one is already using TLS liberally.

wpa2 enterprise provides forward security, merely using the same
username and password doesn't provide you with the ability to snoop
other traffic.

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Jul 2017 09:07:35 +0100

> On 12 Jul 2017, at 16:06, Randy Bush <[email-masked]> wrote:
> 

Nice idea; would force people to consciously choose it, and see the alternatives, rather than keep using it by default.

Tim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jul 2017 15:52:28 +0200

On 2017-07-12 04:55, John Levine wrote:
> ...

...overheard during breakfast at the Toronto IETF meeting: "there seems 
to be a hotel nearby called 'IETF' which has a free high-speed WLAN".

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Jul 2017 11:38:09 +0200

> Given that it is likely that at least one of the 1200
    > open-participation IETF meeting attendees -- all of whom have access to
    > the WiFi password -- sometimes indulges in bad actor behavior, then it
    > might be worth clarifying exactly what the incremental benefit is, in
    > having WiFi encryption, if one is already using TLS liberally.

My understanding is that our use of the EAP-TLS method, even with unverified
certificates, each attendee's device winds up generating a different "WEP"
key at the L2 level.  This means that attendees can not sniff each other's
traffic.
Without this, simple TCP RST attacks are trivial on TLS connections.

I don't know if we are enabling client isolation at the wifi level.
If we aren't then one could do ARP or RA impersonation, and my laptop could
convince your laptop to use me as a router, giving me access to your
unencrypted traffic.

Having said all that, I find wifi security to be generally a waste of time.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Jul 2017 09:59:47 -0400

On Thu, Jul 13, 2017 at 9:52 AM, Julian Reschke <[email-masked]>
wrote:

> ...overheard during breakfast at the Toronto IETF meeting: "there seems to
> be a hotel nearby called 'IETF' which has a free high-speed WLAN".
>
> Best regards, Julian
>

​At another meeting, some years back, before the iphone etc. "Is there some
laptop computer sales convention"

I am always amazed that the WiFi has enough bandwidth. Though I suspect we
are mostly using Web and mail rather than streaming video.

Where is the Game of Thrones fix on Sunday?​

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jul 2017 15:54:46 -0700

> defense in depth.  you do what you can on every link and layer.

The problem with a generic cliche like defense in depth is that there is 
not way to judge what's meaningful and useful and what isn't.  Obviously 
there is defense in depth if I run two anti-virus applications rather 
than only one?  Oh... there isn't?

And the idea that it's best to do what you can at every layer presumably 
means that we need to put checksums back into IPv6?

On the other hand, the basic question of whether one is /positive/ that 
all activity is protected by TLS is worth considering (though such 
coverage was the premise to my original query.)

> username and password doesn't provide you with the ability to snoop

Oh.  So a bad actor having the shared key and being able to wiretap the 
key exchange sequences at the startup of other users doesn't represent a 
threat?  (I'd heard otherwise, but admit to not having researched this 
carefully.)

And only WPA2 is supported on the IETF net(s)?

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Jul 2017 19:51:03 -0400

On Thu, Jul 13, 2017 at 6:54 PM, Dave Crocker <[email-masked]> wrote:

> there is defense in depth if I run two anti-virus applications rather than
> only one?  Oh... there isn't?
>
> all activity is protected by TLS is worth considering (though such coverage
> was the premise to my original query.)

​Defense in depth is ambiguous, I agree. But it is not bogus. End to end is
also ambiguous as ideas on where the ends are differ.

For the Mesh protocols, I use a Triple Lock approach. which I have not
finished writing up on. The idea is that we apply crypto at three different
layers to achieve different effects.

1) Transport Layer: Confidentiality gives us protection against traffic
analysis.

2) Session Layer: HTTP Web Service packets are authenticated with keys
negotiated at the application layer. This provides for transaction
isolation (no injection attacks) and authentication.

3) Data Level Signature: For non repudiation.

Although encryption is only mandated for every interaction at the first
layer, it is usually applied at 2 and often required at 3 as well.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 13 Jul 2017 17:08:07 -0700

> Oh.  So a bad actor having the shared key and being able to wiretap
> the key exchange sequences at the startup of other users doesn't
> represent a threat?  (I'd heard otherwise, but admit to not having
> researched this carefully.)
There's no pre-shared key, there's a cert from a legitimate-looking-ca
that you have to accept on faith the first time. and then the username
and password (ietf / ietf ) which you client caches presumably forever.
The handshake is eap peap or eap ttls so apart from the gratuitious TIFU
issue for most people, the mitm is going to need the cert's private key,
or get you to accept and enroll another cert.

you can examine the cert or grab a profile including it here:

https://802.1x-config.org/?idp=137&profile=101
> And only WPA2 is supported on the IETF net(s)?
we do 802.1x wpa2 ent with peap or ttls methods.