Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Vernon Schryver (vjs) writes: > > spend it on things with at least a little real world security > implications such as DNSSEC and eventually DANE. +1 Or, even more to the point for this list: on securing DNS operations in general. DNSSEC isn't much help if your registr[ar|y] is a straw hut. I don't like the false sense of security given by "deploy DNSSEC at any cost". I subtext that "How to turn your reliable DNS into a ticking timebomb". > Don't waste time lobbying ICANN, but do urge browser vendors to > start using TLSA records. Browser vendors are doing their think, slowly. > It might be extreme and it's certainly unitentially offensive, but > a case can be made that no one writing from a domain without RRSIGs > on its MX and A RRs should say anything in public about network > security other than to ask about DNSSEC. Again, it's a big picture thing. Defense in layers, etc. Just signing ain't enough. Cheers, Phil, off to teach DNS operations :) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
On Mar 15, 2013, at 10:57 AM, Robert Edmonds wrote: > > i certainly hope the reference to "hr" being a "local" or "internal" or > "non-unique" name is a mistake and that CAs would absolutely refuse to > issue certs for names that are the same as a really existing TLD: > >http://www.iana.org/domains/root/db/hr.html We get a steady stream of requests from CAs to endorse certificates for non-existent hosts under .int, because .int is used as the applicant's internal network. On the bright side, these are CAs that are at least making an effort to check with the registry for a definitive answer. kim ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
> > i certainly hope the reference to "hr" being a "local" or "internal" or > > "non-unique" name is a mistake and that CAs would absolutely refuse to > > issue certs for names that are the same as a really existing TLD: > Not using FQDNs is foolish and unwarranted - and issuing certificates to > match unqualified names is not improving the general picture. > > What I find more disturbing is this: > ... What I find even more disturbing is that people are still talking about commercial PKI as if it it had been other than expensive security theater for more than 10 years (i.e. since CA-2001-04). Instead of spending effort on equivalents to arguing that a black semi-automatic rifle is too dangerous for civilians but the same weapon painted pink is ok, or that a molded hand grip makes a 2 inch knife too dangerous for an airplane, spend it on things with at least a little real world security implications such as DNSSEC and eventually DANE. Don't waste time lobbying ICANN, but do urge browser vendors to start using TLSA records. It might be extreme and it's certainly unitentially offensive, but a case can be made that no one writing from a domain without RRSIGs on its MX and A RRs should say anything in public about network security other than to ask about DNSSEC. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Robert Edmonds wrote on 03/15/2013 01:57:41 PM: > i certainly hope the reference to "hr" being a "local" or "internal" or > "non-unique" name is a mistake and that CAs would absolutely refuse to > issue certs for names that are the same as a really existing TLD: Is there money to be had from selling such a certificate? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
-Original Message- From: Phil Regnauld Date: Friday, March 15, 2013 2:08 PM To: "dns-operati...@mail.dns-oarc.net" Subject: Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates >Robert Edmonds (edmonds) writes: >> >> i certainly hope the reference to "hr" being a "local" or "internal" or >> "non-unique" name is a mistake and that CAs would absolutely refuse to >> issue certs for names that are the same as a really existing TLD: >> >> http://www.iana.org/domains/root/db/hr.html > >Not using FQDNs is foolish and unwarranted - and issuing certificates >to >match unqualified names is not improving the general picture. > >What I find more disturbing is this: > > > Outreach to the CA/B forum7 and CAs, requesting that they treat >applied for new gTLDs as if they were delegated TLDs as soon as >possible, as well as discussing the broader implications and mitigation >steps. > >Good luck on that one. Thanks Phil, Appendix A and B of the report shows that CA/B already taken action with ballot 96. Steve > >Cheers, >Phil > >___ >dns-operations mailing list >dns-operations@lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations >dns-jobs mailing list >https://lists.dns-oarc.net/mailman/listinfo/dns-jobs smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Robert Edmonds (edmonds) writes: > > i certainly hope the reference to "hr" being a "local" or "internal" or > "non-unique" name is a mistake and that CAs would absolutely refuse to > issue certs for names that are the same as a really existing TLD: > > http://www.iana.org/domains/root/db/hr.html Not using FQDNs is foolish and unwarranted - and issuing certificates to match unqualified names is not improving the general picture. What I find more disturbing is this: • Outreach to the CA/B forum7 and CAs, requesting that they treat applied for new gTLDs as if they were delegated TLDs as soon as possible, as well as discussing the broader implications and mitigation steps. Good luck on that one. Cheers, Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Livingood, Jason wrote: > Posted today on the SSAC site @ > http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf. > > Worth reading, especially if you have internal namespace (and associated > internally generated SSL certificates) that overlaps with a new gTLD name. > From the exec summary & intro: there is an interesting quote in this document from a CA: According QuoVadis Group, a certificate authority, one use case for internal name certificate is for convenience: As a convenience for users, many servers in corporate networks are reachable by local names such as “mail”, “wiki” or “hr”. Most publicly trusted certificates for non‐unique names are deployed in the context of local networks to enable trust in these local names without the additional cost of provisioning a new trust root to clients. This may be especially desirable for networks lacking centralized policy deployment and management tools, such as “Bring Your Own Device” environments.[5] 5. See QuoVadis Group. 2012. Internal Server Names and IP Address Requirements for SSL at: https://support.quovadisglobal.com/AvatarHandler.ashx?radfile=%2fCommon%2fSSL+General+Topics+%28KB%29%2fQV_DeprecatedCertsGuidance_v2.pdf. i certainly hope the reference to "hr" being a "local" or "internal" or "non-unique" name is a mistake and that CAs would absolutely refuse to issue certs for names that are the same as a really existing TLD: http://www.iana.org/domains/root/db/hr.html -- Robert Edmonds edmo...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Posted today on the SSAC site @ http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf. Worth reading, especially if you have internal namespace (and associated internally generated SSL certificates) that overlaps with a new gTLD name. From the exec summary & intro: Executive Summary The SSAC has identified a Certificate Authority (CA) practice that, if widely exploited, could pose a significant risk to the privacy and integrity of secure Internet communications. This CA practice could impact the new gTLD program. The SSAC thus advises ICANN take immediate steps to mitigate the risks. 1. Introduction Certificate Authorities, also known as Certification Authorities, (CAs) are organizations that issue digital certificates. These digital certificates certify the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or assertions made by the private key that corresponds to the certified public key. The CAs typically validate the identities of requestors before they issue certificates. For example, when Internet users browse to https://www.myicann.org/, their browsers know it is the real myicann.org because GoDaddy, a CA, has vouched the registered holder of myicann.org and issued a certificate to it. This system breaks down, however, if CAs are unable to validate the applicants they vouch for and their authority over the domain name for which the certificate is applied. One such instance is the “Internal Name” certificate (also known as “non-fully qualified domain names” or non-FQDNs). An Internal Name certificate contains a name that is not currently resolvable using the public Domain Name System (DNS) and which is assumed to be for private use only. An internal name is a domain or Internet Protocol (IP) address that is part of a private network. These internal names are not allocated to any specific organization and therefore cannot be verified. Common examples of internal names are: * Any server name with a non-public domain name suffix. For example, www.company.local or server1.company.corp. * NetBIOS names or short hostnames, anything without a public domain. For example, Web1, ExchCAS1, or Frodo. * Any IP address in the RFC19181 range. These addresses are reserved for private networks only. Internal names are not verifiable by CAs because it is not possible to look up who owns them. When determining whether a certificate application is for internal use or not, CAs often rely on the list of currently delegated Top Level Domains (TLDs) and not, for instance, against the list of the TLDs applied for in ICANN’s new Generic TLD (gTLD) program. For instance, although www.exampletld is currently an internal name, exampletld could be an applied-for-TLD and www.exampletld may later become operational. In this advisory, the SSAC examines the prevalence of internal name certificates, analyzes the security risk it imposes, and advises ICANN to take a few mitigation steps. The SSAC also wishes to highlight that although this practice has immediate impact to new gTLDs, it has larger security ramifications. Full doc @ http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf - Jason ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
