Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Ryan Sleevi <[e-mail]>]

On Tue, Apr 23, 2019 at 10:03 PM Michael Richardson <[e-mail]>
wrote:

>
>     mcr>     I ommited your great explanation of the situation.  *I* think
> that
>     mcr> certificates bound to IP addresses are useful for things like
> server
>     mcr> management systems (Dell DRACs, HP iLO, IBM RSA..).  As such,
> there are
>     mcr> no cloud issues involved.
>
> Ryan Sleevi <[e-mail]> wrote:
>     > I’m a bit confused by understanding how this bit fits into the
>     > discussion.
>
>     > Is the concern that the draft-acme-ip would not work for these cases,
>     > and/or that the choice and use of TLS-ALPN (or another identifier)
>     > would preclude addressing these use cases?
>
> I think your inclusion of TLS-ALPN (which would be new code, vs a few
> extra scripts, I think) makes the solution more complex that it needs to
> be,
> in order to address a use case which I've not been convinced is real.
>

I think I'm still confused, then, as it seems this thread has forked from
what it was originally discussing.

Corey's original question was in the context of including or omitting the
SNI - but it seemed uncontroversial that the protocol itself would continue
to be signaled via the ALPN method. To omit that signaling would be to
fundamentally invite security disaster.

However, it seems that's precisely your concern - that independent of the
SNI inclusion or omission, it would seem there is concern about requiring
the use of ALPN. Is that a correct understanding? If not, it would help if
you might clearly state which parts of the draft you find problematic, as I
am still missing how this ties into the concerns Corey was raising
originally.