date:20200323

On Mon, Mar 23, 2020 at 19:25 Owen DeLong  wrote:

>
> I confess I haven’t investigated the implementation details, but is it
> possible for one to issue ubikeys
> to an employee in a secure way with those features disabled?
>

Yes. And changing that setup either requires a separate admin pin or wiping
the associated private key data to reconfigure. It depends on which
application/mode. FIDO I believe is most inflexible here as it can only be
short touch to activate.

I don’t use the HID keyboard mode OTP keying app/feature so I’m not
terribly familiar with that. It might be that it can be configured limited
such that N in X seconds or a replug is required (to circumvent the timer)
but I really do not know. If people are really curious I can grab a spare
key and check.  I use the CCID/smart card type modes. I do know that the
touch OTP key feature requires wiping the associated private key data, or
having it available to reprogram and change options. They’re a shared
secret mode so the yubikey authentication server has those private keys.

>
> It’s the allowing the employee to make a poor choice not necessarily
> desired by the employer thing
> that seems to me is the issue in this case.
>
>
>
> I agree that this abuse of the UBI Key is more an issue of implementation
> than the inherent nature of the
> UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other
> tokens don’t facilitate.
>
>
> That's like saying that cars are worse than bicycles, because cars
> allow you drive into things are a more dangerous speed. I mean, yes,
> but ….
>
>
> Cars are more dangerous than bicycles, but everything is a matter of
> balancing tradeoffs.
>
> In this case, I’m not sure the ubikey offers anything over the Secur-ID to
> balance that increased
> hazard.
>
> Owen
>
>
> --

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: COVID-19 vs. peering wars

2020-03-23 Thread Bradley Huffaker

Regardless of the possible gain from “solving” peering. 
You are talking about renegotiating thousands of individual 
agreements between hundreds of individual organizations, 
all while everyone is in lockdown.

or

You ask a handful of companies to make changes to their own systems. 
Good luck with the peering, I believe the bit rates have already been changed. 

Bradley 

> On Mar 21, 2020, at 4:31 AM, Matthew Petach  wrote:
> 
> 
> 
> I'm curious; 
> would people say that fixing peering inefficiencies could have 
> a bigger impact on service performance than asking that 
> Netflix, Amazon Prime, Youtube, Hulu, and other video
> streaming services cut their bit rates down?
> 
> https://www.bbc.com/news/technology-51968302 
> 
> https://arstechnica.com/tech-policy/2020/03/netflix-and-youtube-cut-streaming-quality-in-europe-to-handle-pandemic/
>  
> 
> 
> It seems that perhaps the fingers, and the regulatory
> hammer, are being pointed in the wrong direction at
> the moment.  ^_^;
> 
> Matt
> staying safely under the saran-wrap blanket for the next few weeks
> 
> 
> 
> 
> On Fri, Mar 20, 2020 at 9:31 AM Adam Thompson  > wrote:
> Every large ISP does this (or rather, doesn't) at every IX in Canada.  Bell 
> isn't unique by any stretch.
> 
> It's not in their economic interest to peer at a local IX, because from their 
> perspective, the IX takes away business (Managed L2 point-to-point circuits, 
> at the very least) from them.
> 
> Don't expect the dominant wireline ISP(s) in any region to join local IXes 
> anytime soon, sadly, no matter how much it would benefit their customers.  
> After all, the customer is always free to purchase service to the IX and join 
> the IX, right???  *grumble*
> 
> In my local case, if BellMTS joined MBIX, un-cached DNS resolution times 
> could potentially drop by 15msec.  That's HUGE.  But the end-user experience 
> is not their primary goal.  Their primary goal is profit, as always.
> 
> -Adam Thompson
>  Founding member, MBIX (once upon a time)
> 
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca 
> www.merlin.mb.ca 
> 
> > -Original Message-
> > From: NANOG mailto:nanog-boun...@nanog.org>> On 
> > Behalf Of Sadiq Saif
> > Sent: Friday, March 20, 2020 9:38 AM
> > To: nanog@nanog.org 
> > Subject: Re: COVID-19 vs. peering wars
> > 
> > On Fri, 20 Mar 2020, at 10:31, Steve Mikulasik via NANOG wrote:
> > >
> > > In Canada the CRTC really needs to get on Canadian ISPs about peering
> > > very liberally at IXs in each province. I know of one major
> > > institution right now that would have a major work from home issue
> > > resolved if one big ISP would peer with one big tier 1 in the IX they
> > > are both located at in the same province. Instead traffic needs to
> > > flow across the country or to the USA to get back to the same city.
> > 
> > **cough** Bell Canada **cough**.
> > 
> > --
> >   Sadiq Saif
> >   https://sadiqsaif.com/ 
>

Re: crypto frobs

On Mon, Mar 23, 2020 at 20:08 Michael Loftis  wrote:

>
>
> On Mon, Mar 23, 2020 at 18:50 William Herrin  wrote:
>
>> On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari  wrote:
>> > Well, yes and no. With a Yubiikey the attacker  has to be local to
>> > physically touch the button[0] - with just an SSH key, anyone who gets
>> > access to the machine can take my key and use it. This puts it in the
>> > "something you have" (not something you are) camp.
>>
>> Hi Warren,
>>
>> They're both "something you have" factors. The yubi key proves
>> possession better than the ssh key just like a long password proves
>> what-you-know better than a 4-digit PIN. But the ssh key and the yubi
>> key are still part of the same authentication factor.
>>
>>
>> > Not really -- if an attacker steals my laptop, they don't have the
>> > yubikey (unless I store it in the USB port).
>>
>> You make a habit of removing your yubi key from the laptop when nature
>> calls? No you don't.
>>
>>
>> > If they *do* steal both,
>> > they can bruteforce the SSH passphrase, but after 5 tries of guessing
>> > the Yubikey PIN it self-destructs.
>>
>> What yubikey are you talking about? I have a password protecting my
>> ssh key but the yubikeys I've used (including the FIPS version) spit
>> out a string of characters when you touch them. No pin.
>>
>
> The yubikey does many things depending on how it’s configured. None of
> mine use the touch to spit out OTP mode, that is the factory mode though
> yes. Other modes can be password protected (it uses the PIN nomenclature
> which is confusing, it definitely accepts ASCII and nay even take binary
> data as a PIN depending on mode of operation) — it can present as industry
> standard smart card ( I have one with a pin/password for code signing in
> Visual Studio f/ex...along with a backup kept locked elsewhere)
>

Replying to myself to clarify a bit... the PKI/SSL private keys are on the
Yubikey, password protected, signing is accomplished by VS passing the bits
to be signed to the smart card application on the yubikey, which requires a
password to enable/unlock. On the yubikey Depending on configuration this
is a just once operation typically. So each signing op requires a password
entry. But it could be configured diffferebtly. By only keeping the private
keys on the yubikey it’s something you have (the yubikey) and something you
know (the password)... the yubikey (barring software bugs obviously) will
not expose the private key, it only does the signing op.

That same yubikey has a separate app and trust store in OpenGPG mode, which
does signing for ssh pubkey auth, with a different private key. Same key
also does FIDO, another application with another key store.

The same key doing all that could also have a “long touch” to spit out an
OTP.

>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/
>>
> --

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

California full facilities CLEC

2020-03-23 Thread Ben Cannon

Need a small yet large COVID traffic load related favor from a California 
Full-Facilities CLEC/CLC, pls contact me off list if you can help.   Connecting 
at-risk citizens.

-Ben

Re: crypto frobs

On Mon, Mar 23, 2020 at 18:50 William Herrin  wrote:

> On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari  wrote:
> > Well, yes and no. With a Yubiikey the attacker  has to be local to
> > physically touch the button[0] - with just an SSH key, anyone who gets
> > access to the machine can take my key and use it. This puts it in the
> > "something you have" (not something you are) camp.
>
> Hi Warren,
>
> They're both "something you have" factors. The yubi key proves
> possession better than the ssh key just like a long password proves
> what-you-know better than a 4-digit PIN. But the ssh key and the yubi
> key are still part of the same authentication factor.
>
>
> > Not really -- if an attacker steals my laptop, they don't have the
> > yubikey (unless I store it in the USB port).
>
> You make a habit of removing your yubi key from the laptop when nature
> calls? No you don't.
>
>
> > If they *do* steal both,
> > they can bruteforce the SSH passphrase, but after 5 tries of guessing
> > the Yubikey PIN it self-destructs.
>
> What yubikey are you talking about? I have a password protecting my
> ssh key but the yubikeys I've used (including the FIPS version) spit
> out a string of characters when you touch them. No pin.
>

The yubikey does many things depending on how it’s configured. None of mine
use the touch to spit out OTP mode, that is the factory mode though yes.
Other modes can be password protected (it uses the PIN nomenclature which
is confusing, it definitely accepts ASCII and nay even take binary data as
a PIN depending on mode of operation) — it can present as industry standard
smart card ( I have one with a pin/password for code signing in Visual
Studio f/ex...along with a backup kept locked elsewhere)

>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>
-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

Re: South Africa On Lockdown - Coronavirus - Update!

First, for your whole message:
  s/\s+UBIKEY'/YUBIKEY/g
  s/\s+UBI/YUBI/g

thanks.

On Mon, Mar 23, 2020 at 9:24 PM Owen DeLong  wrote:
>
>
>
> On Mar 23, 2020, at 17:24 , Warren Kumari  wrote:
>
> On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong  wrote:
>
>
>
>
> On Mar 23, 2020, at 16:50 , Warren Kumari  wrote:
>
> On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha  wrote:
>
>
> Not if you run it in TOTP mode. Yubikeys support many options - if you
> choose to use a weak solution, well that's your choice...
> I guess you could ask them nicely to make a version without the
> features you don't want to use - or you could just not *use* the
> features you don't want to use….
>
>
> I confess I haven’t investigated the implementation details, but is it 
> possible for one to issue ubikeys
> to an employee in a secure way with those features disabled?

You can set the key and the authentication system to only do TOTP
(time based) and not HOTP.
you can also program the keys (I think all of their keys since their
first key) with custom firmware.

> It’s the allowing the employee to make a poor choice not necessarily desired 
> by the employer thing
> that seems to me is the issue in this case.
>

Sure limit the manner in which they can do foolish things, require
totp not hotp.
-chris

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Owen DeLong



> On Mar 23, 2020, at 17:24 , Warren Kumari  wrote:
> 
> On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong  > wrote:
>> 
>> 
>> 
>>> On Mar 23, 2020, at 16:50 , Warren Kumari  wrote:
>>> 
>>> On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha  wrote:
 
 Hi,
 
 In my experience, yubikeys are not very secure. I know of someone in my 
 team who would generate a few hundred tokens during a meeting and save the 
 output in a text file. Then they'd have a small python script which was 
 triggered by a hotkey on my macbook to push "keyboard" input. They did 
 this because the org they were working for would make you use yubikey auth 
 for pretty much everything, including updating a simple internal Jira 
 ticket.
>>> 
>>> By that argument, SecureID (and other LCD tokens) are also really
>>> insecure. When I worked at AOL we had to use them for almost
>>> everything - a bunch of people got together and put their secureIDs in
>>> a grid under a webcam. That way they didn't need  to carry them with
>>> them - when they needed a token they would open the webcam page, and
>>> know that theirs was third down, and fourth across….
>> 
>> Not actually, no…
>> 
>> SecurID and the others of its ilk have a safety feature in that the number 
>> doesn’t change that often.
>> 
>> It turns out to be awkward and time-consuming to do what is being done with 
>> the UBIKEY.
> 
> Not if you run it in TOTP mode. Yubikeys support many options - if you
> choose to use a weak solution, well that's your choice...
> I guess you could ask them nicely to make a version without the
> features you don't want to use - or you could just not *use* the
> features you don't want to use….
> 

I confess I haven’t investigated the implementation details, but is it possible 
for one to issue ubikeys
to an employee in a secure way with those features disabled?

It’s the allowing the employee to make a poor choice not necessarily desired by 
the employer thing
that seems to me is the issue in this case.

> 
>> 
>> I agree that this abuse of the UBI Key is more an issue of implementation 
>> than the inherent nature of the
>> UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other 
>> tokens don’t facilitate.
> 
> That's like saying that cars are worse than bicycles, because cars
> allow you drive into things are a more dangerous speed. I mean, yes,
> but ….

Cars are more dangerous than bicycles, but everything is a matter of balancing 
tradeoffs.

In this case, I’m not sure the ubikey offers anything over the Secur-ID to 
balance that increased
hazard.

Owen

Re: crypto frobs

2020-03-23 Thread William Herrin

On Mon, Mar 23, 2020 at 5:16 PM Warren Kumari  wrote:
> Well, yes and no. With a Yubiikey the attacker  has to be local to
> physically touch the button[0] - with just an SSH key, anyone who gets
> access to the machine can take my key and use it. This puts it in the
> "something you have" (not something you are) camp.

Hi Warren,

They're both "something you have" factors. The yubi key proves
possession better than the ssh key just like a long password proves
what-you-know better than a 4-digit PIN. But the ssh key and the yubi
key are still part of the same authentication factor.

> Not really -- if an attacker steals my laptop, they don't have the
> yubikey (unless I store it in the USB port).

You make a habit of removing your yubi key from the laptop when nature
calls? No you don't.

> If they *do* steal both,
> they can bruteforce the SSH passphrase, but after 5 tries of guessing
> the Yubikey PIN it self-destructs.

What yubikey are you talking about? I have a password protecting my
ssh key but the yubikeys I've used (including the FIPS version) spit
out a string of characters when you touch them. No pin.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Warren Kumari

On Mon, Mar 23, 2020 at 8:03 PM Owen DeLong  wrote:
>
>
>
> > On Mar 23, 2020, at 16:50 , Warren Kumari  wrote:
> >
> > On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha  wrote:
> >>
> >> Hi,
> >>
> >> In my experience, yubikeys are not very secure. I know of someone in my 
> >> team who would generate a few hundred tokens during a meeting and save the 
> >> output in a text file. Then they'd have a small python script which was 
> >> triggered by a hotkey on my macbook to push "keyboard" input. They did 
> >> this because the org they were working for would make you use yubikey auth 
> >> for pretty much everything, including updating a simple internal Jira 
> >> ticket.
> >
> > By that argument, SecureID (and other LCD tokens) are also really
> > insecure. When I worked at AOL we had to use them for almost
> > everything - a bunch of people got together and put their secureIDs in
> > a grid under a webcam. That way they didn't need  to carry them with
> > them - when they needed a token they would open the webcam page, and
> > know that theirs was third down, and fourth across….
>
> Not actually, no…
>
> SecurID and the others of its ilk have a safety feature in that the number 
> doesn’t change that often.
>
> It turns out to be awkward and time-consuming to do what is being done with 
> the UBIKEY.

Not if you run it in TOTP mode. Yubikeys support many options - if you
choose to use a weak solution, well that's your choice...
I guess you could ask them nicely to make a version without the
features you don't want to use - or you could just not *use* the
features you don't want to use


>
> I agree that this abuse of the UBI Key is more an issue of implementation 
> than the inherent nature of the
> UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other 
> tokens don’t facilitate.

That's like saying that cars are worse than bicycles, because cars
allow you drive into things are a more dangerous speed. I mean, yes,
but 

W
>
> Owen
>
>


-- 
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

Re: crypto frobs

2020-03-23 Thread Warren Kumari

On Mon, Mar 23, 2020 at 7:57 PM William Herrin  wrote:
>
> > On 3/23/20 3:53 PM, Sabri Berisha wrote:
> > In my experience, yubikeys are not very secure. I know of someone in my 
> > team who would generate a few hundred tokens during a meeting and save the 
> > output in a text file. Then they'd have a small python script which was 
> > triggered by a hotkey on my macbook to push "keyboard" input. They did this 
> > because the org they were working for would make you use yubikey auth for 
> > pretty much everything, including updating a simple internal Jira ticket.
>
> Meh. Here's a better example of bad:
>
> SSH Key Auth + Yubi key.
>
> This isn't two-factor authentication folks, it's just 1-factor: what
> you have.

Well, yes and no. With a Yubiikey the attacker  has to be local to
physically touch the button[0] - with just an SSH key, anyone who gets
access to the machine can take my key and use it. This puts it in the
"something you have" (not something you are) camp.

> You have an ssh private key. You have a yubi key. Same
> factor. Either one proves you have possession of something only the
> user should have. Proving two does not appreciably change the
> probability that you are you.
>
> For two factor auth, you actually have to use an additional factor.
> Something from the what you know factor (e.g. a password) or the what
> you are factor (e.g. a fingerprint).
>
> Just like a password and a pin isn't two factor. It's exactly the same
> as having a single longer password and subject to the same general
> types of compromise.

Not really -- if an attacker steals my laptop, they don't have the
yubikey (unless I store it in the USB port). If they *do* steal both,
they can bruteforce the SSH passphrase, but after 5 tries of guessing
the Yubikey PIN it self-destructs.
This makes it very different to a longer passphrase.

W
[0]: Yes, obviously an attacker who has root on a machine could trojan
the ssh binary, change the OS to make it play Nyancat through the
speaker, etc... but that's true for any solution...

>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

-- 
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

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Owen DeLong




> On Mar 23, 2020, at 16:50 , Warren Kumari  wrote:
> 
> On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha  wrote:
>> 
>> Hi,
>> 
>> In my experience, yubikeys are not very secure. I know of someone in my team 
>> who would generate a few hundred tokens during a meeting and save the output 
>> in a text file. Then they'd have a small python script which was triggered 
>> by a hotkey on my macbook to push "keyboard" input. They did this because 
>> the org they were working for would make you use yubikey auth for pretty 
>> much everything, including updating a simple internal Jira ticket.
> 
> By that argument, SecureID (and other LCD tokens) are also really
> insecure. When I worked at AOL we had to use them for almost
> everything - a bunch of people got together and put their secureIDs in
> a grid under a webcam. That way they didn't need  to carry them with
> them - when they needed a token they would open the webcam page, and
> know that theirs was third down, and fourth across….

Not actually, no…

SecurID and the others of its ilk have a safety feature in that the number 
doesn’t change that often.

It turns out to be awkward and time-consuming to do what is being done with the 
UBIKEY.

I agree that this abuse of the UBI Key is more an issue of implementation than 
the inherent nature of the
UBIKEY, but the UBIKEY does allow this kind of abuse in ways that other tokens 
don’t facilitate.

Owen

Re: crypto frobs

2020-03-23 Thread William Herrin

> On 3/23/20 3:53 PM, Sabri Berisha wrote:
> In my experience, yubikeys are not very secure. I know of someone in my team 
> who would generate a few hundred tokens during a meeting and save the output 
> in a text file. Then they'd have a small python script which was triggered by 
> a hotkey on my macbook to push "keyboard" input. They did this because the 
> org they were working for would make you use yubikey auth for pretty much 
> everything, including updating a simple internal Jira ticket.

Meh. Here's a better example of bad:

SSH Key Auth + Yubi key.

This isn't two-factor authentication folks, it's just 1-factor: what
you have. You have an ssh private key. You have a yubi key. Same
factor. Either one proves you have possession of something only the
user should have. Proving two does not appreciably change the
probability that you are you.

For two factor auth, you actually have to use an additional factor.
Something from the what you know factor (e.g. a password) or the what
you are factor (e.g. a fingerprint).

Just like a password and a pin isn't two factor. It's exactly the same
as having a single longer password and subject to the same general
types of compromise.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Warren Kumari

On Mon, Mar 23, 2020 at 6:53 PM Sabri Berisha  wrote:
>
> Hi,
>
> In my experience, yubikeys are not very secure. I know of someone in my team 
> who would generate a few hundred tokens during a meeting and save the output 
> in a text file. Then they'd have a small python script which was triggered by 
> a hotkey on my macbook to push "keyboard" input. They did this because the 
> org they were working for would make you use yubikey auth for pretty much 
> everything, including updating a simple internal Jira ticket.

By that argument, SecureID (and other LCD tokens) are also really
insecure. When I worked at AOL we had to use them for almost
everything - a bunch of people got together and put their secureIDs in
a grid under a webcam. That way they didn't need  to carry them with
them - when they needed a token they would open the webcam page, and
know that theirs was third down, and fourth across

W

>
> Thanks,
>
> Sabri
>
>
> - On Mar 23, 2020, at 1:26 PM, Eric Tykwinski  
> wrote:
>
> I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work 
> with Windows Hello.
> Might be something I was doing wrong...
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
>
> On Mar 23, 2020, at 4:21 PM, Peter Beckman  wrote:
>
> Software-based TOTP offer more security than no one-time passwords, but
> admittedly less than the physical tokens. Google Authenticator, Authy,
> 1Password, LastPass all support TOTP.
>
> On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
>
> I dont know where are people about supporting VPN and one-time passwords on 
> tokens.
>
> At my work place a few people dont have tokens (OTP - One Time PAsswords).  
> The reserve of these tokens has been exhausted.  NEw ones are being on order. 
>  Until then some people cant get on VPN.
>
> Some people forgot their token on their desk and had to to travel to office 
> to get it, a thing not good to do to go to office now.
>
> Some (not sure) might have issues with syncing these devices.  An OTP token 
> has a certain skew about clock, and a battery that lasts long. Hopefully, 
> one's token has been synchronised recently and the battery is new.  The 
> length of time one cant go to office might be anywhere between 21 days 
> (announced) and 2 months (experrience eg in Wuhan still closed).  Some times 
> the synching of clock can be performed remotely, and some 'coin' batteries 
> can be replaced by the person with skill and tools, could be extracted from a 
> quartz watch for example.
>
> An OTP device can be of many kinds.  Some people keep OTPs on paper (I did 
> some time ago).  Some OTP devices are like Japanese 'tamaguchi' format, 
> others like a credit card format.
>
> Alex, LF/HF 3
>
> Le 23/03/2020 à 20:47, Mark Tinka a écrit :
>
> On 23/Mar/20 21:20, Peter Beckman wrote:
>
> But also:
>
> "The categories of people who will be exempted from this lockdown
>  are... those involved in the production, distribution and supply
>  of... telecommunications services"
>
> 
> https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/
> I think most anyone on this list could be considered exempt.
> I do hope the same will be true should our respective local and national
> governments take similar action.
>
> Yes, a number of "essential services" have been identified as needing to
> continue to operate under special dispensation during the lockdown, and
> telecoms falls within that.
> The details of the implementation of the dispensation may be nuanced.
> Experience will tell us more in the coming days.
> Mark.
>
>
>
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---
>
>
>


-- 
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

Re: crypto frobs

On Mon, Mar 23, 2020 at 7:34 PM George Michaelson  wrote:
>
> I don't see SKEY style OTP lists as inherently bad. "its how you do
> it" which concerns me, not that it is done.
>

trust your users to always ALWAYS find the worst way to use the product.

Note the label on bleach bottles: "Do not lick"
or coffee cups: "Caution: contents hot"
:( I agree that 'consenting adults' can do this properly, it's when people
really want to find their own way thatwe end having this dicsussion :(


> -G
>
> On Tue, Mar 24, 2020 at 9:33 AM Christopher Morrow
>  wrote:
> >
> > On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas  wrote:
> > >
> > > On 3/23/20 3:53 PM, Sabri Berisha wrote:
> > >
> > > Hi,
> > >
> > > In my experience, yubikeys are not very secure. I know of someone in my 
> > > team who would generate a few hundred tokens during a meeting and save 
> > > the output in a text file. Then they'd have a small python script which 
> > > was triggered by a hotkey on my macbook to push "keyboard" input. They 
> > > did this because the org they were working for would make you use yubikey 
> > > auth for pretty much everything, including updating a simple internal 
> > > Jira ticket.
> > >
> >
> > this is not: "yubikey is bad" as much as: "The user using the yubikey is 
> > bad"
> > Admittedly perhaps: "every time new token" sucks, and that's what (I
> > think michael thomas is saying below), but certainly the yubikey could
> > have been used for TOTP instead of HOTP and the user in question would
> > have been out of luck, right? :)
> >
> > Almost all security 'features' are a trade-off between: "get stuff
> > done" and "get stuff done with an extra hop", making the 'extra hop'
> > as simple and natural as possible makes people less likely to do dumb
> > things like:
> >   1) pregen a crapload of tokens, store them on their probably
> > compromised laptop...
> >   2) aim a webcam at their rsa token and watch the change remotely
> >   3) hot-dog and sipping-bird toy to touch the thingy on their yubikey
> > token every X seconds...
> >
> > >
> > > One of the things that got lost in the Webauthn stuff is that passwords 
> > > per se are not bad. It's passwords being sent over the wire. In 
> > > combination with reuse, that is the actual problem. Webauthn supposedly 
> > > allows use of passwords to unlock a local credential store, but it is so 
> > > heavily focused dongles that it's really hard to figure out for a normal 
> > > website that just want to get rid of the burden of  remote passwords.
> > >
> > > Mike

Re: South Africa On Lockdown - Coronavirus - Update!

On Mon, Mar 23, 2020 at 4:53 PM Sabri Berisha  wrote:
>
> Hi,
>
> In my experience, yubikeys are not very secure. I know of someone in my team 
> who would generate a few hundred tokens during a meeting and save the output 
> in a text file. Then they'd have a small python script which was triggered by 
> a hotkey on my macbook to push "keyboard" input. They did this because the 
> org they were working for would make you use yubikey auth for pretty much 
> everything, including updating a simple internal Jira ticket.
>
> Thanks,

This is an artifact of a poor implementation, not of a yubikey or any
other security.  Yubikeys support MANY methods of authentication.  I
have a number of them, a couple of them are setup for TOTP (using
yubico authenticator), FIDO (native), and use the GPG functionality
for ssh public key auth via agent.  Pre-generating or replaying will
not work with any of those methods.

So saying "Yubikeys are not very secure" is very incorrect.  The
specific deployment decisions weren't great in your specific case.
Any OTP system based on incrementing counters could be abused in this
manner if the OTP keys can be generated rapidly and saved.  TOTP is
the common method for solving this with 2FA.  Yubikeys also support a
number of challenge/response type authentications (which is
effectively what my GPG setup does, and what FIDO sort of does)

Re: crypto frobs

2020-03-23 Thread George Michaelson

I don't see SKEY style OTP lists as inherently bad. "its how you do
it" which concerns me, not that it is done.

-G

On Tue, Mar 24, 2020 at 9:33 AM Christopher Morrow
 wrote:
>
> On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas  wrote:
> >
> > On 3/23/20 3:53 PM, Sabri Berisha wrote:
> >
> > Hi,
> >
> > In my experience, yubikeys are not very secure. I know of someone in my 
> > team who would generate a few hundred tokens during a meeting and save the 
> > output in a text file. Then they'd have a small python script which was 
> > triggered by a hotkey on my macbook to push "keyboard" input. They did this 
> > because the org they were working for would make you use yubikey auth for 
> > pretty much everything, including updating a simple internal Jira ticket.
> >
>
> this is not: "yubikey is bad" as much as: "The user using the yubikey is bad"
> Admittedly perhaps: "every time new token" sucks, and that's what (I
> think michael thomas is saying below), but certainly the yubikey could
> have been used for TOTP instead of HOTP and the user in question would
> have been out of luck, right? :)
>
> Almost all security 'features' are a trade-off between: "get stuff
> done" and "get stuff done with an extra hop", making the 'extra hop'
> as simple and natural as possible makes people less likely to do dumb
> things like:
>   1) pregen a crapload of tokens, store them on their probably
> compromised laptop...
>   2) aim a webcam at their rsa token and watch the change remotely
>   3) hot-dog and sipping-bird toy to touch the thingy on their yubikey
> token every X seconds...
>
> >
> > One of the things that got lost in the Webauthn stuff is that passwords per 
> > se are not bad. It's passwords being sent over the wire. In combination 
> > with reuse, that is the actual problem. Webauthn supposedly allows use of 
> > passwords to unlock a local credential store, but it is so heavily focused 
> > dongles that it's really hard to figure out for a normal website that just 
> > want to get rid of the burden of  remote passwords.
> >
> > Mike

Re: crypto frobs

On Mon, Mar 23, 2020 at 7:00 PM Michael Thomas  wrote:
>
> On 3/23/20 3:53 PM, Sabri Berisha wrote:
>
> Hi,
>
> In my experience, yubikeys are not very secure. I know of someone in my team 
> who would generate a few hundred tokens during a meeting and save the output 
> in a text file. Then they'd have a small python script which was triggered by 
> a hotkey on my macbook to push "keyboard" input. They did this because the 
> org they were working for would make you use yubikey auth for pretty much 
> everything, including updating a simple internal Jira ticket.
>

this is not: "yubikey is bad" as much as: "The user using the yubikey is bad"
Admittedly perhaps: "every time new token" sucks, and that's what (I
think michael thomas is saying below), but certainly the yubikey could
have been used for TOTP instead of HOTP and the user in question would
have been out of luck, right? :)

Almost all security 'features' are a trade-off between: "get stuff
done" and "get stuff done with an extra hop", making the 'extra hop'
as simple and natural as possible makes people less likely to do dumb
things like:
  1) pregen a crapload of tokens, store them on their probably
compromised laptop...
  2) aim a webcam at their rsa token and watch the change remotely
  3) hot-dog and sipping-bird toy to touch the thingy on their yubikey
token every X seconds...

>
> One of the things that got lost in the Webauthn stuff is that passwords per 
> se are not bad. It's passwords being sent over the wire. In combination with 
> reuse, that is the actual problem. Webauthn supposedly allows use of 
> passwords to unlock a local credential store, but it is so heavily focused 
> dongles that it's really hard to figure out for a normal website that just 
> want to get rid of the burden of  remote passwords.
>
> Mike

crypto frobs

2020-03-23 Thread Michael Thomas


On 3/23/20 3:53 PM, Sabri Berisha wrote:

Hi,

In my experience, yubikeys are not very secure. I know of someone in 
my team who would generate a few hundred tokens during a meeting and 
save the output in a text file. Then they'd have a small python script 
which was triggered by a hotkey on my macbook to push "keyboard" 
input. They did this because the org they were working for would make 
you use yubikey auth for pretty much everything, including updating a 
simple internal Jira ticket.



One of the things that got lost in the Webauthn stuff is that passwords 
per se are not bad. It's passwords being sent over the wire. In 
combination with reuse, that is the actual problem. Webauthn supposedly 
allows use of passwords to unlock a local credential store, but it is so 
heavily focused dongles that it's really hard to figure out for a normal 
website that just want to get rid of the burden of  remote passwords.


Mike

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Sabri Berisha

Hi, 

In my experience, yubikeys are not very secure. I know of someone in my team 
who would generate a few hundred tokens during a meeting and save the output in 
a text file. Then they'd have a small python script which was triggered by a 
hotkey on my macbook to push "keyboard" input. They did this because the org 
they were working for would make you use yubikey auth for pretty much 
everything, including updating a simple internal Jira ticket. 

Thanks, 

Sabri 

- On Mar 23, 2020, at 1:26 PM, Eric Tykwinski  
wrote: 

> I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work
> with Windows Hello.
> Might be something I was doing wrong...

> Sincerely,

> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300

>> On Mar 23, 2020, at 4:21 PM, Peter Beckman < [ mailto:beck...@angryox.com |
>> beck...@angryox.com ] > wrote:

>> Software-based TOTP offer more security than no one-time passwords, but
>> admittedly less than the physical tokens. Google Authenticator, Authy,
>> 1Password, LastPass all support TOTP.

>> On Mon, 23 Mar 2020, Alexandre Petrescu wrote:

>>> I dont know where are people about supporting VPN and one-time passwords on
>>> tokens.

>>> At my work place a few people dont have tokens (OTP - One Time PAsswords). 
>>> The
>>> reserve of these tokens has been exhausted. NEw ones are being on order. 
>>> Until
>>> then some people cant get on VPN.

>>> Some people forgot their token on their desk and had to to travel to office 
>>> to
>>> get it, a thing not good to do to go to office now.

>>> Some (not sure) might have issues with syncing these devices. An OTP token 
>>> has a
>>> certain skew about clock, and a battery that lasts long. Hopefully, one's 
>>> token
>>> has been synchronised recently and the battery is new. The length of time 
>>> one
>>> cant go to office might be anywhere between 21 days (announced) and 2 months
>>> (experrience eg in Wuhan still closed). Some times the synching of clock 
>>> can be
>>> performed remotely, and some 'coin' batteries can be replaced by the person
>>> with skill and tools, could be extracted from a quartz watch for example.

>>> An OTP device can be of many kinds. Some people keep OTPs on paper (I did 
>>> some
>>> time ago). Some OTP devices are like Japanese 'tamaguchi' format, others 
>>> like a
>>> credit card format.

>>> Alex, LF/HF 3

>>> Le 23/03/2020 à 20:47, Mark Tinka a écrit :

 On 23/Mar/20 21:20, Peter Beckman wrote:

> But also:

> "The categories of people who will be exempted from this lockdown
> are... those involved in the production, distribution and supply
> of... telecommunications services"

> [
> https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/
> |
> https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/
> ]
> I think most anyone on this list could be considered exempt.
> I do hope the same will be true should our respective local and national
> governments take similar action.

 Yes, a number of "essential services" have been identified as needing to
 continue to operate under special dispensation during the lockdown, and
 telecoms falls within that.
 The details of the implementation of the dispensation may be nuanced.
 Experience will tell us more in the coming days.
 Mark.

>> ---
>> Peter Beckman Internet Guy
>> [ mailto:beck...@angryox.com | beck...@angryox.com ] [ 
>> http://www.angryox.com/ |
>> http://www.angryox.com/ ]
>> ---

Re: South Africa On Lockdown - Coronavirus - Update!

how did 'africa on lockdown' get sidetracked into OTP conversations?

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Eric Tykwinski

I guess I wasn’t as detailed as should be, multi factor authentication should 
hopefully have 1 standard which will work for everything.  So we have an app on 
our phone to authenticate after a username/password which give a 6 digit key, 
or we use a hardware based key to sign a OTP.  Really either doesn’t matter, 
but trying to get endu sers to switch between each for every login is going to 
hamper acceptance in the large scale.

MailOps, would probably the best example, as the spam is generated simply from 
usually not having anything because it’s just too difficult to implement.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Mar 23, 2020, at 6:02 PM, Tom Beecher  wrote:
> 
> I see no possible future outcome in which "one simple authentication 
> mechanism" could ever be remotely close to reasonably secure. 
> 
> 
> 
> On Mon, Mar 23, 2020 at 5:57 PM Eric Tykwinski  > wrote:
> I think that’s the major sticky point, I would hope we could all agree on one 
> thing, but that also leaves one entry point of failure.  Hopefully we can all 
> agree that FIDO2, OAUTH2, et al, with be a winner in the long run so 
> everything can just use one simple authentication mechanism.
> 
> Sincerely,
> 
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> 
>> On Mar 23, 2020, at 5:23 PM, Mark Tinka > > wrote:
>> 
>> 
>> 
>> On 23/Mar/20 22:39, Keith Medcalf wrote:
>> 
>>> Hardware tokens are nothing more than dedicated hardware TOTP devices with 
>>> perhaps a few additional parameters programmed at manufacturing time.  
>>> Example, RSAID keyfobs are nothing more than TOTP generators with 
>>> manufacturer programmed secrets and dedicated clock and display hardware 
>>> with no external interface which permits access to the secret.
>> 
>> For some of my banks, OTP tokens are issued via their device apps. I
>> used to have physical key fobs for that; those are now gone.
>> 
>> Admittedly, not all of my banks have made the transition. On the other
>> hand, many of the banks have moved on to support Face ID and QR code
>> verification via device apps.
>> 
>> Not specific to VPN access management, but in the same vein.
>> 
>> Mark.
>

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Michael Thomas

I don't know about Fido, but i've been making that point about Oauth for 
a very long time. As a browser mechanism which implements a sandbox it's 
fine. But when you have apps that can reach out of the sandbox it is 
definitely not fine.


Mike

On 3/23/20 2:59 PM, Keith Medcalf wrote:

Both Fido and OAuth2 are inherently insecure.

While they may be better than nothing at all, they are only very slightly 
better than proper password selection and management.

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Tom Beecher

I see no possible future outcome in which "one simple authentication
mechanism" could ever be remotely close to reasonably secure.



On Mon, Mar 23, 2020 at 5:57 PM Eric Tykwinski 
wrote:

> I think that’s the major sticky point, I would hope we could all agree on
> one thing, but that also leaves one entry point of failure.  Hopefully we
> can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run
> so everything can just use one simple authentication mechanism.
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
>
> On Mar 23, 2020, at 5:23 PM, Mark Tinka  wrote:
>
>
>
> On 23/Mar/20 22:39, Keith Medcalf wrote:
>
> Hardware tokens are nothing more than dedicated hardware TOTP devices with
> perhaps a few additional parameters programmed at manufacturing time.
> Example, RSAID keyfobs are nothing more than TOTP generators with
> manufacturer programmed secrets and dedicated clock and display hardware
> with no external interface which permits access to the secret.
>
>
> For some of my banks, OTP tokens are issued via their device apps. I
> used to have physical key fobs for that; those are now gone.
>
> Admittedly, not all of my banks have made the transition. On the other
> hand, many of the banks have moved on to support Face ID and QR code
> verification via device apps.
>
> Not specific to VPN access management, but in the same vein.
>
> Mark.
>
>
>

RE: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Keith Medcalf



Both Fido and OAuth2 are inherently insecure.

While they may be better than nothing at all, they are only very slightly 
better than proper password selection and management.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Eric Tykwinski
>Sent: Monday, 23 March, 2020 15:55
>To: Mark Tinka 
>Cc: nanog@nanog.org
>Subject: Re: South Africa On Lockdown - Coronavirus - Update!
>
>I think that’s the major sticky point, I would hope we could all agree on
>one thing, but that also leaves one entry point of failure.  Hopefully we
>can all agree that FIDO2, OAUTH2, et al, with be a winner in the long run
>so everything can just use one simple authentication mechanism.
>
>
>Sincerely,
>
>Eric Tykwinski
>TrueNet, Inc.
>P: 610-429-8300
>
>
>   On Mar 23, 2020, at 5:23 PM, Mark Tinka  > wrote:
>
>
>
>   On 23/Mar/20 22:39, Keith Medcalf wrote:
>
>
>
>   Hardware tokens are nothing more than dedicated hardware TOTP
>devices with perhaps a few additional parameters programmed at
>manufacturing time.  Example, RSAID keyfobs are nothing more than TOTP
>generators with manufacturer programmed secrets and dedicated clock and
>display hardware with no external interface which permits access to the
>secret.
>
>
>
>   For some of my banks, OTP tokens are issued via their device apps. I
>   used to have physical key fobs for that; those are now gone.
>
>   Admittedly, not all of my banks have made the transition. On the
>other
>   hand, many of the banks have moved on to support Face ID and QR code
>   verification via device apps.
>
>   Not specific to VPN access management, but in the same vein.
>
>   Mark.
>
>

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Eric Tykwinski

I think that’s the major sticky point, I would hope we could all agree on one 
thing, but that also leaves one entry point of failure.  Hopefully we can all 
agree that FIDO2, OAUTH2, et al, with be a winner in the long run so everything 
can just use one simple authentication mechanism.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Mar 23, 2020, at 5:23 PM, Mark Tinka  wrote:
> 
> 
> 
> On 23/Mar/20 22:39, Keith Medcalf wrote:
> 
>> Hardware tokens are nothing more than dedicated hardware TOTP devices with 
>> perhaps a few additional parameters programmed at manufacturing time.  
>> Example, RSAID keyfobs are nothing more than TOTP generators with 
>> manufacturer programmed secrets and dedicated clock and display hardware 
>> with no external interface which permits access to the secret.
> 
> For some of my banks, OTP tokens are issued via their device apps. I
> used to have physical key fobs for that; those are now gone.
> 
> Admittedly, not all of my banks have made the transition. On the other
> hand, many of the banks have moved on to support Face ID and QR code
> verification via device apps.
> 
> Not specific to VPN access management, but in the same vein.
> 
> Mark.

Re: Internet operations during pandemics

On Thu, Mar 19, 2020 at 1:47 PM Seth Mattinen  wrote:
>
> On 3/19/20 9:51 AM, Christopher Morrow wrote:
> > During this time, however, 'work from home' technology hasn't really
> > progressed along the same path, has it? So, "get to the vpn" is still
> > largely a process of getting packets across the wide internet and to
> > small locations (your enterprise), there's little relief in site for
> > that model:(
>
>
> IMO that's where local peering comes in, but the big ISPs like AT and
> Charter/Spectrum (the two national providers in my area) are loathe to
> peer anywhere except a few big central locations, if at all. It's not a

peer or transit? or did you mean crossing between att/comcast ?
(assume they are SFP not customer/transit)

> technical problem (i.e. Charter has a 10% utilized 10Ge and unused 1Ge
> switch trunks in my facility as custs cancel due to he.net moving in),
> it's a policy problem.

I expect charter (in your example) would happily sign you up to a 1g
or 10g port that's vacated there, right?
the difference/question is about 'settlement free' or 'less than
standard transit' access?

> So we end up with setups like colo customers not using Charter at the
> colo because they can get better pricing options, then suddenly they
> have remote workers on high latency cable connections at home since for
> that home cable connection to talk to the colo server traffic has to
> take some crazy long out of state boomerang path that a simple peering
> connection would solve.

yea, this is exactly the sort of problem I was thinking about...
I wonder if enterprises pulling their VPN from 'on prem' to 'deploy in
"equinix" (pick your xerox copy of same)' with a private network
backhaul to their prem(s) might actually make things better? Might
that allow them to deploy more servers more easily? (ship to "equinix"
ask remote hands to deploy...)

That and some reasonable answer for 'connect to the IX, get some local
peering to networks where your employees are...' etc.

Re: South Africa On Lockdown - Coronavirus - Update!

On 23/Mar/20 22:39, Keith Medcalf wrote:

> Hardware tokens are nothing more than dedicated hardware TOTP devices with 
> perhaps a few additional parameters programmed at manufacturing time.  
> Example, RSAID keyfobs are nothing more than TOTP generators with 
> manufacturer programmed secrets and dedicated clock and display hardware with 
> no external interface which permits access to the secret.

For some of my banks, OTP tokens are issued via their device apps. I
used to have physical key fobs for that; those are now gone.

Admittedly, not all of my banks have made the transition. On the other
hand, many of the banks have moved on to support Face ID and QR code
verification via device apps.

Not specific to VPN access management, but in the same vein.

Mark.

Re: Sunday traffic curiosity

2020-03-23 Thread Owen DeLong

> On Mar 23, 2020, at 10:14 , Mark Tinka  wrote:
> 
> 
> 
> On 23/Mar/20 05:51, Owen DeLong wrote:
> 
> 
>> How do you see that happening? Are people going to stop wanting to watch 
>> live,
>> or are teams going to somehow play asynchronously (e.g. Lakers vs. Celtics,
>> the Lakers play on November 5 at 6 PM and the Celtics play on November 8
>> at 11 AM)?
>> 
>> Further, it would be more accurate to say that events with large live 
>> audiences
>> are the only thing propping up the “old economy” and sport is probably by far
>> the largest current application of live streaming.
> 
> I'll admit, this is not an easy one to solve.
> 
> The problem you have is the kids who are driving the new economy have little 
> to no interest in live sport. Old timers like ourselves still like watching 
> live sport, and even better, betting on it for those who consider that an 
> extra sport of sport. The kids are not into all of that, and despite the 
> growth of online sporting conventions (eSports, Fortnite tournaments, Twitch 
> binging, e.t.c.), it doesn't even register as a rounding-error on the balance 
> sheets of the traditional sports establishment. To you pysch. majors, that 
> means, "We - the old guard - don't care about any of that :-)”.

That hasn’t been my observation at any of the local sports bars. I actually 
have little to no interest in live sport (except maybe the occasional curling 
match, yeah, I’m not just old, I’m odd).

Live sport seems quite popular among kids and millennials, at least in the US.

> Linear TV networks know that most homes moving to VoD would prefer a 
> sports-only package, so that they can pick that up from them and keep movies 
> and series on VoD. However, the linear TV networks are leveraging that to 
> keep pushing their traditional bouquets because then they have the 
> justification to "charge that little bit extra" in order to deliver all the 
> other content that sits side-by-side with sports.

Personally, I wish I could stop paying the “fee for access to local sports” 
that my linear provider charges every month. Nonetheless, the younger people 
around me supposedly driving this new economy seem very focused on their love 
of live sports.

> As I've been saying before, the Coronavirus has amplified and accelerated the 
> realization that the old economy will not survive in this new digital era. As 
> this applies to sport, Formula One have cancelled a heap of grand prix 
> weekends this season, but this has forced them to, for the first time, hold 
> eSports options, just this week:
> 
> 
> https://www.grandprix247.com/2020/03/23/zhou-wins-virtual-bahrain-grand-prix/ 
> 
> 
> Is that a sign of things to come, yes and no. "No" in that there is simply 
> too much money with the traditional setup to put aside for the bigger 
> picture, but "Yes" in that during times like these, there might be way for 
> folk to get their fix, unless you are a  purist. But even then, how long can 
> you hold out for if another pandemic in 20 years loses us 2 whole years?

Well, for the moment, live sports aren’t happening, at least locally, so how to 
televise them isn’t exactly an issue. I don’t think eSports will replace 
traditional sports, I think that for now, the sports organizations facing a 
sudden and dramatic loss of revenue and progressively more distressed fans are 
grasping at straws to find ways to keep their fans engaged, hoping for a 
near-term return to normal revenue activities. Remains to be seen how well that 
will work.

> One could speak of hybrid solutions where you watch linear TV, but then 
> engage with the match/program online. In 2013, I saw a number of equipment 
> vendors developing walled-garden solutions around this, and it was great. But 
> as we all know, the kids gravitate to simpler solutions that offer obvious 
> value, are downloadable from a public market store, and cost zero. So now, 
> watching anything on TV means engaging via Twitter, not via some 
> walled-garden app only open to a few, ships with a price tag, and crashes 
> more than it is usable.

These have already been tried in a variety of ways, usually with limited 
success.

This idea that things can cost zero is the most frustrating part. I’m so tired 
of not being able to buy apps instead of rent them. I’m fed up to here with 
apps that come with ridiculous loads of advertising.
This shift from an ownership economy to a rental economy is terrible and I wish 
that we could somehow educate the kids on how much more it actually costs them.

Possibly the worst artifact is the “If you’re not paying, you’re the product” 
and the number of millennials that view the surveillance economy with a kind of 
“Yeah, so what? Privacy is so 1990.” attitude.

> Where all the VoD providers are letting linear TV networks keep running away 
> with this model is by all of them chasing us to give them our US$10/month for

RE: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Keith Medcalf

On Monday, 23 March, 2020 14:21, Peter Beckman  wrote:

>Software-based TOTP offer more security than no one-time passwords, but
>admittedly less than the physical tokens. Google Authenticator, Authy,
>1Password, LastPass all support TOTP.

Hardware tokens are nothing more than dedicated hardware TOTP devices with 
perhaps a few additional parameters programmed at manufacturing time.  Example, 
RSAID keyfobs are nothing more than TOTP generators with manufacturer 
programmed secrets and dedicated clock and display hardware with no external 
interface which permits access to the secret.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Eric Tykwinski

I’ve already been playing with YubiKeys, but sadly Google Titan wouldn't work 
with Windows Hello.  
Might be something I was doing wrong...

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Mar 23, 2020, at 4:21 PM, Peter Beckman  wrote:
> 
> Software-based TOTP offer more security than no one-time passwords, but
> admittedly less than the physical tokens. Google Authenticator, Authy,
> 1Password, LastPass all support TOTP.
> 
> On Mon, 23 Mar 2020, Alexandre Petrescu wrote:
> 
>> I dont know where are people about supporting VPN and one-time passwords on 
>> tokens.
>> 
>> At my work place a few people dont have tokens (OTP - One Time PAsswords).  
>> The reserve of these tokens has been exhausted.  NEw ones are being on 
>> order.  Until then some people cant get on VPN.
>> 
>> Some people forgot their token on their desk and had to to travel to office 
>> to get it, a thing not good to do to go to office now.
>> 
>> Some (not sure) might have issues with syncing these devices.  An OTP token 
>> has a certain skew about clock, and a battery that lasts long. Hopefully, 
>> one's token has been synchronised recently and the battery is new.  The 
>> length of time one cant go to office might be anywhere between 21 days 
>> (announced) and 2 months (experrience eg in Wuhan still closed).  Some times 
>> the synching of clock can be performed remotely, and some 'coin' batteries 
>> can be replaced by the person with skill and tools, could be extracted from 
>> a quartz watch for example.
>> 
>> An OTP device can be of many kinds.  Some people keep OTPs on paper (I did 
>> some time ago).  Some OTP devices are like Japanese 'tamaguchi' format, 
>> others like a credit card format.
>> 
>> Alex, LF/HF 3
>> 
>> Le 23/03/2020 à 20:47, Mark Tinka a écrit :
>>> On 23/Mar/20 21:20, Peter Beckman wrote:
 But also:
 
 "The categories of people who will be exempted from this lockdown
  are... those involved in the production, distribution and supply
  of... telecommunications services"
 
 
 https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/
 I think most anyone on this list could be considered exempt.
 I do hope the same will be true should our respective local and national
 governments take similar action.
>>> Yes, a number of "essential services" have been identified as needing to
>>> continue to operate under special dispensation during the lockdown, and
>>> telecoms falls within that.
>>> The details of the implementation of the dispensation may be nuanced.
>>> Experience will tell us more in the coming days.
>>> Mark.
>> 
> 
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Peter Beckman

Software-based TOTP offer more security than no one-time passwords, but
admittedly less than the physical tokens. Google Authenticator, Authy,
1Password, LastPass all support TOTP.

On Mon, 23 Mar 2020, Alexandre Petrescu wrote:

I dont know where are people about supporting VPN and one-time passwords on
tokens.

At my work place a few people dont have tokens (OTP - One Time PAsswords).
The reserve of these tokens has been exhausted. NEw ones are being on
order. Until then some people cant get on VPN.

Some people forgot their token on their desk and had to to travel to office
to get it, a thing not good to do to go to office now.

Some (not sure) might have issues with syncing these devices. An OTP token
has a certain skew about clock, and a battery that lasts long. Hopefully,
one's token has been synchronised recently and the battery is new. The
length of time one cant go to office might be anywhere between 21 days
(announced) and 2 months (experrience eg in Wuhan still closed). Some times
the synching of clock can be performed remotely, and some 'coin' batteries
can be replaced by the person with skill and tools, could be extracted from a
quartz watch for example.

An OTP device can be of many kinds. Some people keep OTPs on paper (I did
some time ago). Some OTP devices are like Japanese 'tamaguchi' format,
others like a credit card format.

Alex, LF/HF 3

Le 23/03/2020 à 20:47, Mark Tinka a écrit :

On 23/Mar/20 21:20, Peter Beckman wrote:

But also:

"The categories of people who will be exempted from this lockdown
are... those involved in the production, distribution and supply
of... telecommunications services"

https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/

I think most anyone on this list could be considered exempt.

I do hope the same will be true should our respective local and national
governments take similar action.

Yes, a number of "essential services" have been identified as needing to
continue to operate under special dispensation during the lockdown, and
telecoms falls within that.

The details of the implementation of the dispensation may be nuanced.
Experience will tell us more in the coming days.

Mark.

---
Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Alexandre Petrescu

I dont know where are people about supporting VPN and one-time passwords
on tokens.

At my work place a few people dont have tokens (OTP - One Time
PAsswords). The reserve of these tokens has been exhausted. NEw ones
are being on order. Until then some people cant get on VPN.

Some people forgot their token on their desk and had to to travel to
office to get it, a thing not good to do to go to office now.

Some (not sure) might have issues with syncing these devices. An OTP
token has a certain skew about clock, and a battery that lasts long.
Hopefully, one's token has been synchronised recently and the battery is
new. The length of time one cant go to office might be anywhere between
21 days (announced) and 2 months (experrience eg in Wuhan still
closed). Some times the synching of clock can be performed remotely,
and some 'coin' batteries can be replaced by the person with skill and
tools, could be extracted from a quartz watch for example.

An OTP device can be of many kinds. Some people keep OTPs on paper (I
did some time ago). Some OTP devices are like Japanese 'tamaguchi'
format, others like a credit card format.

Alex, LF/HF 3

Le 23/03/2020 à 20:47, Mark Tinka a écrit :

On 23/Mar/20 21:20, Peter Beckman wrote:

But also:

"The categories of people who will be exempted from this lockdown
are... those involved in the production, distribution and supply
of... telecommunications services"

https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/

I think most anyone on this list could be considered exempt.

I do hope the same will be true should our respective local and national
governments take similar action.

Yes, a number of "essential services" have been identified as needing to
continue to operate under special dispensation during the lockdown, and
telecoms falls within that.

The details of the implementation of the dispensation may be nuanced.
Experience will tell us more in the coming days.

Mark.

Re: South Africa On Lockdown - Coronavirus - Update!

On 23/Mar/20 21:20, Peter Beckman wrote:

> But also:
>
>     "The categories of people who will be exempted from this lockdown
>  are... those involved in the production, distribution and supply
>  of... telecommunications services"
>
> 
> https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/
>
> I think most anyone on this list could be considered exempt.
>
> I do hope the same will be true should our respective local and national
> governments take similar action.

Yes, a number of "essential services" have been identified as needing to
continue to operate under special dispensation during the lockdown, and
telecoms falls within that.

The details of the implementation of the dispensation may be nuanced.
Experience will tell us more in the coming days.

Mark.

Re: South Africa On Lockdown - Coronavirus - Update!

2020-03-23 Thread Peter Beckman


But also:

"The categories of people who will be exempted from this lockdown
 are... those involved in the production, distribution and supply
 of... telecommunications services"

 
https://www.cnbcafrica.com/news/2020/03/23/breaking-nationwide-lockdown-announced-in-south-africa/

I think most anyone on this list could be considered exempt.

I do hope the same will be true should our respective local and national
governments take similar action.

On Mon, 23 Mar 2020, Mark Tinka wrote:


And oh, it's for 21 days...

Mark.

On 23/Mar/20 20:22, Mark Tinka wrote:

So the South African president has just announced - full country
lockdown from midnight this Thursday, 26th March (SAST).

If any of you have any work that needs to be done out here, please
bear that in mind.

Mark.





---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: South Africa On Lockdown - Coronavirus - Update!

And oh, it's for 21 days...

Mark.

On 23/Mar/20 20:22, Mark Tinka wrote:
> So the South African president has just announced - full country
> lockdown from midnight this Thursday, 26th March (SAST).
>
> If any of you have any work that needs to be done out here, please
> bear that in mind.
>
> Mark.

South Africa On Lockdown - Coronavirus

So the South African president has just announced - full country
lockdown from midnight this Thursday, 26th March (SAST).

If any of you have any work that needs to be done out here, please bear
that in mind.

Mark.

Re: Sunday traffic curiosity

2020-03-23 Thread Alexandre Petrescu

Thank you for the update.

The rural usage peaking at 1600 (instead of 2000-24000) sounds as a 
relevant indicator, I think.

It sounds as a shock ('in the middle of the day'), but it is a wave.  
People spot it from a distance, and you do have time.  There are levels 
of 'stay home', increasingly restrictive, separated by days.

It's not like the tsunami hitting Fukushima, and nothing like 9/11 shock.

Ohio borders Pennsylvania and further NYC who is in a level of emergency 
state - cant get into Manhattan.  Ohio is not in the MidWest, and there 
were earlier claims that MidWest might not be affected - I dont know.

If trust there is.

The communnication channels must stay up.

Yours,

Alex, LF/HF 3

Le 23/03/2020 à 15:01, Josh Luthman a écrit :
I'm in Ohio.  Dewine announced a stay at home order in the middle of 
the day.

Our uplink that feeds more urban customers, kept increasing as per 
usual.  Our uplink that feeds exclusively rural customers, leveled out 
- the usage peaked at 1600!!!  I'd never seen it not peak at 2000-2400 
at night.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Mar 23, 2020 at 6:19 AM Alexandre Petrescu 
mailto:alexandre.petre...@gmail.com>> 
wrote:

Le 23/03/2020 à 04:05, Aaron Gould a écrit :
> I can see it now Business driver that moved the world
towards multicast  2020 Coronavirus

I should abstain from writing about this but I think the situation of
virus with a crown version year 2020 is not yet understood on
business.

There are signs business would work as before: business challenges
that
we know worked are now tested with sponsoring open source projects on
3D-printed ventilators (respirator).

Other signs I see seem to differ: same kind of projects but not
looking
for money.  That might not amount for 'business' but might save lives
equally well.

It is not clear to me where it is heading to, probably a mix of
the two.

And it is not clear to me where multicast might fit into this,
because
presumably an Internet-connected ventilator might not have much
data to
send, depending of course, if one wants to put a measurement
device on
another side of the planet and the breath on one side, and the air
pressure might need to be transmitted instantaneously, like 'remote
surgery' needs to transmit haptic feedback effect across long
distances.

It's all hypothesis and speculation from my part.

Alex, LF/HF 3

>
> Also, I wonder how much money would be lost by big pipe
providers with multicast working everywhere
>
> -Aaron
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org
] On Behalf Of Alexandre Petrescu
> Sent: Sunday, March 22, 2020 3:41 PM
> To: nanog@nanog.org 
> Subject: Re: Sunday traffic curiosity
>
>
> Le 22/03/2020 à 21:31, Nick Hilliard a écrit :
>> Grant Taylor via NANOG wrote on 22/03/2020 19:17:
>>> What was wrong with Internet scale multicast? Why did it get
abandoned?
>> there wasn't any problem with inter-domain multicast that
couldn't be
>> resolved by handing over to level 3 engineering and the vendor's
>> support escalation team.
>>
>> But then again, there weren't many problems with inter-domain
>> multicast that could be resolved without handing over to level 3
>> engineering and the vendor's support escalation team.
>>
>> Nick
> For my part I speculate multicast did not take off at any level
(inter
> domain, intra domain) because pipes grew larger (more bandwidth)
faster
> than uses ever needed.  Even now, I dont hear problems of
bandwidth from
> some end users, like friends using netflix.  I do hear in media that
> there _might_ be an issue of capacity, but I did not hear that
from end
> users.
>
> On another hand, link-local multicast does seem to work ok, at least
> with IPv6.  The problem it solves there is not related to the
width of
> the pipe, but more to resistance against 'storms' that were
witnessed
> during ARP storms.  I could guess that Ethernet pipes are now so
large
> they could accomodate many forms of ARP storms, but for one
reason or
> another IPv6 ND has multicast and no broadcast.  It might even be a
> problem in the name, in that it is named 'IPv6 multicast ND' but
> underlying is often implemented with pure broadcast and local
filters.
>
> If the capacity is reached and if end users need more, then
there are
> two alternative solutions: grow capacity unicast (e.g. 1Tb/s
Ethernet)
> or multicast; it's useless to do both.  If we cant do 1 Tb/s
Ethernet
> ('apocalypse'  was called by some?) then we'll do multicast.
>
> I think,

RE: Sunday traffic curiosity

2020-03-23 Thread Keith Medcalf

On Monday, 23 March, 2020 04:19, Alexandre Petrescu 
 wrote:

> ... like  'remote surgery' needs to transmit haptic feedback effect across 
> long distances.

Personally, if I were asked to give consent for surgery and it contained a risk 
"the communications uses the Internet for transport and the Internet is a 
best-effort only communications method" I would not consent.  And in this 
jurisdiction, it would be unlawful to fail to disclose that risk.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: Sunday traffic curiosity

On 23/Mar/20 12:18, Alexandre Petrescu wrote:

>
> I should abstain from writing about this but I think the situation of
> virus with a crown version year 2020 is not yet understood on business.
>
> There are signs business would work as before: business challenges
> that we know worked are now tested with sponsoring open source
> projects on 3D-printed ventilators (respirator).
>
> Other signs I see seem to differ: same kind of projects but not
> looking for money.  That might not amount for 'business' but might
> save lives equally well.
>
> It is not clear to me where it is heading to, probably a mix of the two.

It's going to be a battle between putting capitalism marginally aside
and keeping humanity a going concern.

I laugh when I see the news and hear some countries talking about how
they are first to do this and the first do that, or the first to help
this and the first to help, or the first to discover this and the first
to discover that re: the Coronavirus. Okay, you're the first, and then
what? What good is you being #1 if I am too poor or too dead to buy any
of your #1'ness? But I digress.

The world has been at 100% speed since 2010. This "forced leave" should
be used as a great opportunity to slow down, take a step back, and think
about what REALLY matters.

The companies that will survive and do well in the new economy (during
and post-Coronavirus) are not the ones that can gain the most profit,
but the ones that can gain the most profit while actually caring about
humanity, and offering real value (which = individual + company-wide
fulfillment)

Nothing against Mr. Gates, but let's not wait until we are 60+ to
realize all the billions we've made can actually make meaningful,
valuable difference, on a large scale.

#ProfitAndFulfillmentIsTheNewGame

>
> And it is not clear to me where multicast might fit into this, because
> presumably an Internet-connected ventilator might not have much data
> to send, depending of course, if one wants to put a measurement device
> on another side of the planet and the breath on one side, and the air
> pressure might need to be transmitted instantaneously, like  'remote
> surgery' needs to transmit haptic feedback effect across long distances.

I honestly don't think Multicast features anywhere on today's public
Internet.

Mark.

Re: Sunday traffic curiosity