Re: [Acme] AD Review: draft-ietf-acme-ip-04

[Eric Rescorla <[e-mail]>]

On Thu, Jan 24, 2019 at 11:50 AM Roland Shoemaker <[e-mail]>
wrote:

> Comments inline:
>
> > On Dec 24, 2018, at 12:32 PM, Eric Rescorla <[e-mail]> 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