On 28/08/2017 10:15, Nick Lamb wrote:
I think that instead Ryan H is suggesting that (some) CAs are taking advantage
of multiple geographically distinct nodes to run the tests from one of the
Blessed Methods against an applicant's systems from several places on the
Internet at once. This
On Monday, August 28, 2017 at 1:15:55 AM UTC-7, Nick Lamb wrote:
> I think that instead Ryan H is suggesting that (some) CAs are taking
> advantage of multiple geographically distinct nodes to run the tests from one
> of the Blessed Methods against an applicant's systems from several places on
I think that instead Ryan H is suggesting that (some) CAs are taking advantage
of multiple geographically distinct nodes to run the tests from one of the
Blessed Methods against an applicant's systems from several places on the
Internet at once. This mitigates against attacks that are able to
On 25/8/2017 9:42 μμ, Ryan Hurst via dev-security-policy wrote:
Dimitris,
I think it is not accurate to characterize this as being outside of the CAs
controls. Several CAs utilize multiple network perspectives and consensus to
mitigate these risks. While this is not a total solution it is
Dimitris,
I think it is not accurate to characterize this as being outside of the CAs
controls. Several CAs utilize multiple network perspectives and consensus to
mitigate these risks. While this is not a total solution it is fairly effective
if the consensus pool is well thought out.
Ryan
On
On 26/7/2017 3:38 πμ, Matthew Hardeman via dev-security-policy wrote:
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5,birg...@princeton.edu wrote:
We have been considering research in this direction. PEERING controls several
ASNs and may let us use them more liberally with some convincing. We
On Tuesday, July 25, 2017 at 1:00:39 PM UTC-5, birg...@princeton.edu wrote:
> We have been considering research in this direction. PEERING controls several
> ASNs and may let us use them more liberally with some convincing. We also
> have the ASN from Princeton that could be used with
On Monday, July 24, 2017 at 5:31:33 AM UTC-7, Jakob Bohm wrote:
> On 22/07/2017 02:38, birge...@princeton.edu wrote:
> > On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
> >> It seems that a group of Princeton researchers just presented a live
> >> theoretical* misissuance by
On Monday, July 24, 2017 at 2:49:20 AM UTC-5, Gervase Markham wrote:
> On 20/07/17 21:31, Ryan Sleevi wrote:
> > Broadly, yes, but there's unfortunately a shade of IP issues that make it
> > more difficult to contribute as directly as Gerv proposed. Gerv may accept
> > any changes to the Mozilla
On 22/07/2017 02:38, birge...@princeton.edu wrote:
On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
It seems that a group of Princeton researchers just presented a live
theoretical* misissuance by Let's Encrypt.
They did a sub-prefix hijack via a technique other than
On 20/07/17 21:31, Ryan Sleevi wrote:
> Broadly, yes, but there's unfortunately a shade of IP issues that make it
> more difficult to contribute as directly as Gerv proposed. Gerv may accept
> any changes to the Mozilla side, but if the goal is to modify the Baseline
> Requirements, you'd need to
On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
> It seems that a group of Princeton researchers just presented a live
> theoretical* misissuance by Let's Encrypt.
>
> They did a sub-prefix hijack via a technique other than those I described
> here and achieved issuance
It seems that a group of Princeton researchers just presented a live
theoretical* misissuance by Let's Encrypt.
They did a sub-prefix hijack via a technique other than those I described here
and achieved issuance while passing-through traffic for other destination
within the IP space of the
On Thursday, July 20, 2017 at 3:32:29 PM UTC-5, Ryan Sleevi wrote:
> Broadly, yes, but there's unfortunately a shade of IP issues that make it
> more difficult to contribute as directly as Gerv proposed. Gerv may accept
> any changes to the Mozilla side, but if the goal is to modify the Baseline
On Thursday, July 20, 2017 at 8:13:23 PM UTC-5, Nick Lamb wrote:
> On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote:
> > As easily as that, one could definitely get a certificate issued without
> > breaking most of the internet, without leaving much of a trace, and without
> >
On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote:
> As easily as that, one could definitely get a certificate issued without
> breaking most of the internet, without leaving much of a trace, and without
> failing domain validation.
One trace this would leave, if done using Let's
On Thu, Jul 20, 2017 at 8:13 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> My purpose in writing this was to illustrate just how easily someone with
> quite modest resources and the right skill set can presently overcome the
> technical checks of
One (Hypothetical) Concrete Example of a Practical DNS Validation Attack:
(Author's note: I've chosen for this example to utilize the Let's Encrypt CA
as the Certificate Authority involved and I have chosen as a target for
improper validation the domain eff.org. Neither of these is in any way
On Thursday, July 20, 2017 at 9:39:40 AM UTC-5, Gervase Markham wrote:
> Your point, in the abstract, is a reasonable one, but so is your further
> point about trade-offs. The only way we can really make progress is for
> you to propose specific changes to the language, and we can then discuss
>
On 20/07/2017 16:39, Gervase Markham wrote:
On 18/07/17 17:51, Matthew Hardeman wrote:
The broader point I wish to make is that much can be done do improve the
strength of the various subset of the 10 methods which do rely solely on
network reliant automated validation methodologies. The
On 18/07/17 17:51, Matthew Hardeman wrote:
> The broader point I wish to make is that much can be done do improve the
> strength of the various subset of the 10 methods which do rely solely on
> network reliant automated validation methodologies. The upside would be a
> significant,
> Yes, however I don't think Matthew's concern was about systems owned by the
> CA but rather systems proximate to them in the network. For example if the CA
> purchases Internet service from a single local Internet Service Provider, the
> BRs obviously don't require that this ISP have all the
On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm wrote:
> 1. I believe (though others may know better) that the high general
>requirements for the security of CA systems also apply to the
>systems performing the validation procedures in question.
Yes, however I don't think Matthew's
Many of the concerns you list below are already covered in different
ways.
1. I believe (though others may know better) that the high general
requirements for the security of CA systems also apply to the
systems performing the validation procedures in question.
2. For all DV (Domain
Hi all,
I was just reading through the baseline requirements -- specifically 3.2.2.4
and its children -- and noted that while there are particular standards as to
the blessed methods of validation of authority & control for domain names (and
host names within domain names), there is nothing
25 matches
Mail list logo
