On Thu, Jan 24, 2019 at 11:50 AM Roland Shoemaker <[email protected]> wrote:
> Comments inline: > > > On Dec 24, 2018, at 12:32 PM, Eric Rescorla <[email protected]> wrote: > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D4180 > > > > > > IMPORTANT > > S 3. > > > used to refer to fully qualified domain names. If a ACME server > > > wishes to request proof that a user controls a IPv4 or IPv6 > address > > > it MUST create an authorization with the identifier type "ip". > The > > > value field of the identifier MUST contain the textual form of the > > > address as defined in [RFC1123] Section 2.1 for IPv4 and in > [RFC4291] > > > Section 2.2 for IPv6. > > > > Are all three variants here valid? > > I think requiring the canonical representation defined in 5952 Section 4 > to be supported makes sense, but would be in favor of also allowing > supporting any of the other 4291 representations if the implementer wishes. > > > > > > > S 4. > > > For the "tls-alpn-01" the subjectAltName extension in the > validation > > > certificate MUST contain a single iPAddress which matches the > address > > > being validated. As [RFC6066] does not permit IP addresses to be > > > used in the SNI extension the server MUST instead use the IN- > > > ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the > IP > > > address as the SNI value instead of the literal IP address. > > > > What happens if an attacker forces an incorrect SNI on you here? I > > don't see any security analysis below, but I suspect it's bad, > > > > I’m not sure I understand how an attacker would force an incorrect SNI? > tls-alpn-01 requires that the server verify that the SNI that it is > provided matches what it expects. > I'm talking about an attacker who controls the reverse tree, and thus can cause the server to use an SNI of his choice. > COMMENTS > > S 6. > > > > > > 6. Security Considerations > > > > > > Given the often short delegation periods for IP addresses > provided by > > > various service providers CAs MAY want to impose shorter lifetimes > > > for certificates which contain IP identifiers. They MAY also > impose > > > > https://tools.ietf.org/rfcmarkup?doc=6919#section-6 > > > > If the WG thinks that providers ought to do this, then it should say > > so. > > > > I don’t think it makes sense for the document to mandate this as it’s not > an implementation detail but a policy one which the relevant policy > authorities (such as CABF) may dictate themselves in the future putting > this document at odds with those requirements. I don't agree. It's the IETF's job to provide a complete and clear spec. The text implies that we think that you ought to use a shorter lifetime and then the MAY totally undercuts that. This text either should be removed or you should use a SHOULD or MUST. See also https://tools.ietf.org/rfcmarkup?doc=6919#section-6 -Ekr
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
