On Wed, Jan 10, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> I acknowledge that the TLS-SNI-02 improvements do eliminate certain risks > of the TLS-SNI-01 validation method -- and they do at least restore a > promise that the answering TLS infrastructure to which the validation > request is being made has been modified/configured/affected by the party > who requested the certificate / validation, there does remain a significant > gap. I'll discuss that below in my response to your commentary on the > state of web hosting practices. > I think it's important to point out that these levels of technical discussions are best directed to the IETF ACME WG, under the auspices of the IETF NoteWell - https://datatracker.ietf.org/wg/acme/about/ > To the extent that this is true, I harbor significant concern that > TLS-SNI-01 could responsibly return to use. > > I also see a possibility that the mitigations in TLS-SNI-02 may be > ineffective in this case. TLS-SNI-02 would prevent naive and automatic > accidental success of validations by some infrastructure, but an attacker > who can still create the proper zone in .acme.invalid and upload a custom > certificate to be served for this zone would still be able to succeed at > validation. > Can you explain what you mean by 'create a proper zone'? .invalid is an explicitly reserved TLD. > However, even that plan only actually gains security if the hosting > infrastructure would generally apply protection for heretofore unknown > names which are children of existing boarded named on another customer's > account. In other words, how likely is it that if I have a login at some > hosting company, and I have boarded on my account a hosting zone that > includes the labels www.example.com and example.com that a totally > separate > login would be allowed to prospectively create a zone called > notreallyexample.example.com? If that's likely or even non-rare, there's > still a problem with the mechanism. > > It is likely and non-rare (infact, quite common as it turns out). There are very few that match domain authorizations in some way. Note that this is further 'difficult' because it would also require cloud providers be aware of the tree-walking notion of authorization domain name. So I don't think this buys any improvement over the status quo, and actually makes it considerably more complex and failure prone, due to the cross-sectional lookups, versus the fact that .invalid is a reserved TLD. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
