<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 4:25 PM, Jacob Hoffman-Andrews <span dir="ltr"><<a href="mailto:jsha@letsencrypt.org" target="_blank">jsha@letsencrypt.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>My reasoning is, like you said, related to the ease of obtaining a certificate. Specifically, allowing verification through a given port makes it possible to write software that automatically requests certificates for itself. People have already written web servers that do that. Ideally it would be possible to do the same for POP, IMAP, and the other SMTP ports.</div></div></div></div></blockquote><div><br></div><div>I'm not sure I share your goal or agree it's a good one, quite frankly, primarily because of the potential for combinatorial growth of attack surface that each port adds (note how Authorized Ports are reused in several methods of validation). Throw in protocol confusion issues, and the surface grows.</div><div><br></div><div>As discussed in the past, I still have fundamental unease and reservations about the use of non-DNS methods to obtain certificates. There are a number of ways to mitigate this in the future (which I say primarily because I don't believe it should be a reason to hold back this ballot), whether it be by restricting such certificates to SRVName certificates or mandated CAA with a means for CAA to disable some methods, but I don't share your enthusiasm for increasing the ways in which certs can be issued. This is precisely because it's already rather difficult to restrict the ways today.</div><div><br></div><div>For example, even this week, and despite doing everything reasonably possible to restrict accidental misissuance, we saw a CA issue certificates for a Google domain in a manner that complies with the Baseline Requirements, but goes against our specific, expressed, and programatically enforced wishes. The CA in particular doesn't check CAA, and used a file-based means of validation - but didn't use /.well-known/pki-validation/ to do so. The means of validation that this particular CA uses to produce the filepath is something that we, Google, simply cannot prevent while delivering our services to our users. That's not a good state.</div><div><br></div><div>Because each method introduced - and each port introduced - adds yet another attack surface that every vendor has to comprehensively attempt to defend against, I'm fairly opposed to adding new methods that don't authoritatively tie to DNS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>A related idea: What would you think of an IANA-allocated port specifically for certificate validation? That would decrease the risk that software running on that port was not authorized to request certificate issuance, and would make it possible to write a system-level service that can request certificates for various components on the system without worry about port conflicts.</div></div></div></div></blockquote><div><br></div><div>I think it's a fairly broad claim that it will "decrease the risk that software running on that port was not authorized to request certificate issuance", and think it's very unlikely to be true. Yet again, everyone would have to block that port. I would think it would be as objectionable to proposing adding a new email alias for email validation - it's precisely the kind of expansion of attack surface that we should be looking to avoid, if not outright reduce. </div></div><br></div></div>