On Tue, Apr 23, 2019 at 10:03 PM Michael Richardson <[email protected]> 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 <[email protected]> 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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
