On Wed, Dec 26, 2018 at 07:14:44AM -0800, Eric Rescorla wrote: > On Wed, Dec 26, 2018 at 6:56 AM Ilari Liusvaara <[email protected]> > wrote: > > > On Mon, Dec 24, 2018 at 12:47:30PM -0800, Eric Rescorla wrote: > > > > > > S 4. > > > > properly segregates control of those names to the users that own > > > > them. This means that if User A registers Host A and User B > > > > registers Host B the server should not allow a TLS request using a > > > > SNI value for Host A to be served by User B or Host B to be > > served by > > > > User A. If the server allows User B to serve this request it > > allows > > > > them to illegitimately validate control of Host A to the ACME > > server. > > > > > > Isn't this the property you say doesn't hold in S 6 below. As I > > > understand it, the rationale for this design is that people who opt in > > > to acme-tls/1 won't do this, no? > > > > No. This is a different property than one mentioned in S6. This is due > > to different SNI used. > > > > That appears to be what S 6 says as well: > > domain names they controlled (i.e. if User A registered Host A and > User B registered Host B with a service provider that User A wouldn't > be able to respond to SNI traffic for Host B). This turns out not to > > So at minimum some improved text is required here.
Oh, that text in S6 looks to be incorrect. Maybe something like (some further wordsmithing needed): When the TLS SNI challenge was designed it was assumed that a user would only be able to respond to TLS traffic via SNI for domain names they controlled (i.e. User A would only be able to register Host A if they controlled the domain name for Host A). TLS-SNI needs stronger properties than coherent FCFS registration of names for security. Specifically, it needs some mechanism that prevents the registration of validation names. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
