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

From: Corey Bonnell <[email-masked]>
Date: Wed, 17 Apr 2019 01:54:51 +0000

Hello,

Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an SNI value with the in-addr/ipv6.arpa domain name corresponding to the iPAddress being validated MUST be specified. I have a concern that this requirement suffers the same problem that rendered tls-sni-01 insecure: namely, an arbitrary user on a shared hosting provider could upload an arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus circumventing any security provided by the mandatory SNI extension.

The mandatory ALPN extension prevents this from being exploited to obtain fraudulent certificates, but given how trivially the SNI requirement can be defeated in the same manner as for tls-sni-01, I don’t believe that requiring SNI provides any security value and is not necessary. If the intent for requiring the SNI extension is to convey to the TLS server that an IP address is being validated, couldn’t that similarly be accomplished by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames) requires that a SNI value be specified, so TLS servers could differentiate between challenge requests for dNSNames and iPAddress based on the presence (or absence) of the SNI extension.

Thanks,

Corey

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 17 Apr 2019 01:05:10 -0400

On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell <[email-masked]> wrote:

> Hello,
>
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an
> SNI value with the in-addr/ipv6.arpa domain name corresponding to the
> iPAddress being validated MUST be specified. I have a concern that this
> requirement suffers the same problem that rendered tls-sni-01 insecure:
> namely, an arbitrary user on a shared hosting provider could upload an
> arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus
> circumventing any security provided by the mandatory SNI extension.
>
> The mandatory ALPN extension prevents this from being exploited to obtain
> fraudulent certificates, but given how trivially the SNI requirement can be
> defeated in the same manner as for tls-sni-01, I don’t believe that
> requiring SNI provides any security value and is not necessary. If the
> intent for requiring the SNI extension is to convey to the TLS server that
> an IP address is being validated, couldn’t that similarly be accomplished
> by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames)
> requires that a SNI value be specified, so TLS servers could differentiate
> between challenge requests for dNSNames and iPAddress based on the presence
> (or absence) of the SNI extension.
>

I’m not sure I follow the attack scenario you’re describing. The value
proposition of the ALPN method is that it’s indicative that the server does
not “suffer the same problem that rendered sni-01 insecure”, precisely
because it does not allow an arbitrary user to upload an arbitrary
certificate while also responding with that ALPN identifier.

Perhaps I misunderstood your question, but with the above invariant being
the reason for the introduction of the ALPN method, if we assume it holds,
do you still have concerns?

---

From: Corey Bonnell <[email-masked]>
Date: Tue, 23 Apr 2019 01:21:24 +0000

Hi Ryan,
I suppose I should have framed my email a bit more generally as opposed to focusing specifically on the security aspects. More broadly, I'm having a hard time coming up with a reason why the SNI extension must be included at all for IP address challenges. In the normal TLS connection flow, a connection by direct IP address (not hostname) would not include the SNI extension at all, so mandating the use of the .arpa domain in the SNI is inconsistent with normal TLS processing. This inconsistency is compounded when you consider that the self-signed cert for the challenge encodes the IP address as an iPAddress SAN (and not the .arpa dNSName). I could also see someone being confused upon reading the spec and thinking that a DNS A/AAAA record lookup against the in-addr/ipv6.arpa domain must be performed and that the challenge TLS connection is to be done against the resolved IP address.

I believe it would be more consistent with normal TLS processing and less confusing to prohibit the use of SNI altogether for IP address validations. However, I'd greatly appreciate any explanations as to why it is preferable to include the SNI extension.

Thanks,
Corey

________________________________
From: Ryan Sleevi <[email-masked]>
Sent: Wednesday, April 17, 2019 1:05 AM
To: Corey Bonnell
Cc: [email-masked]
Subject: Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

I’m not sure I follow the attack scenario you’re describing. The value proposition of the ALPN method is that it’s indicative that the server does not “suffer the same problem that rendered sni-01 insecure”, precisely because it does not allow an arbitrary user to upload an arbitrary certificate while also responding with that ALPN identifier.

Perhaps I misunderstood your question, but with the above invariant being the reason for the introduction of the ALPN method, if we assume it holds, do you still have concerns?

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 Apr 2019 14:15:21 -0400

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 that in the case of tls-sni, there wasn't a strong
binding between the host name of the challenge certificate and the host
name that the certificate would be issued for (the .invalid problem).
TLS-ALPN resolves this by introducing the ALPN identifier as the protocol
signal, and thus ensures a strong binding between the SNI name and the
final certificate - ensuring it's unambiguous as to what host name will be
challenged for.

As you note, TLS prohibits the use of the IP address in SNI, and thus makes
it difficult to have a strong binding between the name that the certificate
will be issued for and the challenge certificate. This leaves two options:
introduce an alternative way to encode the challenged-for IP in the request
(which the draft does) or omit it entirely (as I believe you're proposing).
If we go with the former approach, encoding it in the request, than servers
that are dispatching the request can ensure that it's only dispatched to
the entity responsible for the IP address encoded. If we go with the latter
approach, then servers would need to ensure that the SNI-less responses can
only be provided on the particular party authorized for that IP address.

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 the
binding, it'd likely be worthy of a security consideration to specify
guidance as to how to do so safely / considerations that should be done
before enabling TLS-ALPN in the context of IP. Alternatively, if we assume
they took the necessary steps for TLS-ALPN, then encoding the domain in the
SNI allows the existing dispatch protection mechanisms to work will
continue to work.

That's, at least, how I've viewed it :)

On Mon, Apr 22, 2019 at 9:21 PM Corey Bonnell <[email-masked]> wrote:

> Hi Ryan,
> I suppose I should have framed my email a bit more generally as opposed to
> focusing specifically on the security aspects. More broadly, I'm having a
> hard time coming up with a reason why the SNI extension must be included at
> all for IP address challenges. In the normal TLS connection flow, a
> connection by direct IP address (not hostname) would not include the SNI
> extension at all, so mandating the use of the .arpa domain in the SNI is
> inconsistent with normal TLS processing. This inconsistency is compounded
> when you consider that the self-signed cert for the challenge encodes the
> IP address as an iPAddress SAN (and not the .arpa dNSName). I could also
> see someone being confused upon reading the spec and thinking that a DNS
> A/AAAA record lookup against the in-addr/ipv6.arpa domain must be performed
> and that the challenge TLS connection is to be done against the resolved IP
> address.
>
> I believe it would be more consistent with normal TLS processing and less
> confusing to prohibit the use of SNI altogether for IP address validations.
> However, I'd greatly appreciate any explanations as to why it is preferable
> to include the SNI extension.
>
> Thanks,
> Corey
>
> ------------------------------
> *From:* Ryan Sleevi <[email-masked]>
> *Sent:* Wednesday, April 17, 2019 1:05 AM
> *To:* Corey Bonnell
> *Cc:* [email-masked]
> *Subject:* Re: [Acme] SNI extension for tls-alpn-01 challenge in
> draft-ietf-acme-ip-05
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 14:28:09 -0400

Ryan Sleevi <[email-masked]> 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 offboard TLS termination by IP
address.    That would seem to involve some kind of layer-3 (destination) NAT.
Given that TLS would forbid SNI being present in that case, how would such a
offboard TLS termination work?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Apr 2019 18:35:53 +0000

Probably violating the RFC?  "We're not the protocol police"

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 Apr 2019 14:43:07 -0400

> offboard TLS termination work?

Right. I wasn't trying to suggest that such servers intended to be
responding on 'bare' IP addresses, merely that they were capable of doing
so (by virtue of the SNI absence). As commonly configured by a TLS server,
all IPs would merely be dispatched to a common 'default' host
implementation, *unless* the server used some out-of-band signaling method
to determine the 'original' IP.

In the cloud provider model, this might be multiple physical IPs all
dispatched to a same internal system. The internal system ACLs based on
hostname (the original issue with the tls-sni proposal), and thus may not
have ACLs on the 'bare hostname' form. Let's say I have 'good.example'
(Customer A) resolving to 10.0.0.2, 'evil.example' (Customer B) resolving
to 10.0.0.3, and whenever you connect, TLS termination is dispatched to an
internal service on 10.0.0.1.

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 a TLS-ALPN (no-ip) model, there's no
restrictions or requirements there; you could serve Customer A, customer B,
or neither - and none would undermine the security of TLS-ALPN (as a
validation method) or of the security properties you're trying for.

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 they could get
a certificate for Customer A's IP.

In a world where we include the to-be-validated IP in the request, and the
Cloud Provider is observing the security invariants required for TLS-ALPN
(that any hostnames to be validated have been successfully authenticated as
belonging to the customer in question), then Customer B would have to
demonstrate control, to the provider, over 2.0.0.10.in-addr.arpa in order
to get such a certificate.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 16:24:49 -0400

Salz, Rich <[email-masked]> 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 Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 16:28:46 -0400

Ryan Sleevi <[email-masked]> wrote:
    > 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 a TLS-ALPN (no-ip)
    > model, there's no restrictions or requirements there; you could serve
    > Customer A, customer B, or neither - and none would undermine the
    > security of TLS-ALPN (as a validation method) or of the security
    > properties you're trying for.

okay, I'm with you so far.

    > 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
    > they could get a certificate for Customer A's IP.

To do this requires that the cloud provider make a clear decision about what
they are going to do with SNI-less requests above.    I feel that the cloud
provider did something wrong here.

    > In a world where we include the to-be-validated IP in the request, and
    > the Cloud Provider is observing the security invariants required for
    > TLS-ALPN (that any hostnames to be validated have been successfully
    > authenticated as belonging to the customer in question), then Customer
    > B would have to demonstrate control, to the provider, over
    > 2.0.0.10.in-addr.arpa in order to get such a certificate.

I see.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 Apr 2019 16:40:12 -0400

> provider did something wrong here.

That's a not-unreasonable position to take, generally speaking, but it's
not an invariant that the TLS-ALPN method stated needed to be met. For
example, we 'could' just as well introduce yet-another-ALPN method to
indicate it's being used to validate an IP address, rather than a domain,
and then we can totally omit the IP address (encoded or otherwise) from the
TLS handshake, on the assumption that the Service Provider must be
responsible for determining the authorization scope. The use of a new ALPN
value would be explicit signalling by said Cloud Provider that they're
aware of the semantics and the security properties that need to be observed.

Fundamentally, TLS-SNI had problems because it relied on
implicit/out-of-band state to bind the request to the response (in this
case, the binding between the .acme.invalid namespace and the actual
customer namespace). As a result, the TLS terminator was not able to
dispatch or ACL appropriately. The 'main' contribution of TLS-ALPN was to
make the server explicitly signal support for the method, rather than
implicitly signal. We could have left the SNI domain as .acme.invalid and
still achieved the same security properties - however, moving it to use the
'actual' name, and only dispatch on ALPN, simply made it easier for Cloud
Providers to implement safely and securely.

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 particular, given that the draft is
reusing the ALPN tag of TLS-ALPN, observes the semantics and security
properties required of servers that 'speak' TLS-ALPN.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 17:12:15 -0400

Ryan Sleevi <[email-masked]> 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 particular, given that
    > the draft is reusing the ALPN tag of TLS-ALPN, observes the semantics
    > and security properties required of servers that 'speak' TLS-ALPN.

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 involved.

A second use case is for end-systems to get certificates for use in things
like TLS ClientCertificates.  I can see my desktop or appliances doing this
given that they might have a stable IPv6 addresses.  Few users would have
stable, public IPv4 today though.  ACME could still be used to talk to
internal CAs though.

You have a different use case, and I still don't understand it.

Maybe the document needs an applicability statement.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 23 Apr 2019 17:35:25 -0400

> are no cloud issues involved.

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?

It seems that the applicability of the protocol satisfies all of these use
cases, including internal CAs. Have I overlooked a concern with respect to
SNI and ALPN?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 22:03:56 -0400

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.

    > 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.

    > It seems that the applicability of the protocol satisfies all of these
    > use cases, including internal CAs. Have I overlooked a concern with
    > respect to SNI and ALPN?

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 24 Apr 2019 00:47:58 -0400

> 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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Apr 2019 17:23:31 +0300

On Wed, Apr 17, 2019 at 01:54:51AM +0000, Corey Bonnell wrote:
> Hello,
> 
> Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge,
> an SNI value with the in-addr/ipv6.arpa domain name corresponding to
> the iPAddress being validated MUST be specified. I have a concern
> that this requirement suffers the same problem that rendered
> tls-sni-01 insecure: namely, an arbitrary user on a shared hosting
> provider could upload an arbitrary certificate for the required
> .ip-addr/ipv6.arpa domain, thus circumventing any security provided
> by the mandatory SNI extension.
> 
> The mandatory ALPN extension prevents this from being exploited to
> obtain fraudulent certificates, but given how trivially the SNI
> requirement can be defeated in the same manner as for tls-sni-01, I
> don’t believe that requiring SNI provides any security value and is
> not necessary.

I am not sure ALPN extension prevents exploitation.

Consider TLS SNI NAT (yes, such things exist) with:

- Connections without SNI are handled in some safe way.
- Loose registration practices (which made TLS-SNI-01/02 insecure)
- No TLS termination (or customer can disable termination for their
  name).
- No support for TLS-ALPN.

Now, attacker claims the RDNS name of the IP address of the host
and sets up TLS-ALPN responder (this fails with DNS-type names).

Then attacker requests certificate for the IP address. The NAT then
sees the SNI, ignores ALPN and sends the connection to the attacker,
which can then respond with validation certificate. The authorization
passes and CA issues fradulent certificate.

The attack exploits the different SNI in requests client would send
and what validation uses (TLS-ALPN with DNS names uses the same name,
so the attack will not work). The attack against TLS-SNI also exploited
this difference (but could work even if TLS termination could not be
disabled).

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 24 Apr 2019 12:33:50 -0400

> this difference (but could work even if TLS termination could not be

Thanks Ilari!

Just to make sure - these are TLS SNI NAT based on inspecting the TLS
handshake, without actually terminating it, right? That is, it's doing the
"middlebox" thing that introduced huge amounts of complexity to deploying
TLS 1.3, and we're wanting to make sure the IP validation similarly works
around it.

The further assumption here is that these products are 'safe by default'
when omitting SNI, but are otherwise ignorant of ALPN and its semantics.

If that's roughly correct, would you agree a possible mitigation
(notwithstanding complexity concerns) 'could' be the use of a client hello
extension, echo'd by the server (thus confirming it understands the
protocol, and is not merely 'dumb' parsing but an active participant in the
TLS handshake), that indicates the IP being verified?

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Apr 2019 20:34:39 +0300

> TLS 1.3, and we're wanting to make sure the IP validation similarly works

These things are pretty transparent when it comes to TLS. They do not
need to inspect ServerHello, so they won't. They will not need to
understand most TLS extensions, so they won't. 0-RTT might break if
not taken into account.

However, this sort of thing could be much bigger headache with QUIC...

> when omitting SNI, but are otherwise ignorant of ALPN and its semantics.

Well, these need to do something sane when SNI omitted (which might be
just giving an error or sending the connection to some appropriate
default handler).

And whereever that goes is where the raw IP would go.

> TLS handshake), that indicates the IP being verified?

The server must already acknowledge the IP address being verified.

And that mitigation does not work. If the NAT does not know about
TLS-ALPN, it will not know about whatever extension that would be,
and thus just copy it through straight to attacker, who can then
freely reply.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 24 Apr 2019 13:48:24 -0400

> The server must already acknowledge the IP address being verified.

I'm not sure how this conclusion is reached. Could you help me understand
more?

> and thus just copy it through straight to attacker, who can then

I'm not sure why you say this. Your original threat model was that the TLS
SNI NAT box does something 'sensible' in the absence of SNI - and that the
attacker would not be able to terminate the handshake if SNI were absent.
If the proposal were to omit the SNI, while still making sure it's bound to
the request (via a separate extension), then as long as the TLS SNI NAT box
does the sensible thing for an SNI-less request, there's no additional
privilege.

If the issue is that the TLS SNI NAT box is *only* secure in the context of
DNS - and maybe it does something sensible absent an SNI, and maybe it's
terrible and fundamentally insecure absent an SNI - then what we're saying
is middleboxes are evil and fundamentally insecure ;)

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 25 Apr 2019 09:27:39 +0300

> I'm not sure how this conclusion is reached. Could you help me understand

The validation certificate contains the IP address being verified
in the SAN extension.

> does the sensible thing for an SNI-less request, there's no additional

What are the consequences if the server just takes that address without
checking (echoing the extension, with whatever is in it)?

TLS-ALPN with domain names is pretty robust security-wise against
servers and middleboxes doing wrong (but sensible) things.

And in CABForum BRs, fradulent IP address certificate is quite bad, as
it allows (at least in rules) getting fradulent DNS certificates for
any domain pointing to that name (due to existence of method 8).

> is middleboxes are evil and fundamentally insecure ;)

The reason for distinction between DNS and IP here is because of the
difference in how TLS-ALPN works with DNS and IP versus how clients
works with DNS and IP.

Consider TLS-SNI. That difference in behavior renders it insecure
w.r.t. such middleboxes for both DNS and IP. Yet I do not think anybody
would blame the middleboxes for this issue, they blame TLS-SNI instead.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 25 Apr 2019 07:34:17 -0400

On Thu, Apr 25, 2019 at 2:27 AM Ilari Liusvaara <[email-masked]>
wrote:

> > > > protocol, and is not merely 'dumb' parsing but an active participant
> in
> > > the

I’m still struggling to build up a cohesive threat model for your concerns.
Perhaps you can try writing one up, for folks who haven’t read this thread
- and this might help folks like me who have read this thread.

Where I struggle is that the threats seem to continually shift through each
message, but perhaps  I’m not understanding. For example, a middlebox that
blindly echoes TLS extensions means it is terminating TLS, not merely
dispatching on it. The security model of TLS-ALPN is, as discussed during
that process, fundamentally undermined if the server starts echoing the
ALPN - which is why the ALPN draft warns against it.

I’m trying to understand what “bad but legitimate” behaviors you see,
because I doubt we can, will, or should solve for “bad and violating
existing TLS invariant” behaviours. We should be careful to balance how
many hypotheticals here, as unless we have a concrete threat model, we’re
making protocol authors do unreasonable and undocumented dances.

> any domain pointing to that name (due to existence of method 8).

I think that is largely orthogonal to this discussion. There is no need for
a certificate - any “technical control” over the IP is sufficient for that
purpose. If we’re countenancing servers that don’t do something sensible
for SNI-less requests, then that’s already an issue, since CAs also aren’t
required to use TLS-ALPN.

> would blame the middleboxes for this issue, they blame TLS-SNI instead.

I’m still not confident I have a clear understanding of your concerns, and
that’s concerning if only because it sounds like you believe there are
critical, unaddressed security issues with the draft, and it’s unclear how
to move forward or address them. It appears the concerns are shifting in
the messages, but it’s entirely likely I’m missing some metapoint you’re
making.

Do you have suggestions on how to address the issues you see? That might
also help make it clearer.