From ripe at brite.cz Thu Aug 1 10:29:40 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Thu, 01 Aug 2019 10:29:40 +0200 Subject: [atlas] =?utf-8?q?Network_name_missing_at_http=3A//sg-pub=2Eripe?= =?utf-8?q?=2Enet/petros/population=5Fcoverage/country=2Ehtml=3Fname=3DCZ?= Message-ID: <20190801102940.40895A19@centrum.cz> Hi team, RIPE Atlas Population Coverage tool ( http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ ) is missing Network Names (column "Network Name") in more than half rows. It seems it is the same for multiple/all countries. Please have a look. Thank you Jiri From emile.aben at ripe.net Thu Aug 1 14:47:30 2019 From: emile.aben at ripe.net (Emile Aben) Date: Thu, 1 Aug 2019 14:47:30 +0200 Subject: [atlas] Network name missing at http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ In-Reply-To: <20190801102940.40895A19@centrum.cz> References: <20190801102940.40895A19@centrum.cz> Message-ID: <1b151d43-db6f-2736-4cbe-2a41a11b08e3@ripe.net> Hi Jiri, On 01/08/2019 10:29, ripe at brite.cz wrote: > Hi team, > RIPE Atlas Population Coverage tool ( http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ ) is missing Network Names (column "Network Name") in more than half rows. > It seems it is the same for multiple/all countries. > Please have a look. Thanks for using the population coverage tool. I've tracked down the issue in this prototype page, but don't have an easy fix available right now. As a work-around you can click on the AS number in the table, that will lead you to a RIPEstat page that has the AS name. best regards, Emile Aben RIPE NCC From johannbg at gmail.com Thu Aug 22 10:30:11 2019 From: johannbg at gmail.com (=?UTF-8?B?SsOzaGFubiBCLiBHdcOwbXVuZHNzb24=?=) Date: Thu, 22 Aug 2019 08:30:11 +0000 Subject: [atlas] SSL Certificates for ripe anchors Message-ID: Hi Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt? Regards ??????????? J?hann B. From ripe at brite.cz Tue Aug 27 13:16:41 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Tue, 27 Aug 2019 13:16:41 +0200 Subject: [atlas] =?utf-8?q?User_Tags_missing_=5BProbeTag_object=5D?= Message-ID: <20190827131641.461BF6A8@centrum.cz> Hi team, all User Tags on all probes I checked are showing string "ProbeTag object" only. Please have a look. Thank you Jiri From camin at ripe.net Tue Aug 27 15:48:11 2019 From: camin at ripe.net (Chris Amin) Date: Tue, 27 Aug 2019 15:48:11 +0200 Subject: [atlas] User Tags missing [ProbeTag object] In-Reply-To: <20190827131641.461BF6A8@centrum.cz> References: <20190827131641.461BF6A8@centrum.cz> Message-ID: <7560a8c9-3e22-830d-b5ea-f23c3b75c2bc@ripe.net> Dear Jiri, Thanks for reporting this. It has now been fixed, so tags should display as normal! Regards, Chris Amin RIPE NCC On 27/08/2019 13:16, ripe at brite.cz wrote: > Hi team, > all User Tags on all probes I checked are showing string "ProbeTag object" only. > Please have a look. > > Thank you > Jiri > > From yves.croison at wanadoo.fr Tue Aug 27 17:08:48 2019 From: yves.croison at wanadoo.fr (yves croison) Date: Tue, 27 Aug 2019 17:08:48 +0200 Subject: [atlas] User Tags missing [ProbeTag object] In-Reply-To: <7560a8c9-3e22-830d-b5ea-f23c3b75c2bc@ripe.net> References: <20190827131641.461BF6A8@centrum.cz> <7560a8c9-3e22-830d-b5ea-f23c3b75c2bc@ripe.net> Message-ID: <07256d7d-d996-1fc8-3bf0-ea00b2390ee1@wanadoo.fr> at home it's good I found my tags. thank you Le 27/08/2019 ? 15:48, Chris Amin a ?crit?: > Dear Jiri, > > Thanks for reporting this. It has now been fixed, so tags should display > as normal! > > Regards, > Chris Amin > RIPE NCC > > On 27/08/2019 13:16, ripe at brite.cz wrote: >> Hi team, >> all User Tags on all probes I checked are showing string "ProbeTag object" only. >> Please have a look. >> >> Thank you >> Jiri >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsalgado at nic.cl Thu Aug 29 16:37:58 2019 From: hsalgado at nic.cl (Hugo Salgado) Date: Thu, 29 Aug 2019 10:37:58 -0400 Subject: [atlas] Measurement with msm probe type isn't working Message-ID: <20190829143757.oe3brilo7rlfrr7z@nic.cl> Dear Atlas team. I have a script to launch a new measurement using an old measurement list of probes ids, using type:msm. This script worked ok several times (last time like 1 month ago), but now it gives me the error: {"error":{"detail":"There was a problem with your request","status":400,"title":"Bad Request","code":102,"errors":[{"source":{"pointer":"/probes/0/value"},"detail":"The measurement you selected for your probe request does not exist"}]}} However I still can see the old measurement on the web page! I solved it downloading the list of probes using a GET to https://atlas.ripe.net/api/v2/measurements//?fields=probes' and then giving the complete probes list to my script. Is there any recent change with the type:msm call? Thanks, Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rustrict at gmail.com Fri Aug 30 11:33:37 2019 From: rustrict at gmail.com (Alexey Troshchanovich) Date: Fri, 30 Aug 2019 12:33:37 +0300 Subject: [atlas] "Anchor Details" on the probe pages Message-ID: Hello team, Is it normal that the probe pages contain an empty "Anchor Details" section?
>

Anchor Details

> ... >
> Thank you. Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Aug 30 11:54:32 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 30 Aug 2019 11:54:32 +0200 Subject: [atlas] "Anchor Details" on the probe pages In-Reply-To: References: Message-ID: <2c7d148b-8666-a619-490c-01a3fc7a5dcb@ripe.net> On 2019-08-30 11:33, Alexey Troshchanovich wrote: > Hello team, > Is it normal that the probe pages contain an empty "Anchor Details" section? > >
>

Anchor Details

> ... >
> > > Thank you. > > Alexey Hello, Thank you for pointing this out. This has been fixed; it is a section that should only have been displayed for anchors, it is empty / meaningless for regular probes. Regards, Robert Kisteleki From robert at ripe.net Fri Aug 30 12:07:24 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 30 Aug 2019 12:07:24 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: References: Message-ID: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> On 2019-08-22 10:30, J?hann B. Gu?mundsson wrote: > Hi > > > Has there been any dialog about moving the anchors away from using self > signed certificates to Let's Encrypt? > > > Regards > > ??????????? J?hann B. Hello, I believe there was no elaborate discussion about this so far. We do have TLSA records for all anchors which could be of help depending on what you want to achieve. Regards, Robert From jdenhertog at ripe.net Fri Aug 30 12:15:09 2019 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Fri, 30 Aug 2019 12:15:09 +0200 Subject: [atlas] Measurement with msm probe type isn't working In-Reply-To: <20190829143757.oe3brilo7rlfrr7z@nic.cl> References: <20190829143757.oe3brilo7rlfrr7z@nic.cl> Message-ID: hi Hugo, Thanks for this feedback, I can confirm this is a bug. I was able to reproduce this. You?ve hit (regression) bug, probably due to (massive) changes we have made to our backends recently. We have started figuring out what causes this and come up with a solution. I?ll keep you posted on progress we?re making. Sorry for the inconvenience this has caused, greetings, Jasper den Hertog > On 29 Aug 2019, at 16:37, Hugo Salgado wrote: > > Dear Atlas team. > I have a script to launch a new measurement using an old measurement > list of probes ids, using type:msm. This script worked ok several > times (last time like 1 month ago), but now it gives me the error: > > {"error":{"detail":"There was a problem with your request","status":400,"title":"Bad > Request","code":102,"errors":[{"source":{"pointer":"/probes/0/value"},"detail":"The > measurement you selected for your probe request does not exist"}]}} > > However I still can see the old measurement on the web page! > > I solved it downloading the list of probes using a GET to > https://atlas.ripe.net/api/v2/measurements//?fields=probes' > and then giving the complete probes list to my script. > > Is there any recent change with the type:msm call? > > Thanks, > > Hugo > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2639 bytes Desc: not available URL: From johannbg at gmail.com Fri Aug 30 15:14:41 2019 From: johannbg at gmail.com (=?UTF-8?B?SsOzaGFubiBCLiBHdcOwbXVuZHNzb24=?=) Date: Fri, 30 Aug 2019 13:14:41 +0000 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> Message-ID: On 8/30/19 10:07 AM, Robert Kisteleki wrote: > On 2019-08-22 10:30, J?hann B. Gu?mundsson wrote: >> Hi >> >> >> Has there been any dialog about moving the anchors away from using self >> signed certificates to Let's Encrypt? >> >> >> Regards >> >> ??????????? J?hann B. > Hello, > > I believe there was no elaborate discussion about this so far. We do > have TLSA records for all anchors which could be of help depending on > what you want to achieve. What I'm trying to achieve is that ripe's anchors in data centers follow the latest security practices and standards, which require among other things a valid certificate issuer and associated CAA record for *.anchors.atlas.ripe.net anchors be it from Let's encrypt or Digicert, ripe's current certificate issuer Using a self signed certificate in today's age act's as an indicator that the security on the device or server in use might be in question ( if you cant even have an valid certificate issuer on the device or server when it's free, what other things are you skipping on, underlying OS and library updates, coding practices etc. ) and thus can negatively impact the anchor hosting provider security grade, which may lead to anchors having to be removed from data centers to prevent them from negatively affect corporation's security ratings. If money was the issue why the anchors got deployed with self signed certificates to begin with, that's not an issue anymore and probably the community can just get rid of Digicert and actually save money or use that money for lottery or beer on ripe event(s) .? ;) Regards ???????????? J?hann B. From petr.spacek at nic.cz Fri Aug 30 15:47:37 2019 From: petr.spacek at nic.cz (=?UTF-8?B?UGV0ciDFoHBhxI1law==?=) Date: Fri, 30 Aug 2019 15:47:37 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> Message-ID: <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> On 30. 08. 19 15:14, J?hann B. Gu?mundsson wrote: > On 8/30/19 10:07 AM, Robert Kisteleki wrote: >> On 2019-08-22 10:30, J?hann B. Gu?mundsson wrote: >>> Hi >>> >>> >>> Has there been any dialog about moving the anchors away from using self >>> signed certificates to Let's Encrypt? >>> >>> >>> Regards >>> >>> ???????????? J?hann B. >> Hello, >> >> I believe there was no elaborate discussion about this so far. We do >> have TLSA records for all anchors which could be of help depending on >> what you want to achieve. > > > What I'm trying to achieve is that ripe's anchors in data centers follow > the latest security practices and standards, which require among other > things a valid certificate issuer and associated CAA record for > *.anchors.atlas.ripe.net anchors be it from Let's encrypt or Digicert, > ripe's current certificate issuer > > Using a self signed certificate in today's age act's as an indicator > that the security on the device or server in use might be in question ( > if you cant even have an valid certificate issuer on the device or > server when it's free, what other things are you skipping on, underlying > OS and library updates, coding practices etc. ) and thus can negatively > impact the anchor hosting provider security grade, which may lead to > anchors having to be removed from data centers to prevent them from > negatively affect corporation's security ratings. > > If money was the issue why the anchors got deployed with self signed > certificates to begin with, that's not an issue anymore and probably the > community can just get rid of Digicert and actually save money or use > that money for lottery or beer on ripe event(s) .? ;) Hold your horses, self-signed cert with proper TLSA records in DNSSEC-signed domain is even better, see https://tools.ietf.org/html/rfc6698 . Besides other things correctly configured TLSA record + client side validation prevents rogue or compromised CAs from issuing "fake but accepted as valid" certs. So I would say RIPE NCC is attempting to do security it in the most modern way available. -- Petr ?pa?ek @ CZ.NIC From sander at steffann.nl Fri Aug 30 16:36:29 2019 From: sander at steffann.nl (Sander Steffann) Date: Fri, 30 Aug 2019 16:36:29 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> Message-ID: <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> Hi, > Hold your horses, self-signed cert with proper TLSA records in > DNSSEC-signed domain is even better, see > https://tools.ietf.org/html/rfc6698 . > > Besides other things correctly configured TLSA record + client side > validation prevents rogue or compromised CAs from issuing "fake but > accepted as valid" certs. > > So I would say RIPE NCC is attempting to do security it in the most > modern way available. Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From johannbg at gmail.com Fri Aug 30 17:08:06 2019 From: johannbg at gmail.com (=?UTF-8?B?SsOzaGFubiBCLiBHdcOwbXVuZHNzb24=?=) Date: Fri, 30 Aug 2019 15:08:06 +0000 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> Message-ID: <4eef9839-28dc-e2ee-4d84-a2e66e80ceeb@gmail.com> On 8/30/19 2:36 PM, Sander Steffann wrote: > Hi, > >> Hold your horses, self-signed cert with proper TLSA records in >> DNSSEC-signed domain is even better, see >> https://tools.ietf.org/html/rfc6698 . >> >> Besides other things correctly configured TLSA record + client side >> validation prevents rogue or compromised CAs from issuing "fake but >> accepted as valid" certs. >> >> So I would say RIPE NCC is attempting to do security it in the most >> modern way available. > Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. The third parties that "certify" are for others to establish trust in that you are who you claim to be not because its "required" and the security industry has deemed those who do not atleast get some other entity to validate, not to be worthy of trust. Just because Trump says he's a genius and the "chosen one" does not make him one now does it... JBG From gert at space.net Fri Aug 30 20:32:19 2019 From: gert at space.net (Gert Doering) Date: Fri, 30 Aug 2019 20:32:19 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <4eef9839-28dc-e2ee-4d84-a2e66e80ceeb@gmail.com> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <4eef9839-28dc-e2ee-4d84-a2e66e80ceeb@gmail.com> Message-ID: <20190830183219.GF55186@Space.Net> Hi, On Fri, Aug 30, 2019 at 03:08:06PM +0000, J?hann B. Gu?mundsson wrote: > > Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. > > The third parties that "certify" are for others to establish trust in > that you are who you claim to be not because its "required" and the > security industry has deemed those who do not atleast get some other > entity to validate, not to be worthy of trust. TLSA does all this, without requiring some other entity that follows their own agenda to "certify" anything. You need to trust the DNS root KSK, of course, but everything else follows the normal DNSSEC chain. > Just because Trump says he's a genius and the "chosen one" does not make > him one now does it... No, but that is slighly missing the point. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bjorn at mork.no Fri Aug 30 20:33:49 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 30 Aug 2019 20:33:49 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> (Sander Steffann's message of "Fri, 30 Aug 2019 16:36:29 +0200") References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> Message-ID: <874l1ysdte.fsf@miraculix.mork.no> Sander Steffann writes: > Yep. I wish the use of TLSA was more wide spread. It doesn't require > third parties to "certify" who is who. +1 There is still too much money in the CA business. Which is the reason why no major browser does TLSA validation. And why "best practices" allow, or even recommend, inferior solutions like CAA, HPKP and other bad ideas instead of DANE. You gotta look at the source of those recommendations. They are most likely "best" for someones wallet. Not necessarily for security. It's amazing that they still try to make those pigs fly. Bj?rn From johannbg at gmail.com Fri Aug 30 21:31:05 2019 From: johannbg at gmail.com (=?UTF-8?B?SsOzaGFubiBCLiBHdcOwbXVuZHNzb24=?=) Date: Fri, 30 Aug 2019 19:31:05 +0000 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <874l1ysdte.fsf@miraculix.mork.no> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: On Fri, Aug 30, 2019, 18:34 Bj?rn Mork wrote: > Sander Steffann writes: > > > Yep. I wish the use of TLSA was more wide spread. It doesn't require > > third parties to "certify" who is who. > > +1 > > There is still too much money in the CA business. I would argue not but given that ripe itself is still paying digicert that arguement would be muted Which is the reason > why no major browser does TLSA validation. ** And why "best practices" > allow, or even recommend, inferior solutions like CAA, HPKP and other > bad ideas instead of DANE. How on earth is having a CAA record which pin points who is allowed to issue certificates on your behalf an inferiour solution. A RR that you use with DANE btw o_O You gotta look at the source of those > recommendations. They are most likely "best" for someones wallet. Not > necessarily for security. > Still no one has answered why ripe is using self signed certs for anchor when they can use let's encrypt for free... It's amazing that they still try to make those pigs fly. > Who are they? The evil certificate cabal that is out to destroy the world? Do I need to start wearing my tin foil hat when I go out riding and storm area 51 while i'm at it ;) In anycase to stay on topic. If the person or team that is responsible for the certificates on anchors can answer why they choose to use self signed certs, and why the ripe community is still paying for digicert when there is equally good, free signed alternative in an open community available,that would be good. If the answer is "we have not gotten around to it yet, but are planning to switch to let's encrypt for our self signed and paid certificates" *wink*wink**nudge*nudge* that would be even better. Thanks JBG -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Aug 30 22:29:42 2019 From: randy at psg.com (Randy Bush) Date: Fri, 30 Aug 2019 13:29:42 -0700 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <874l1ysdte.fsf@miraculix.mork.no> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: > There is still too much money in the CA business. well, though on the surface i agree, i do not take it as a motivation to add one more chunk of sysadmin. > Which is the reason why no major browser does TLSA validation. well. there is the extra protocol turn. agl tried and backed off, seemingly because of that. but, if we want to encourage tlsa, recommended values for the three lovely but obscure (after all, it is the dns) parameters. victor whacked me into using 211 with let's encrypt certs. randy From bjorn at mork.no Fri Aug 30 23:20:49 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 30 Aug 2019 23:20:49 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: (=?utf-8?Q?=22J=C3=B3hann?= B. =?utf-8?Q?Gu=C3=B0mundsson=22's?= message of "Fri, 30 Aug 2019 19:31:05 +0000") References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: <87mufq5ozy.fsf@miraculix.mork.no> J?hann B. Gu?mundsson writes: > How on earth is having a CAA record which pin points who is allowed to > issue certificates No, it doesn't. It's merely a hint to CAs. It cannot prevent spoofed certificates if any CA is compromised, or fails to validate the CAA record for other reasons. TLS clients are unable to detect spoofed certificates using CAA, since there is no sane way to map between CA certificate and the CAA record. It depends on ultimate trust in every browser root CA. CAA is mostly smoke and mirrors. TLSA allows you to pin CA certificates or server certificates so that it can be validated by everyone. It will protect against rogue or compromised CAs. And you don't need to trust any of them. You can pin your own certificate instead. Yes, CAA is inferior. It would have been funny if it wasn't for the fact that people actually believe in this stuff. Bj?rn From bjorn at mork.no Fri Aug 30 23:33:43 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 30 Aug 2019 23:33:43 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: (Randy Bush's message of "Fri, 30 Aug 2019 13:29:42 -0700") References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: <87imqe5oeg.fsf@miraculix.mork.no> Randy Bush writes: >> Which is the reason why no major browser does TLSA validation. > > well. there is the extra protocol turn. agl tried and backed off, > seemingly because of that. I hear that. And I see them pushing DNS over HTTPS at the same time. Doesn't really compute... They are so good at making up excuses. A couple of yours ago they didn't need TLSA validation beacuse HPKP was so much better: https://www.imperialviolet.org/2015/01/17/notdane.html Where did that go? Oh, yes, turns out it wasn't such a good idea anyway: https://ordina-jworks.github.io/security/2018/02/12/HPKP-deprecated-what-now.html So now we're back to ultimate trust in the CAs again, using CT and CAA. Nice move. > but, if we want to encourage tlsa, recommended values for the three > lovely but obscure (after all, it is the dns) parameters. victor > whacked me into using 211 with let's encrypt certs. I prefer 3 1 1 for my certs, pinning my own key regardless of who else signed it. Bj?rn From johannbg at gmail.com Fri Aug 30 23:59:02 2019 From: johannbg at gmail.com (=?UTF-8?B?SsOzaGFubiBCLiBHdcOwbXVuZHNzb24=?=) Date: Fri, 30 Aug 2019 21:59:02 +0000 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: On Fri, Aug 30, 2019, 20:30 Randy Bush wrote: > > There is still too much money in the CA business. > > well, though on the surface i agree, i do not take it as a motivation to > add one more chunk of sysadmin. > > > Which is the reason why no major browser does TLSA validation. > > well. there is the extra protocol turn. agl tried and backed off, > seemingly because of that. > The problem with the added extra lookup which added more latency, which increased the chances for packet loss, causing expensive timeouts and retransmitions had been somewhat worked on but abandoned [1] and wont be revisited due to [2] being the browser community take on this afaik. Given that Let's encrypt own root which was supposed to be pushed out this July but got delayed til 2020 is widely trusted by browser, one can hardly claim that the browser community is run by some "cert cabal" If the "cert cabal" will try anything it will be to block acceptance and or usage of self and Let's encrypt signed certs with high profile cloud providers because that's where the money is and corporates are somewhat vendor locked in there, which makes them an easy pray for additional fees.. JBG 1. https://www.imperialviolet.org/2011/06/16/dnssecchrome.html 2. http://www.certificate-transparency.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sat Aug 31 14:33:09 2019 From: gert at space.net (Gert Doering) Date: Sat, 31 Aug 2019 14:33:09 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> Message-ID: <20190831123309.GG55186@Space.Net> Hi, On Fri, Aug 30, 2019 at 09:59:02PM +0000, J?hann B. Gu?mundsson wrote: > Given that Let's encrypt own root which was supposed to be pushed out this > July but got delayed til 2020 is widely trusted by browser, one can hardly > claim that the browser community is run by some "cert cabal" Well, the pieces sort of nicely fit. Push everybody to do "https everywhere!" (why not? LE is free!), and of course for *real* security companies must have EV certs from "real" CAs... for heaps of money. Money flows. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From randy at psg.com Sat Aug 31 14:59:55 2019 From: randy at psg.com (Randy Bush) Date: Sat, 31 Aug 2019 05:59:55 -0700 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <20190831123309.GG55186@Space.Net> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <874l1ysdte.fsf@miraculix.mork.no> <20190831123309.GG55186@Space.Net> Message-ID: > Push everybody to do "https everywhere!" (why not? LE is free!), and > of course for *real* security companies must have EV certs from "real" > CAs... for heaps of money. upcoming chrome and ffox will not green light ev randy From bruno.pagani at ens-lyon.org Sat Aug 31 15:09:29 2019 From: bruno.pagani at ens-lyon.org (Bruno Pagani) Date: Sat, 31 Aug 2019 15:09:29 +0200 Subject: [atlas] SSL Certificates for ripe anchors In-Reply-To: <20190830183219.GF55186@Space.Net> References: <82d32656-fe5d-17c7-4dff-0212ea8c9b60@ripe.net> <16811fdc-55e0-bc07-6500-e2d40c82c064@nic.cz> <0B3E152F-6D39-4CFD-B52F-012E91E682BD@steffann.nl> <4eef9839-28dc-e2ee-4d84-a2e66e80ceeb@gmail.com> <20190830183219.GF55186@Space.Net> Message-ID: <7384fcf3-563c-b640-4bab-24e08f54abac@ens-lyon.org> Le 30/08/2019 ? 20:32, Gert Doering a ?crit?: > Hi, > > On Fri, Aug 30, 2019 at 03:08:06PM +0000, J?hann B. Gu?mundsson wrote: >>> Yep. I wish the use of TLSA was more wide spread. It doesn't require third parties to "certify" who is who. >> The third parties that "certify" are for others to establish trust in >> that you are who you claim to be not because its "required" and the >> security industry has deemed those who do not atleast get some other >> entity to validate, not to be worthy of trust. > TLSA does all this, without requiring some other entity that follows their > own agenda to "certify" anything. You need to trust the DNS root KSK, > of course, but everything else follows the normal DNSSEC chain. Not quite true, you also need to trust your registrar, as they could change the enrolled DNSSEC key and glue records. Though this is way more visible than a rogue certificate used ponctually for some targets.?;)