Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5386
IMPORTANT
S 3.
> the handshake MUST contain a ALPN extension with the single
> protocol name "acme-tls/1" and a Server Name Indication [RFC6066]
> extension containing the domain name being validated.
>
> 4. Verify that the ServerHello contains a ALPN extension containing
> the value "acme-tls/1" and that the certificate returned contains
This will not work with TLS 1.3, where ALPN is in EE.
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?
COMMENTS
S 3.
> that it is returned during a TLS handshake that contains a ALPN
> extension containing the value "acme-tls/1" and a SNI extension
> containing the domain name being validated.
>
> A client responds with an empty object ({}) to acknowledge that the
> challenge is ready to be validated by the server. The base64url
This isn't really a response. It posts a message.
S 4.
> blindly agreeing to use the "acme-tls/1" protocol without actually
> understanding it.
>
> To further mitigate the risk of users claiming domain names used by
> other users on the same infrastructure hosting providers, CDNs, and
> other service providers should not allow users to provide their own
Should this be a 2119/8174 SHOULD NOT?
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
