+1 The WG should adopt this document. I will volunteer to help review if adopted.
On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes <[email protected]> wrote: > +1 > > This approach is a major improvement from earlier efforts at a TLS-based > challenge. It follows normal TLS processing logic much more closely, > differing only in the fact that the certificate presented has an extra > extension. Minimizing the differences w.r.t. normal behavior seems like a > good approach to avoiding the sorts of corner cases that have tripped up > earlier flavors of TLS-based challenges. > > Before this is finalized as an RFC, we should verify empirically that most > hosting providers will be secure in the presence of this challenge. But > I'm convinced that the approach in Roland's document is likely enough to > work that we should go ahead and develop a specification, which we can test > as it matures. > > --Richard > > > On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell < > [email protected]> wrote: > >> >> >> On 23/02/18 16:31, Salz, Rich wrote: >> > >> >> Here is the ID: >> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/ >> > >> > Should the WG adopt this document? >> >> Yes. >> >> Having a sufficiently secure mechanism that works on port 443 is >> a good thing in general. I'm not sure how many folks were using >> tls-sni-01 for new domains (I was) but whatever that number was, >> is I think evidence that a port 443 scheme fills a read need. >> >> I assume that if problems are found with the new mechanism >> (whether those be technical, due to odd deployments or I guess >> even cabforum politics;-) then we'd recognise that and stop >> the work. The fact that we did that to tls-sni-02 hould be >> re-assuring wrt this. >> >> If one accepts the two assertions above then adoption seems >> like a no-brainer. >> >> S. >> >> > Speak up now, we'll make a >> > consensus decision next week. Also if you are able to help work on >> > it. If adopted, I would expect this to be on the agenda for London >> > next month, even if it's just to briefly introduce it. >> > >> > >> > _______________________________________________ Acme mailing list >> > [email protected] https://www.ietf.org/mailman/listinfo/acme >> > >> >> -- >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
