By controlling the reverse tree do you mean the actual DNS zone? If so that provide no leverage for an attack. The value sent in the SNI isn’t any value retrieved from the DNS for the reverse mapping of the address, but the reverse mapping itself. If the IP being validated was 1.2.3.4 then the SNI sent would be 4.3.2.1.in-addr.arpa. This was originally suggested when Corey Bonnell pointed out that 6066 disallows literal IP addresses in the SNI HostName and Rich Salz and Richard Barnes suggested we just use the reverse mapping instead. Perhaps the text could be reworked here to clarify this further?
> On Jan 26, 2019, at 6:21 AM, Eric Rescorla <[email protected]> wrote: > > > > 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
