<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:82268401;
mso-list-type:hybrid;
mso-list-template-ids:1301204826 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word;overflow-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">My thoughts (some of which others have previously stated):<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt">I agree with others that email as MFA that is also the recovery email significantly weakens the overall security of it. Using an alternative email that
is not the recovery email for 2FA would ameliorate that, if that is an option. I would be in support of email as MFA in that scenario.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt">Others pointed out SMS is considered a weaker MFA path (true), but I think there is a problem with widespread adoption of alternatives in ARIN’s service
area. The “right” answer is to say FIDO\TOTP, but I don’t think we’re there from a practical standpoint yet and SMS use represents a practical reality for the time being. Restricting MFA to the ARIN region does seem like a continued reasonable middle ground,
though I’m making that statement on the presumption that in theory those carriers are easier to assume reliability (or it is more difficult to compromise users on those services) that farther-flung international ones (which could be one of those myths I believe.)
Definitely taking in the other comments and thinking about them. <o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:11.0pt">I think there is a good reason to create some sort of upper bound on the number of keys registered. Unlimited disincentivizes users from actively managing
the tokens registered and can create edge cases if someone takes advantage of that. 5-10 sounds superficially reasonable, though I’d be interested in other viewpoints detailing cases I may not be considering. Soft limits also seem good, if practical.
<o:p></o:p></span></li></ol>
<p class="MsoListParagraph"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks – <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Doug<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Douglas J. Camin<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">doug@dougcamin.com</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">ARIN-consult <arin-consult-bounces@arin.net> on behalf of Chris Woodfield <chris@semihuman.com><br>
<b>Date: </b>Tuesday, January 24, 2023 at 2:30 PM<br>
<b>To: </b>ARIN <info@arin.net><br>
<b>Cc: </b><arin-consult@arin.net><br>
<b>Subject: </b>Re: [ARIN-consult] Consultation on Expanding 2FA Options for ARIN Online<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Jan 24, 2023, at 11:16 AM, Ross Tajvar <ross@tajvar.io> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">> 1. Would you support ARIN offering email as an additional 2FA method?<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt">No.</span></b><span style="font-size:11.0pt"> Email can be used to reset one's password. If it's used for one-time login codes as well, that's only one authentication factor. An email compromise could therefore
easily result in account takeover, which defeats the purpose of 2FA.<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Agreed. The password-reset mechanism and standard 2FA login process should not both use the same auth path.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">> 2. Given that 13% of web user accounts list phone numbers outside the ARIN service region, should we widen the availability of SMS, or are the other offered 2FA options sufficient to meet the needs of these
users?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I am against SMS 2FA being offered as an option at all, so I'm ambivalent about this.<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m not a fan of SMS as a 2FA for all the obvious reasons, but also recognize that requiring FIDO/TOTP as the *only* supported 2FA is a sure path to tepid adoption. I believe that we should highly encourage
users to prefer those mechanisms over SMS but not prohibit SMS as an option.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">> 3. We agree that users should be allowed to register multiple hardware security keys. The question is: What is the optimal number of keys that should be allowed to be registered?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I can't see someone reasonably needing to register more than a handful, but I also don't think there's a good reason to set a low limit. I think 10 is a reasonable upper bound.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">The only reason I can see to limit the number of keys is to discourage the use of a single account by multiple employees in an organization. I think a good approach is to have a soft limit (say, 8) that can
be increased on request to help combat this. There should also be a mechanism to delete no-longer-used 2FA keys instead of simply disabling them (Seems obvious, but I have accounts on sites that don’t allow this, leading to a ever-growing list of registered
auth apps on various phones shown in my account) <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Separate question - is there a workflow for manually resettting/removing user 2FA when users lose their tokens/auth apps/phone numbers/etc? How would ARIN staff authenticate those requests? Please, please
don’t make that process involve a notary (I’m looking at you, AWS).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">-Chris<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Tue, Jan 24, 2023 at 1:53 PM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:11.0pt">On 1 November 2022, ARIN announced that we will require two-factor authentication (2FA) on all ARIN Online accounts beginning 1 February 2023. ARIN currently has three options for customers to set up 2FA
on their ARIN Online accounts:<br>
<br>
- Time-based One-time Password (TOTP) using an authenticator of your choice<br>
- Short Message Service (SMS) for customers within the ARIN service region<br>
- FIDO2/Passkey-enabled Security Key<br>
<br>
Please note: Voice 2FA is not currently available for new 2FA activations; it is still available to those customers who already have that method set up on their accounts.<br>
<br>
Following the announcement of the planned enforcement date of 1 February 2023, we received several suggestions for further expansion of our authentication offerings, including:<br>
<br>
- Allowing email as an authentication method<br>
- Enabling SMS support for customers who reside outside of the ARIN service region<br>
- Allowing registration of multiple hardware security keys.<br>
<br>
We are seeking community feedback on these suggestions as well as additional input on our 2FA options. Specifically:<br>
<br>
1. Would you support ARIN offering email as an additional 2FA method?<br>
<br>
2. Given that 13% of web user accounts list phone numbers outside the ARIN service region, should we widen the availability of SMS, or are the other offered 2FA options sufficient to meet the needs of these users?<br>
<br>
3. We agree that users should be allowed to register multiple hardware security keys. The question is: What is the optimal number of keys that should be allowed to be registered?<br>
<br>
The feedback you provide during this consultation will help us decide the path forward regarding our 2FA options for ARIN Online. Thank you for your participation in the ARIN Consultation and Suggestion Process.<br>
<br>
Please provide comments to <a href="mailto:arin-consult@arin.net" target="_blank">
arin-consult@arin.net</a>. You can subscribe to this mailing list at: <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-consult&data=05%7C01%7C%7Cbf0bb50df42545aa2bb208dafe4179b2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638101854428385449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qKZSPVTAkNB9AyQH6OXMve6wIukolPMfg048UqD020A%3D&reserved=0" target="_blank">
https://lists.arin.net/mailman/listinfo/arin-consult</a><br>
<br>
This consultation will remain open through 5:00 PM ET on 7 February 2023.<br>
<br>
Regards,<br>
<br>
John Curran<br>
President and CEO<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
Helpful Resources:<br>
<br>
Consultation: <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fcommunity%2Facsp%2Fconsultations%2F2023%2F2023-1%2FTwo-Factor&data=05%7C01%7C%7Cbf0bb50df42545aa2bb208dafe4179b2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638101854428385449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sjBrCxaaYVFg8s3ae12vADXK7jD1f5zMb%2Bzh1GUuhL0%3D&reserved=0" target="_blank">
https://www.arin.net/participate/community/acsp/consultations/2023/2023-1/<br>
Two-Factor</a> Authentication at ARIN: <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farin.net%2F2FA&data=05%7C01%7C%7Cbf0bb50df42545aa2bb208dafe4179b2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638101854428385449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uT5HrwmseNdOl21BLKROcDi4KK9Lr7jEyTvFunkB5KU%3D&reserved=0" target="_blank">
https://arin.net/2FA</a><br>
<br>
<br>
_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net" target="_blank">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-consult&data=05%7C01%7C%7Cbf0bb50df42545aa2bb208dafe4179b2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638101854428385449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qKZSPVTAkNB9AyQH6OXMve6wIukolPMfg048UqD020A%3D&reserved=0" target="_blank">https://lists.arin.net/mailman/listinfo/arin-consult</a>
Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (ARIN-consult@arin.net).<br>
Unsubscribe or manage your mailing list subscription at:<br>
https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services<br>
Help Desk at info@arin.net if you experience any issues.<o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>