On Tue, Apr 23, 2019 at 10:03 PM Michael Richardson
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 suc
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 wrote:
Hi Rifaat,
Inline.
From: Rifaat Shekh-Yusef
Sent: 17 April 2019 20:37
To: Richard Barnes
Cc: IETF ACME ; Owen Friel (ofriel)
Subject: Re: Use cases / trust model for device certs
Hi Richard,
I was not aware of the ANIMA work before the meeting in Prague, so I will
definitely look into that i
On Tue, Apr 23, 2019 at 5:18 PM Michael Richardson
wrote:
> I ommited your great explanation of the situation.
> *I* think that certificates bound to IP addresses are useful for things
> like
> server management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there
> are no cloud issues involv
Ryan Sleevi wrote:
> That same logic applies here - we 'could' use a distinct ALPN method,
> in which case, omitting the IP is fine. However, including the IP
> (albeit, encoded) makes it easier to reason about, dispatch, and less
> likely to result in implementation flaws, and in
On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson
wrote:
> > In a world where IPs were possible to be validated using TLS-ALPN,
> and
> > the information omitted from the request, if evil.example/Customer B
> > can serve a certificate that confirms the response for 10.0.0.2, then
>
Ryan Sleevi wrote:
> Now, the system can already dispatched based on hostname, ensuring that
> good.example sessions are served Customer A's response, and
> evil.example sessions are served Customer B's response. The issue is
> whose response is served when there is no SNI? Under
Salz, Rich wrote:
mcr> Given that TLS would forbid SNI being present in that case, how
mcr> would such a offboard TLS termination work?
rsalz> Probably violating the RFC? "We're not the protocol police"
Okay, then just put the SNI for the challenge too :-)
--
Michael Richard
On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson
wrote:
>
> Ryan Sleevi wrote:
> > The latter only becomes a consideration if multiple IPs are
> terminated
> > at the same TLS layer, and that TLS termination layer doesn't
> consider
> > the destination IP when dispatching certifica
Given that TLS would forbid SNI being present in that case, how would such a
offboard TLS termination work?
Probably violating the RFC? "We're not the protocol police"
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/ac
Ryan Sleevi wrote:
> The latter only becomes a consideration if multiple IPs are terminated
> at the same TLS layer, and that TLS termination layer doesn't consider
> the destination IP when dispatching certificates. If we were to omit
I am curious to understand the use case for offb
Good points!
I can't speak for the draft authors here, but my understanding and
expectation was, in part in response to the concerns with tls-sni mitigated
by tls-alpn, to ensure there's a strong binding from the request to the
response, and that the binding is unambiguous.
What I mean by that is
12 matches
Mail list logo
