Mitigating DNS fragmentation attacks

2018-10-14 Thread jsha--- via dev-security-policy
There’s a paper from 2013 outlining a fragmentation attack on DNS that allows an off-path attacker to poison certain DNS results using IP fragmentation[1]. I’ve been thinking about mitigation techniques and I’m interested in hearing what this group thinks. I've started a thread over at the

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

2018-03-14 Thread jsha--- via dev-security-policy
> So to clarify I understand this: The same problem was in the staging > environment and there where also certificates with illegal encoding issued in > staging, but you didn't notice them because no one manually validated them > with the crt.sh lint? That's correct. > Or are there

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

2018-03-13 Thread jsha--- via dev-security-policy
On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote: > I'm hoping that LE can provide more details about the change management > process and how, in light of this incident, it may change - both in terms > of automated testing and in certificate policy review. Forgot to reply to this

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

2018-03-13 Thread jsha--- via dev-security-policy
On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote: > availability of certificate linting tools - such as ZLint, x509Lint, > (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of > availability of open tools and checks. Given the industry push towards > integration of

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

2018-03-12 Thread jsha--- via dev-security-policy
On Monday, March 12, 2018 at 8:27:06 PM UTC-7, Ryan Sleevi wrote: > Also, is this the correct timestamp? For example, examining > https://crt.sh/?id=353754255=ocsp > > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > revocation time of 2018-03-12 23:58:10 UTC , but you