From woody at pch.net Thu Mar 1 11:46:22 2018 From: woody at pch.net (Bill Woodcock) Date: Thu, 1 Mar 2018 08:46:22 -0800 Subject: [ARIN-consult] ASO Review Consultation 2018 In-Reply-To: References: Message-ID: <9550F7A6-A4BD-45AC-A97E-6831ACA0EBB8@pch.net> > On Feb 2, 2018, at 5:59 AM, ARIN wrote: > > As a part of the Number Resource Organization (NRO), ARIN is seeking > community input on the NRO community consultation on the ASO review. Now that there?s a contractual relationship with the IANA Functions Operator, with its own heavyweight oversight process in place, the ASO/AC is completely redundant, since it interfaces with ICANN, and unlike the Names community, we and Protocols don?t do our policymaking within ICANN, we do it ourselves. So, no reason to continue to have an ASO/AC. It would just be looking for a purpose and confusing people. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From alyssa at alyssamoore.ca Thu Mar 1 17:34:38 2018 From: alyssa at alyssamoore.ca (Alyssa Moore) Date: Thu, 01 Mar 2018 22:34:38 +0000 Subject: [ARIN-consult] ASO Review Consultation 2018 In-Reply-To: <9550F7A6-A4BD-45AC-A97E-6831ACA0EBB8@pch.net> References: <9550F7A6-A4BD-45AC-A97E-6831ACA0EBB8@pch.net> Message-ID: It has taken me over two years to wrap my head around the responsibilities, structure and difference between the ASO, ASO AC, NRO, and NRO EC. I have to agree with Woody here on redundancy. Regarding clarity and complexity, it still remains unclear that the ASO is an ICANN Supporting Organization, whose functions are carried out by the NRO, and that the NRO NC and the ASO AC are the same people. And that the NRO EC is part of the ASO, but is separate from the ASO AC, etc. The ASO also plays an advisory role, and not a policy development role like the other two Supporting Organizations within ICANN. If it?s an advisory role, shouldn?t it be an Advisory Committee? Or why can?t that advice come from outside the ICANN structure from the NRO itself? To that end, the vast majority of RIR policy development is all done outside the constraints of the ICANN system on a regional basis. The new IANA SLA replaces the ASO MoU in terms of defining the relationship between ICANN and the RIRs, which has moved away from policy development and coordination toward an operator/clients relationship. The primary role of the ASO - forwarding global policy proposals for ratification to the ICANN Board - is an extremely rare occurrence. Does there need to be a supporting organization for that work? The NRO performs this policy coordination function already. All of that being said, despite the increased volunteer time required in the wake of the Empowered Community, I must say the ASO is probably one of the more efficient creatures of ICANN considering the sheer number of network operators it represents. On Thu, Mar 1, 2018 at 9:46 AM Bill Woodcock wrote: > > > > On Feb 2, 2018, at 5:59 AM, ARIN wrote: > > > > As a part of the Number Resource Organization (NRO), ARIN is seeking > > community input on the NRO community consultation on the ASO review. > > Now that there?s a contractual relationship with the IANA Functions > Operator, with its own heavyweight oversight process in place, the ASO/AC > is completely redundant, since it interfaces with ICANN, and unlike the > Names community, we and Protocols don?t do our policymaking within ICANN, > we do it ourselves. So, no reason to continue to have an ASO/AC. It would > just be looking for a purpose and confusing people. > > -Bill > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markk at arin.net Thu Mar 15 09:56:09 2018 From: markk at arin.net (Mark Kosters) Date: Thu, 15 Mar 2018 13:56:09 +0000 Subject: [ARIN-consult] Summary Report on IRR Presentation at NANOG 72 Message-ID: <743A26C4-8BBF-4811-AF6E-186A5016072A@arin.net> Hi John Curran presented a summary of ARIN's IRR plans to the NANOG community on Feb 20, 2018. The talk is located at: https://tinyurl.com/yaxpcz4z. For those who don't want to use tinyurl, here is the full URL that may wrap: https://pc.nanog.org/static/published/meetings/NANOG72/1618/20180220_Curran_Arin_S_Internet_Routing_v1.pdf . The video of the talk is at: https://youtu.be/tsWq_LgNS5s . At the end of the talk, John opened the floor for comments. A summary of the discussion was: * Concern about ARIN's legacy data and now to transition/remove legacy objects in ARIN's existing IRR. A number of suggestions on the floor were discussed regarding this topic. These ranged from creating different source tag for legacy data and removing the data at some later date to having ARIN create an import tool to transition objects. * RPKI was mentioned as a superior system for routing security but many felt that an improvement to the IRR would be a good intermediate step. * Allowing for better tools that leveraged the existing routing system to help users create correct objects in both RPKI and IRR. * Allowing management of the new IRR through an API as opposed to using templates. We welcome the community to read the slides, listen to John's talk, and to help ARIN more fully flesh out this new service. If you have any comments or additional elements you like to discuss/propose - please provide that input promptly while this consultation remains open. We will use the information received from the consultation to refine our plans for the new IRR. Regards, Mark Kosters From owen at delong.com Fri Mar 16 13:36:26 2018 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Mar 2018 10:36:26 -0700 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> Message-ID: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> I?m actually opposed to this. First, whois lookups are a query against a public database. All information in the database is currently public, so there is no possibility that the content of a whois lookup is sensitive other than, perhaps, the person sending the query wishes their query to be unknown. In that case, the person sending the query is fully empowered to choose https if desired. There is no reason to add SSL overhead to all queries just because. Owen > Begin forwarded message: > > From: ARIN > Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL > Date: March 16, 2018 at 10:02:16 PDT > To: arin-suggestions at arin.net > > On 14 March 2018, we received a new ACSP 2018.3: Automatically Redirect > Whois Queries to Secure URL. > > https://www.arin.net/participate/acsp/suggestions/2018-3.html > > Description: It appears possible to go to the insecure version of ARIN's > whois by going to http://whois.arin.net. Would ARIN be willing > auto-redirect users to the secure version, https://whois.arin.net, and > additionally, consider using HSTS for this site, too? > > Value to Community: Secures all WHOIS lookups, which could sometimes be > potentially sensitive. It's also consistent with what ARIN has done with > most of it's other public-facing websites. > > Timeframe: Not specified > > ** > > We are currently evaluating this suggestion, and will provide a response > to the community as soon as it is available. > > > Regards, > > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > arin-suggestions mailing list > arin-suggestions at arin.net > http://lists.arin.net/mailman/listinfo/arin-suggestions -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Fri Mar 16 14:03:14 2018 From: job at ntt.net (Job Snijders) Date: Fri, 16 Mar 2018 18:03:14 +0000 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> Message-ID: On Fri, 16 Mar 2018 at 18:38, Owen DeLong wrote: > I?m actually opposed to this. > > First, whois lookups are a query against a public database. All > information in the > database is currently public, so there is no possibility that the content > of a whois > lookup is sensitive other than, perhaps, the person sending the query > wishes their > query to be unknown. In that case, the person sending the query is fully > empowered > to choose https if desired. > > There is no reason to add SSL overhead to all queries just because. > This overhead you speak of is negligible. TLS designed to help against eavesdropping, tampering, and message forgery. All of which are desirable qualities in context of querying a service. ARIN should just implement this. Kind regards, Job > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spointer at humdai.net Fri Mar 16 14:04:26 2018 From: spointer at humdai.net (Steve Pointer) Date: Fri, 16 Mar 2018 18:04:26 +0000 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> Message-ID: <1521223466.2574724.1305773776.6F89D5A9@webmail.messagingengine.com> > > There is no reason to add SSL overhead to all queries just because. > SSL/TLS does not just give privacy, it also certifies that the published site has not been tampered with (man-in-the-middle). I would suggest that as the purpose of the whois database is to serve accurate data, including information which may be of use to professionals dealing with cybersecurity events, that the request is totally reasonable, and not "just because". The overhead for HTTPS is real on older hardware, however the most recent generations of CPU have some new fangled magic bit which whilst I do not claim to know how it works, but does have the effect that the HTTPS overhead is very much reduced in real life implementations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rs at seastrom.com Fri Mar 16 14:23:16 2018 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 16 Mar 2018 14:23:16 -0400 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> Message-ID: <90942F1A-B854-41CA-8497-EBEAEDC8F08F@seastrom.com> This service is available over https:// and http:// and includes services that are made available to non-browser libraries (REST) that hopefully handle redirects properly and probably don't have any kind of preserved state that would honor HSTS. Like Owen, I don't see a security/privacy issue surrounding the data returned by lookups in a public database, though there may be some sensitivity to the lookup having been made at all. Depending on the client and the network may be concerns (valid or not) about MITM attacks. The current setup allows the client to make the sole determination as to whether http, https, or https with certificate pinning is appropriate for their application; I believe forcing the issue with a redirect is a step away from goodness. For context, I am culturally generally in favor of encryption except where there is a good reason not to. I was the originator of https://www.arin.net/participate/acsp/suggestions/2015-2.html and noted at the time the ticket was closed that it was not implemented on whois.arin.net and upon reflection didn't have a problem with it because of the likelihood of unintended consequences. Opposed to the redirection, and without the redirection HSTS discussions are out of scope. -r PS: The overhead of TLS is negligible on modern hardware. > On Mar 16, 2018, at 1:36 PM, Owen DeLong wrote: > > I?m actually opposed to this. > > First, whois lookups are a query against a public database. All information in the > database is currently public, so there is no possibility that the content of a whois > lookup is sensitive other than, perhaps, the person sending the query wishes their > query to be unknown. In that case, the person sending the query is fully empowered > to choose https if desired. > > There is no reason to add SSL overhead to all queries just because. > > Owen > > >> Begin forwarded message: >> >> From: ARIN >> Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL >> Date: March 16, 2018 at 10:02:16 PDT >> To: arin-suggestions at arin.net >> >> On 14 March 2018, we received a new ACSP 2018.3: Automatically Redirect >> Whois Queries to Secure URL. >> >> https://www.arin.net/participate/acsp/suggestions/2018-3.html >> >> Description: It appears possible to go to the insecure version of ARIN's >> whois by going to http://whois.arin.net. Would ARIN be willing >> auto-redirect users to the secure version, https://whois.arin.net, and >> additionally, consider using HSTS for this site, too? >> >> Value to Community: Secures all WHOIS lookups, which could sometimes be >> potentially sensitive. It's also consistent with what ARIN has done with >> most of it's other public-facing websites. >> >> Timeframe: Not specified >> >> ** >> >> We are currently evaluating this suggestion, and will provide a response >> to the community as soon as it is available. >> >> >> Regards, >> >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> arin-suggestions mailing list >> arin-suggestions at arin.net >> http://lists.arin.net/mailman/listinfo/arin-suggestions > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From Mel.Stotyn at sjrb.ca Fri Mar 16 15:04:23 2018 From: Mel.Stotyn at sjrb.ca (Mel Stotyn) Date: Fri, 16 Mar 2018 19:04:23 +0000 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <90942F1A-B854-41CA-8497-EBEAEDC8F08F@seastrom.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> <90942F1A-B854-41CA-8497-EBEAEDC8F08F@seastrom.com> Message-ID: RE MITM attack on http:// If that can be intercepted, then it presumably can also be redirected to a good spoof of https://arin.net complete with a certificate that matches the spoofed site. If one is concerned about the security then the https:// should be chosen explicitly while still under the control of the requestor. Redirect doesn't seem to buy much in this case. Opposed. Mel Stotyn -----Original Message----- From: ARIN-consult On Behalf Of Rob Seastrom Sent: Friday, March 16, 2018 12:23 PM To: Owen Delong Cc: Subject: Re: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL This service is available over https:// and http:// and includes services that are made available to non-browser libraries (REST) that hopefully handle redirects properly and probably don't have any kind of preserved state that would honor HSTS. Like Owen, I don't see a security/privacy issue surrounding the data returned by lookups in a public database, though there may be some sensitivity to the lookup having been made at all. Depending on the client and the network may be concerns (valid or not) about MITM attacks. The current setup allows the client to make the sole determination as to whether http, https, or https with certificate pinning is appropriate for their application; I believe forcing the issue with a redirect is a step away from goodness. For context, I am culturally generally in favor of encryption except where there is a good reason not to. I was the originator of https://www.arin.net/participate/acsp/suggestions/2015-2.html and noted at the time the ticket was closed that it was not implemented on whois.arin.net and upon reflection didn't have a problem with it because of the likelihood of unintended consequences. Opposed to the redirection, and without the redirection HSTS discussions are out of scope. -r PS: The overhead of TLS is negligible on modern hardware. > On Mar 16, 2018, at 1:36 PM, Owen DeLong wrote: > > I?m actually opposed to this. > > First, whois lookups are a query against a public database. All > information in the database is currently public, so there is no > possibility that the content of a whois lookup is sensitive other > than, perhaps, the person sending the query wishes their query to be > unknown. In that case, the person sending the query is fully empowered to choose https if desired. > > There is no reason to add SSL overhead to all queries just because. > > Owen > > >> Begin forwarded message: >> >> From: ARIN >> Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect >> Whois Queries to Secure URL >> Date: March 16, 2018 at 10:02:16 PDT >> To: arin-suggestions at arin.net >> >> On 14 March 2018, we received a new ACSP 2018.3: Automatically >> Redirect Whois Queries to Secure URL. >> >> https://www.arin.net/participate/acsp/suggestions/2018-3.html >> >> Description: It appears possible to go to the insecure version of >> ARIN's whois by going to http://whois.arin.net. Would ARIN be willing >> auto-redirect users to the secure version, https://whois.arin.net, >> and additionally, consider using HSTS for this site, too? >> >> Value to Community: Secures all WHOIS lookups, which could sometimes >> be potentially sensitive. It's also consistent with what ARIN has >> done with most of it's other public-facing websites. >> >> Timeframe: Not specified >> >> ** >> >> We are currently evaluating this suggestion, and will provide a >> response to the community as soon as it is available. >> >> >> Regards, >> >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> arin-suggestions mailing list >> arin-suggestions at arin.net >> http://lists.arin.net/mailman/listinfo/arin-suggestions > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services Help Desk at info at arin.net if you experience any issues. _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From scottleibrand at gmail.com Fri Mar 16 15:24:22 2018 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 16 Mar 2018 12:24:22 -0700 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> <90942F1A-B854-41CA-8497-EBEAEDC8F08F@seastrom.com> Message-ID: <314EEF0B-F302-45E0-BB87-F649D70CEC09@gmail.com> That?s what HSTS is for: it forces all subsequent requests from that client (which might be subject to MITM) to use https. So your vulnerability window is dramatically narrowed, to only your very first request ever to an HSTS-enabled site. Scott > On Mar 16, 2018, at 12:04 PM, Mel Stotyn wrote: > > RE MITM attack on http:// > > If that can be intercepted, then it presumably can also be redirected to a good spoof of https://arin.net complete with a certificate that matches the spoofed site. If one is concerned about the security then the https:// should be chosen explicitly while still under the control of the requestor. Redirect doesn't seem to buy much in this case. > > Opposed. > > Mel Stotyn > > -----Original Message----- > From: ARIN-consult On Behalf Of Rob Seastrom > Sent: Friday, March 16, 2018 12:23 PM > To: Owen Delong > Cc: > Subject: Re: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL > > > This service is available over https:// and http:// and includes services that are made available to non-browser libraries (REST) that hopefully handle redirects properly and probably don't have any kind of preserved state that would honor HSTS. > > Like Owen, I don't see a security/privacy issue surrounding the data returned by lookups in a public database, though there may be some sensitivity to the lookup having been made at all. Depending on the client and the network may be concerns (valid or not) about MITM attacks. > > The current setup allows the client to make the sole determination as to whether http, https, or https with certificate pinning is appropriate for their application; I believe forcing the issue with a redirect is a step away from goodness. > > For context, I am culturally generally in favor of encryption except where there is a good reason not to. I was the originator of https://www.arin.net/participate/acsp/suggestions/2015-2.html and noted at the time the ticket was closed that it was not implemented on whois.arin.net and upon reflection didn't have a problem with it because of the likelihood of unintended consequences. > > Opposed to the redirection, and without the redirection HSTS discussions are out of scope. > > -r > > PS: The overhead of TLS is negligible on modern hardware. > > >> On Mar 16, 2018, at 1:36 PM, Owen DeLong wrote: >> >> I?m actually opposed to this. >> >> First, whois lookups are a query against a public database. All >> information in the database is currently public, so there is no >> possibility that the content of a whois lookup is sensitive other >> than, perhaps, the person sending the query wishes their query to be >> unknown. In that case, the person sending the query is fully empowered to choose https if desired. >> >> There is no reason to add SSL overhead to all queries just because. >> >> Owen >> >> >>> Begin forwarded message: >>> >>> From: ARIN >>> Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect >>> Whois Queries to Secure URL >>> Date: March 16, 2018 at 10:02:16 PDT >>> To: arin-suggestions at arin.net >>> >>> On 14 March 2018, we received a new ACSP 2018.3: Automatically >>> Redirect Whois Queries to Secure URL. >>> >>> https://www.arin.net/participate/acsp/suggestions/2018-3.html >>> >>> Description: It appears possible to go to the insecure version of >>> ARIN's whois by going to http://whois.arin.net. Would ARIN be willing >>> auto-redirect users to the secure version, https://whois.arin.net, >>> and additionally, consider using HSTS for this site, too? >>> >>> Value to Community: Secures all WHOIS lookups, which could sometimes >>> be potentially sensitive. It's also consistent with what ARIN has >>> done with most of it's other public-facing websites. >>> >>> Timeframe: Not specified >>> >>> ** >>> >>> We are currently evaluating this suggestion, and will provide a >>> response to the community as soon as it is available. >>> >>> >>> Regards, >>> >>> >>> Communications and Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> _______________________________________________ >>> arin-suggestions mailing list >>> arin-suggestions at arin.net >>> http://lists.arin.net/mailman/listinfo/arin-suggestions >> >> _______________________________________________ >> ARIN-Consult >> You are receiving this message because you are subscribed to the ARIN >> Consult Mailing List (ARIN-consult at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the >> ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From farmer at umn.edu Fri Mar 16 23:14:27 2018 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Mar 2018 22:14:27 -0500 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> Message-ID: I would like to see HSTS applied to "whois.arin.net" that way if you successfully get to the secure version of the site from an HSTS supporting user agent then on you will be forced to use the secure version and won't accidentally (or because of an MITM attack) go to the insecure version in the future. However, if your user agent doesn't support HTTPS, should still be able to get to the insecure site. Therefore, the insecure site should not automatically redirect to the secure version of the site, as insecure access to whois.arin.net should (maybe even must) be allowed. Maybe a compromise would be to have well-known browser user agents presented with a warning banner that says you are accessing the site insecurely and secure access is available via a link provided. Then if the user decides to go to the secure site, they will get an HSTS policy if their browser supports it. Other user agents (presumably programs accessing the API) should not get the additional warning banner unless an encryption status warning flag can be added to the API. I'll also note all links embedded in response pages seem to point to secure pages, even with an insecure query. Maybe the links provided to an insecure query should point to insecure pages. Also, it seems that "https://whois.arin.net/" redirects you to " http://whois.arin.net/ui" the insecure site, that redirect should probably send you to "https://whois.arin.net/ui" instead, the secure site. To summarize; 1. Insecure access to whois.arin.net should (maybe even must) be maintained. 2. Secure access to whois.arin.net should be augmented with HSTS policy to prevent MITM attacks for user agents that support HSTS. 3. Secure queries should provide secure responses, vice-versa, insecure quires should provide insecure responses. 4. Possibly a warning banner could be provided when accessing the insecure site with well-known browsers, allowing users to decide to use the secure site and possibly get HSTS protections in the future, but by their choice, not automatically. Thanks On Fri, Mar 16, 2018 at 12:36 PM, Owen DeLong wrote: > I?m actually opposed to this. > > First, whois lookups are a query against a public database. All > information in the > database is currently public, so there is no possibility that the content > of a whois > lookup is sensitive other than, perhaps, the person sending the query > wishes their > query to be unknown. In that case, the person sending the query is fully > empowered > to choose https if desired. > > There is no reason to add SSL overhead to all queries just because. > > Owen > > > Begin forwarded message: > > *From: *ARIN > *Subject: **[ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect > Whois Queries to Secure URL* > *Date: *March 16, 2018 at 10:02:16 PDT > *To: *arin-suggestions at arin.net > > On 14 March 2018, we received a new ACSP 2018.3: Automatically Redirect > Whois Queries to Secure URL. > > https://www.arin.net/participate/acsp/suggestions/2018-3.html > > Description: It appears possible to go to the insecure version of ARIN's > whois by going to http://whois.arin.net. Would ARIN be willing > auto-redirect users to the secure version, https://whois.arin.net, and > additionally, consider using HSTS for this site, too? > > Value to Community: Secures all WHOIS lookups, which could sometimes be > potentially sensitive. It's also consistent with what ARIN has done with > most of it's other public-facing websites. > > Timeframe: Not specified > > ** > > We are currently evaluating this suggestion, and will provide a response > to the community as soon as it is available. > > > Regards, > > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > arin-suggestions mailing list > arin-suggestions at arin.net > http://lists.arin.net/mailman/listinfo/arin-suggestions > > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin at reg.dd.org Tue Mar 20 13:23:26 2018 From: arin at reg.dd.org (Dave Lawrence) Date: Tue, 20 Mar 2018 13:23:26 -0400 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL Message-ID: <23217.17294.262903.737032@gro.dd.org> On Fri, 16 Mar 2018 at 18:38, Owen DeLong wrote: >> There is no reason to add SSL overhead to all queries just because. I disagree that it is "just because". There is a non-trivial movement to secure all network traffic, in no small part because of the issues that Job identified: Job Snijders writes: > TLS designed to help against eavesdropping, tampering, and message > forgery. All of which are desirable qualities in context of querying > a service. ... but specifically on eavesdropping, also as a general privacy principal of the IETF, particularly in the wake of the Snowden revelations when it adopted the posture that pervasive monitoring is an attack (RFC 7258). You might well not think that looking up WHOIS data is all that sensitive, and the vast majority of the time you're almost certainly right. But you can't tell a priori when all of a sudden it will be an issue. This is something that librarians confronted well before the Internet, and took the professional position that what you choose to look up is private and should be only your business, not that of anyone who comes asking about it. When we already well know that we can't rely on users to make properly informed choices about their own privacy and security posture, why not do what we can to make the Internet more safe and secure for them? From ndavis at arin.net Sun Mar 25 12:45:14 2018 From: ndavis at arin.net (Nate Davis) Date: Sun, 25 Mar 2018 16:45:14 +0000 Subject: [ARIN-consult] ARIN Mailing List Issues Message-ID: ARIN staff resolved an issue last Friday night that prevented proper e-mail delivery to ARIN mailing lists between Monday 19 March and Friday 23 March 2018. To ensure full delivery of e-mail during this period, ARIN staff will repost e-mail during this period to each appropriate mailing list. If you receive duplicate e-mail, please ignore. We apologize for any issues this has created. Staff is committed to preventing this from occurring again in the future. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin at reg.dd.org Tue Mar 20 13:23:26 2018 From: arin at reg.dd.org (Dave Lawrence) Date: Tue, 20 Mar 2018 13:23:26 -0400 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL Message-ID: <23217.17294.262903.737032@gro.dd.org> On Fri, 16 Mar 2018 at 18:38, Owen DeLong wrote: >> There is no reason to add SSL overhead to all queries just because. I disagree that it is "just because". There is a non-trivial movement to secure all network traffic, in no small part because of the issues that Job identified: Job Snijders writes: > TLS designed to help against eavesdropping, tampering, and message > forgery. All of which are desirable qualities in context of querying > a service. ... but specifically on eavesdropping, also as a general privacy principal of the IETF, particularly in the wake of the Snowden revelations when it adopted the posture that pervasive monitoring is an attack (RFC 7258). You might well not think that looking up WHOIS data is all that sensitive, and the vast majority of the time you're almost certainly right. But you can't tell a priori when all of a sudden it will be an issue. This is something that librarians confronted well before the Internet, and took the professional position that what you choose to look up is private and should be only your business, not that of anyone who comes asking about it. When we already well know that we can't rely on users to make properly informed choices about their own privacy and security posture, why not do what we can to make the Internet more safe and secure for them? From bill at herrin.us Sun Mar 25 19:35:53 2018 From: bill at herrin.us (William Herrin) Date: Sun, 25 Mar 2018 19:35:53 -0400 Subject: [ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL In-Reply-To: <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> References: <101902b4-05d5-eee1-f78d-a69de1c50fe7@arin.net> <3230B08A-5A3B-4C77-9BA6-BDA72207F537@delong.com> Message-ID: > From: ARIN > Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois > Queries to Secure URL > Date: March 16, 2018 at 10:02:16 PDT > To: arin-suggestions at arin.net > > On 14 March 2018, we received a new ACSP 2018.3: Automatically Redirect > Whois Queries to Secure URL. > > https://www.arin.net/participate/acsp/suggestions/2018-3.html > > Description: It appears possible to go to the insecure version of ARIN's > whois by going to http://whois.arin.net. Would ARIN be willing > auto-redirect users to the secure version, https://whois.arin.net, and > additionally, consider using HSTS for this site, too? > > Value to Community: Secures all WHOIS lookups, which could sometimes be > potentially sensitive. It's also consistent with what ARIN has done with > most of it's other public-facing websites. Greetings, I am AGAINST sending HTTP redirects (HTTP Location header) to upgrade HTTP requests to whois.arin.net to HTTPS. Security is comprised of the "CIA" triad: Confidentiality, Integrity and Availability. Any security choice which harms the sum of these three categories is a bad choice, even if it improves one of them. Confidentiality is how well a system keeps secret information secret. In general, whois requests to whois.arin.net are not sensitive in nature, The exceptions have https available to them without requiring any change to ARIN behavior. There is reasonable cause to believe that folks who make http requests instead of https requests to whois would gain no improvement to confidentiality. This isn't google search where a user might search health or other sensitive information without thinking about it, whois information just isn't sensitive. Integrity is how well a system guarantees that the data received is the correct data. In general, whois requests to whois.arin.net support human not automated activity thus gain little from an improvement in data integrity. The exceptions have https available to them without requiring any change to ARIN behavior. More, the kinds of man in the middle attacks which could be gainfully executed against the whois service are challenging and rare to the point of non-existent. The integrity improvement from forcing https is negligible at best, particularly when any activity requiring greater integrity has https available to it without requiring any change to ARIN behavior. Availability is the likelihood that a system functions successfully for the user. We should expect the existance of software querying whois which does not support https and/or will malfunction if told to execute a redirect (http location header). Perhaps the client doesn't support https at all. Perhaps the client uses an old version of java and the root of the certificate chain is not in the java key store. There are plenty of reasons to expect a noticeable hit to system availability should ARIN implement an http to https redirect. No meaningful improvement to confidentiality and integrity. Noticeable, potentially large hit to availability. Bad security plan. HSTS is less offensive. The "Strict-Transport-Security" header is sent only via HTTPS connections, never during ordinary HTTP connections. It advises the supporting client software to remember and upgrade all subsequent HTTP requests to HTTPS. The server acts exactly as before, honoring both HTTP and HTTPS requests. Client software which does not support HSTS acts exactly as before, sending requests via HTTP or HTTPS as directed by the user. Only software built to understand HTTPS and HSTS behaves any different. >From the perspective of the CIA triad, HSTS offers negligible improvements to confidentiality (no secrets), a very minor improvement to integrity and a very minor hit to availability (HSTS is pretty new, new stuff is buggy). Basically it's a neutral change in the security posture. Neutral changes run afoul of another core principle of information security: The cost of a security feature must exceed the cost of not having that security feature.Otherwise you're spending more money on security than the information secured is worth, which is foolhardy. There is an annualized dollar cost of implementing and operating HSTS. There is an annualized risk-cost of not implementing HSTS. Who can offer a credible argument that the annualized risk-cost of not implementing HSTS for ARIN whois is something other than zero? I cannot. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From info at arin.net Wed Mar 28 17:16:42 2018 From: info at arin.net (ARIN) Date: Wed, 28 Mar 2018 17:16:42 -0400 Subject: [ARIN-consult] Consultation on ACSP 2018.3 Message-ID: ARIN has received a suggestion requesting Whois queries made from "http" be automatically redirected to "https" in order to make the queries more secure. It has also been suggested ARIN consider using HSTS for Whois services. These suggestions were made through ARIN's Consultation and Suggestion Process and are documented at the following URL: https://www.arin.net/participate/acsp/suggestions/2018-3.html Question: Should ARIN automatically redirect user Whois queries made via "http" to "https"? Question: If ARIN redirects http to https requests, should ARIN then use HSTS for web-based Whois queries? The feedback you provide during this consultation will help inform how ARIN will proceed in response to ACSP 2018.3. All messages that have been sent to the arin-consult mailing lists in response to this suggestion prior to the opening of this consultation will be included in our feedback collection resulting from this consultation. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. Discussion on arin-consult at arin.net will close on 30 April 2018. If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From farmer at umn.edu Wed Mar 28 17:33:22 2018 From: farmer at umn.edu (David Farmer) Date: Wed, 28 Mar 2018 16:33:22 -0500 Subject: [ARIN-consult] Consultation on ACSP 2018.3 In-Reply-To: References: Message-ID: On Wed, Mar 28, 2018 at 4:16 PM, ARIN wrote: > ... > Question: Should ARIN automatically redirect user Whois queries made > via "http" to "https"? > No, ARIN should not automatically redirect Whois queries made via "http" to "https". Insecure Whois queries made via "http", need to be allowed. Maybe a warning could be provided, with a link to direct the whois query to "https". Question: If ARIN redirects http to https requests, should ARIN then > use HSTS for web-based Whois queries? > HSTS should be provided for Whois queries made via "https", even though I don't think Whois queries made via "http" should be automatically redirected to "https". Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Mar 28 18:06:51 2018 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 28 Mar 2018 15:06:51 -0700 Subject: [ARIN-consult] Consultation on ACSP 2018.3 In-Reply-To: Message-ID: <71865.1522274811@segfault.tristatelogic.com> In message , John Curran wrote: >Question: Should ARIN automatically redirect user Whois queries made >via "http" to "https"? > >Question: If ARIN redirects http to https requests, should ARIN then >use HSTS for web-based Whois queries? It is difficult to evaluate these proposals in the absence of a bit more context. Specifically, before responding, I'd like to put my own simple question, prefixed by what I hope is a rather obvious observation: EVEN IF my ARIN WHOIS queries were to be protected (from the proverbial "prying eyes") IN TRANSIT, it is my assumption that somewhere deep within the bowels of ARIN, a log record is generated, and logged, for each such query that I perform. Anyone with the ability to view such log records has no need to spy on my WHOIS queries while they are in transit, as they can just as easily view the corresponding log records. (In fact it would arguably be easier to just look at the log records. WHOIS queries in transit are ephemeral, while log records are entirely less so.) Wih respect to said log records, I would like to know three things: *) How many people are authorized, specifically, by ARIN, to view or access said records? *) What is ARIN's data retention policy with respect to such records? *) May either nefarious Russian hackers or the NSA access such records, the latter presumably doing so under the auspices of a court order or a Presidential finding or directive, secret or otherwise? Speaking as a longtime, constant, and daily user of ARIN WHOIS services, I can say that I operate on the basis of assuming the worst at all times, i.e. that the relevant ARIN log records (a) can be accessed by anyone, certainly within ARIN staff, and perhaps also by outside contractors and others, and that (b) ARIN retains copies of all such records forever, and that (c) unspecified other parties, including but not limited to law enforcement, the NSA, the CIA, and the occasional foreign hacker may perhaps be wittingly or unwittingly given access to said records, by ARIN, either in connection with legal process or otherwise. That having been said, none of these possibilities keep me up at night. My hope is that ARIN will not go about, willy nilly, giving data about my WHOIS queries to the various malefactors who I am gathering data on, but if they do, there ain't much I can do about it in any event. The bottom line is that I can easily think of at least a half dozen other (and far more useful and meaningful) things that I would like to see ARIN staff spending their limited mental cycles and bandwidth on, rather than working to secure, in transit, that which will probably never be entirely secure when it finally arrives at its destination anyway. Regards, rfg From job at ntt.net Thu Mar 29 05:44:43 2018 From: job at ntt.net (Job Snijders) Date: Thu, 29 Mar 2018 09:44:43 +0000 Subject: [ARIN-consult] Consultation on ACSP 2018.3 In-Reply-To: References: Message-ID: <20180329094443.GD61030@vurt.meerval.net> On Wed, Mar 28, 2018 at 04:33:22PM -0500, David Farmer wrote: > On Wed, Mar 28, 2018 at 4:16 PM, ARIN wrote: > > ... > > Question: Should ARIN automatically redirect user Whois queries made > > via "http" to "https"? > > No, ARIN should not automatically redirect Whois queries made via > "http" to "https". Insecure Whois queries made via "http", need to be > allowed. Do you have any supporting arguments for your statement? Kind regards, Job From rs at seastrom.com Thu Mar 29 10:23:43 2018 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 29 Mar 2018 10:23:43 -0400 Subject: [ARIN-consult] Consultation on ACSP 2018.3 In-Reply-To: <20180329094443.GD61030@vurt.meerval.net> References: <20180329094443.GD61030@vurt.meerval.net> Message-ID: <05CD921F-349C-48EA-AB27-0D00BA40167C@seastrom.com> > On Mar 29, 2018, at 5:44 AM, Job Snijders wrote: > > On Wed, Mar 28, 2018 at 04:33:22PM -0500, David Farmer wrote: >> On Wed, Mar 28, 2018 at 4:16 PM, ARIN wrote: >>> ... >>> Question: Should ARIN automatically redirect user Whois queries made >>> via "http" to "https"? >> >> No, ARIN should not automatically redirect Whois queries made via >> "http" to "https". Insecure Whois queries made via "http", need to be >> allowed. > > Do you have any supporting arguments for your statement? Hi Job, I suppose I wouldn't have any problems with automatic redirects for anything that had a user-agent that looked like a modern browser. I did a cursory look and couldn't find the slide deck, but my recollection from a presentation by Mark Kosters is that there are a significant number of things hitting the REST interface that are not browsers; they may even outnumber the human visitors - and it's the same host, whois.arin.net. Neither you nor I has any idea how well those clients will handle redirects and https. One would earnestly hope that by and large folks are using standard libraries that will magically do the right thing, yet repeated experiences with password hash dumps wherein a homemade (and cryptographically poor) KDF has been employed shows that the DIY spirit is alive and well and I would not expect it to be any different here. So there's a balance of harms argument to be had: is forcibly encrypting traffic that has historically been of marginal privacy concern worth breaking client software in the field? Bear in mind that if someone chooses to use https:// then things will be encrypted just fine; there is nothing forcing the client to be unencrypted when they'd rather be encrypted, and deploying HSTS will make modern browser users sticky to https://. I submit that David has articulated the right balance to strike and that redirects are a poor idea. If we advertise for some number of years that we're sunsetting non-https access to whois (if events haven't been overtaken by RDAP at that point), then I'll probably feel differently about this. Note that I'm generally in favor of encryption. In January 2015 I submitted an ACSP proposal asking for HSTS where practicable and in October 2015 I mentioned at the members' meeting that HSTS on the REST-Whois seemed to have been overlooked (see https://www.rwhois.net/vault/participate/meetings/reports/ARIN_36/mem_transcript.html ). I'm just not a fan of intentionally breaking things, even if they're crappy software, without a lot of forethought and deliberate intent. cheers, -r From farmer at umn.edu Fri Mar 30 13:07:09 2018 From: farmer at umn.edu (David Farmer) Date: Fri, 30 Mar 2018 12:07:09 -0500 Subject: [ARIN-consult] Consultation on ACSP 2018.3 In-Reply-To: <05CD921F-349C-48EA-AB27-0D00BA40167C@seastrom.com> References: <20180329094443.GD61030@vurt.meerval.net> <05CD921F-349C-48EA-AB27-0D00BA40167C@seastrom.com> Message-ID: See inline; On Thu, Mar 29, 2018 at 9:23 AM, Rob Seastrom wrote: > > > On Mar 29, 2018, at 5:44 AM, Job Snijders wrote: > > > > On Wed, Mar 28, 2018 at 04:33:22PM -0500, David Farmer wrote: > >> On Wed, Mar 28, 2018 at 4:16 PM, ARIN wrote: > >>> ... > >>> Question: Should ARIN automatically redirect user Whois queries made > >>> via "http" to "https"? > >> > >> No, ARIN should not automatically redirect Whois queries made via > >> "http" to "https". Insecure Whois queries made via "http", need to be > >> allowed. > > > > Do you have any supporting arguments for your statement? > That's a fair question and my answer to the question above was probably a little too terse. I intended to not repeat what I had said in the thread regarding the original suggestion and I ended up proving just my answer insufficient justification for it. Rob summarizes my feelings on the subject well. More below; Hi Job, > > I suppose I wouldn't have any problems with automatic redirects for > anything that had a user-agent that looked like a modern browser. > > I did a cursory look and couldn't find the slide deck, but my recollection > from a presentation by Mark Kosters is that there are a significant number > of things hitting the REST interface that are not browsers; they may even > outnumber the human visitors - and it's the same host, whois.arin.net. > > Neither you nor I has any idea how well those clients will handle > redirects and https. One would earnestly hope that by and large folks are > using standard libraries that will magically do the right thing, yet > repeated experiences with password hash dumps wherein a homemade (and > cryptographically poor) KDF has been employed shows that the DIY spirit is > alive and well and I would not expect it to be any different here. > > So there's a balance of harms argument to be had: is forcibly encrypting > traffic that has historically been of marginal privacy concern worth > breaking client software in the field? Bear in mind that if someone > chooses to use https:// then things will be encrypted just fine; there is > nothing forcing the client to be unencrypted when they'd rather be > encrypted, and deploying HSTS will make modern browser users sticky to > https://. > > I submit that David has articulated the right balance to strike and that > redirects are a poor idea. If we advertise for some number of years that > we're sunsetting non-https access to whois (if events haven't been > overtaken by RDAP at that point), then I'll probably feel differently about > this. > > Note that I'm generally in favor of encryption. In January 2015 I > submitted an ACSP proposal asking for HSTS where practicable and in October > 2015 I mentioned at the members' meeting that HSTS on the REST-Whois seemed > to have been overlooked (see https://www.rwhois.net/vault/p > articipate/meetings/reports/ARIN_36/mem_transcript.html ). I'm just not > a fan of intentionally breaking things, even if they're crappy software, > without a lot of forethought and deliberate intent. > Upon reflection, and building on Rob's comments, I'm changing my answer, ARIN should adopt a goal of redirecting all "http" traffic to "https" for whois.arin.net. However, I don't think "http" access to whois.arin.net, especially programmatic access to the Whois REST API, should be precipitously terminated. Therefore a sufficiently generous sunset date needs to be given for the discontinuation of "http" access to whois.arin.net and the redirecting all "http" traffic to "https", I'd say at least a year. However, the date for final discontinuation of "http" access should be driven by data about the amount of use of the "http" version of whois.arin.net, and not some inflexible sunset date. On the other hand, I'm not saying access to the " http" version of whois.arin.net needs to get to zero before it can be terminated either, but we need to understand and accept the potential damage caused by the event before it happens. In the meantime providing HSTS policy and redirecting "http" traffic for most known browser user agents should begin ASAP. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: