Subject: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session

From: Andrew Campling <[email-masked]>
Date: Wed, 16 Mar 2022 16:15:28 +0000

I would like to request some time to dispatch draft-campling-ech-deployment-considerations<https://www.ietf.org/archive/id/draft-campling-ech-deployment-considerations-01.txt> at IETF 113.  The draft is intended to inject additional detail about deployment considerations relating to Encrypted Client Hello by including observations on current use cases for SNI data in a variety of contexts.  In the spirit of RFC 8890, we believe that end-user needs to be taken into account in protocol development and we hope that this document is one small step in that process.

Andrew

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 16 Mar 2022 15:44:22 -0400

Thank thank, Andrew.

Per your message to SecDispatch chairs, I’ll put you on the agenda. I think we have 3 requests and I’ll try to post an agenda soon (tonight).

Best regards,
Kathleen 

Sent from my mobile device

> On Mar 16, 2022, at 12:15 PM, Andrew Campling <[email-masked]> wrote:
> 
> 
> I would like to request some time to dispatch draft-campling-ech-deployment-considerations at IETF 113.  The draft is intended to inject additional detail about deployment considerations relating to Encrypted Client Hello by including observations on current use cases for SNI data in a variety of contexts.  In the spirit of RFC 8890, we believe that end-user needs to be taken into account in protocol development and we hope that this document is one small step in that process. 
>  
>  
> Andrew
>  
>  
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: David Schinazi <[email-masked]>
Date: Wed, 16 Mar 2022 18:01:40 -0700

Hi Andrew,

(I'm writing as an IAB member, but not representing the IAB)

Your understanding of IAB document RFC 8890 is incorrect. Encrypting the
TLS Client Hello is performed to protect end users. In particular, it is an
example of Section 4.2 "Creating User-Focused Systems" as it brings control
over information sharing closer to the end users. Additionally, ECH was the
product of Section 4.3 "Identifying Negative End-User Impact" as we have
seen abuse of user information caused by networks observing the SNI. That
section additionally references RFCs 7258 and 7624 which clearly lay out
the dangers of cleartext information and the user benefit of encryption. If
you'd like more information on the IAB's position on this topic, we also
released the following statement: <
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>.

You're welcome to raise your concerns about ECH, but they are in the
opposite of the spirit of RFC 8890. Let's discuss your draft at
secdispatch, but I can't imagine it progressing with such a clear
misunderstanding of RFC 8890.

Thanks,
David

On Wed, Mar 16, 2022 at 9:15 AM Andrew Campling
<[email-masked]> wrote:

> I would like to request some time to dispatch
> *draft-campling-ech-deployment-considerations*
> <https://www.ietf.org/archive/id/draft-campling-ech-deployment-considerations-01.txt>
> at IETF 113.  The draft is intended to inject additional detail about
> deployment considerations relating to Encrypted Client Hello by including
> observations on current use cases for SNI data in a variety of contexts.
> In the spirit of RFC 8890, we believe that end-user needs to be taken into
> account in protocol development and we hope that this document is one small
> step in that process.
>
>
> *Andrew*
>
>

---

From: Andrew Campling <[email-masked]>
Date: Thu, 17 Mar 2022 08:38:39 +0000

Hi David
Thank you for your interest in the draft.  You’re right to highlight the benefit of privacy but, as you will see when you read the draft, we highlight a range of issues that can reasonably be considered as being in the interest of end users such as security, cost and complexity.

Focusing specifically on privacy, it is of course more complex than encryption.  For example, as noted in the draft, by removing an indicator of compromise (the SNI data), a user may be at greater risk of attack from malicious content or simply by surveillance by badly behaved client software.

RFC 8890 highlights the importance of multistakeholder input in order to understand the potential trade-offs between competing factors that may impact end users.  This is an instance where such engagement would be beneficial as it will no doubt highlight other considerations to take into account.

As you conclude, let’s discuss it at Secdispatch but I believe that debate will be more useful if we avoid using such a narrow interpretation of end users' interests.

Andrew

________________________________
From: David Schinazi <[email-masked]>
Sent: Thursday, March 17, 2022 1:01 am
To: Andrew Campling <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Secdispatch] Request for a slot at the Secdispatch IETF 113 Session

Hi Andrew,

Your understanding of IAB document RFC 8890 is incorrect. Encrypting the TLS Client Hello is performed to protect end users. In particular, it is an example of Section 4.2 "Creating User-Focused Systems" as it brings control over information sharing closer to the end users. Additionally, ECH was the product of Section 4.3 "Identifying Negative End-User Impact" as we have seen abuse of user information caused by networks observing the SNI. That section additionally references RFCs 7258 and 7624 which clearly lay out the dangers of cleartext information and the user benefit of encryption. If you'd like more information on the IAB's position on this topic, we also released the following statement: <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>.

You're welcome to raise your concerns about ECH, but they are in the opposite of the spirit of RFC 8890. Let's discuss your draft at secdispatch, but I can't imagine it progressing with such a clear misunderstanding of RFC 8890.

Thanks,
David

On Wed, Mar 16, 2022 at 9:15 AM Andrew Campling <[email-masked]> wrote:
I would like to request some time to dispatch draft-campling-ech-deployment-considerations<https://www.ietf.org/archive/id/draft-campling-ech-deployment-considerations-01.txt> at IETF 113.  The draft is intended to inject additional detail about deployment considerations relating to Encrypted Client Hello by including observations on current use cases for SNI data in a variety of contexts.  In the spirit of RFC 8890, we believe that end-user needs to be taken into account in protocol development and we hope that this document is one small step in that process.

Andrew

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Mar 2022 13:17:11 +1100

I'm not going to be at SECDISPATCH, so I'll make my comments here.

First, a general comment. Andrew, you seem to be forming a habit of relying on 8890 to get air time for your arguments. That RFC's focus is on encouraging the IETF community to consider the impacts of its actions elsewhere. The only place it privileges those already active here is when it talks about civil society organisations' ability to act as a channel for engaging the broader Internet community. I don't believe you're acting in that capacity here. 

I.e., your arguments should stand on their own -- invoking 8890 doesn't reinforce them.

Now, regarding the draft -- draft-campling-ech-deployment-considerations seems to assume that the *only* viable way to scan for viruses, impose parental controls, or control access to resources is by having a network element impose it without coordination. Your draft supports this by noting that transparent proxies are used because they're easier to administer than on-endpoint software -- a viewpoint which privileges administrator convenience and cost over user safety,  and ignores other options.

The underlying problem is that such "transparent proxy" services are unauthenticated -- they rely on the user understanding that the network is going to perform these services, and accepting their imposition. They're also disproportionate, giving complete access to all data flows and capabilities on the connection.

Performing these tasks in this fashion allows not only legitimate authorities to impose them, but also illegitimate attackers. As such, they're inappropriate for deployment on the Internet, and that's why we're seeing efforts like ECH -- use of this data and the associated control channel without explicit user authorisation is not "permissionless innovation" (as your draft states), it's an open door to abuse. Put bluntly, you (as a network operator) don't have a right to "innovate" with my data (as a user) -- especially without my permission.

This doesn't reduce the urgency of meeting those goals for some users, but it does mean that they need to be met without endangering security and privacy for all users on the Internet, even if that has historically been the path of least resistance.

It also doesn't mean that the path forward will be easy. What's required is a discussion and implementation of interfaces for offloading these functions from operating systems, applications, and IoT devices -- potentially to somewhere else on the network -- in a way that maintains users' autonomy, privacy, and security, and in a proportional way (i.e., only as much access to data as required to fulfil the task). That is difficult not only because of the inherent user interface subtleties and potential for abuse/hijacking, but also because there is little current coordination or convergence at that layer.

The IETF has a very clear responsibility to assure that the protocols it ships are secure -- hence, ECH. It *could* have a role to play in responsibly offloading these functions, especially where the work intersects protocol design. There is also other work to be done that's squarely outside our scope. I'd suggest that you and your co-authors focus on assisting those positive, forward-looking efforts rather than trying to stop ECH deployment.

Cheers,

> On 17 Mar 2022, at 7:38 pm, Andrew Campling <[email-masked]> wrote:
> 
> Hi David

--
Mark Nottingham   https://www.mnot.net/

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 22 Mar 2022 05:24:05 -0400

Mark,

> On Mar 21, 2022, at 10:17 PM, Mark Nottingham <[email-masked]> wrote:
> 

No hat - 

Are there more options than Safe Browsing and endpoint solutions? There are DNS based solutions, but if DoH forces you to go to a dedicated DNS server you don’t get that filtering. It’s more helpful if the alternative options are spelled out as well as how solutions are used. Closing a security gap before other solutions are viable or in place will only exacerbate the very real problems faced by organizations and their users experiencing attacks including random ware.

Best regards,
Kathleen

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 22 Mar 2022 09:31:25 +0000

>  There are DNS based solutions, but if DoH forces you to go to a dedicated DNS server you don’t get that filtering.

Perhaps we can lower the temperature of discussion by not using such loaded terms as "DoH forces you"

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Mar 2022 02:55:13 -0700

On Tue, Mar 22, 2022 at 2:24 AM Kathleen Moriarty <
[email-masked]> wrote:

> > First, a general comment. Andrew, you seem to be forming a habit of
> relying on 8890 to get air time for your arguments. That RFC's focus is on
> encouraging the IETF community to consider the impacts of its actions
> elsewhere. The only place it privileges those already active here is when
> it talks about civil society organisations' ability to act as a channel for
> engaging the broader Internet community. I don't believe you're acting in
> that capacity here.
> >
> > Now, regarding the draft -- draft-campling-ech-deployment-considerations
> seems to assume that the *only* viable way to scan for viruses, impose
> parental controls, or control access to resources is by having a network
> element impose it without coordination. Your draft supports this by noting
> that transparent proxies are used because they're easier to administer than
> on-endpoint software -- a viewpoint which privileges administrator
> convenience and cost over user safety,  and ignores other options.
>
> No hat -
>
> Are there more options than Safe Browsing and endpoint solutions? There
> are DNS based solutions, but if DoH forces you to go to a dedicated DNS
> server you don’t get that filtering. It’s more helpful if the alternative
> options are spelled out as well as how solutions are used. Closing a
> security gap before other solutions are viable or in place will only
> exacerbate the very real problems faced by organizations and their users
> experiencing attacks including random ware.
>

I think it's a mistake to locate the incompatibility with DNS-based
filtering in DoH. Rather, it's a question of resolver selection.

Specifically, the case of interest is the one where the client uses a
different DNS server (DoH, DoT, or otherwise) than that proposed by the
network. And that disagreement happens when the network does not have
practical control over the client (because otherwise it can force the
client to use its preferred server). IOW, I don't think the question is the
technical means by which said filtering happens, but whether the network
can unilaterally impose filtering on the client.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Mar 2022 10:17:19 +0000

Hiya,

My (probably unsurprising) take on draft-campling-ech-
deployment-considerations is that it would be better if
this draft not progress nor be dispatched anywhere.

I'd like to second Mark's well-stated position below.

In addition:

- as someone who has deployed test servers that support ECH,
I find the document title misleading. The intent seems more
like "ECH considered dangerous" - if that is the case then I
think it'd be better to be clear about that.

- the draft overall seems like an attempt to second-guess
RFC8744, which is a recent (2020) IETF consensus document. I
don't think "dispatch" processes were intended for, nor
suit, handling such efforts to overturn an existing consensus
position.

- it might be interesting to consider whether or not "The
data encapsulated by ECH is of legitimate interest to on-path
security actors..." is a reasonable proposition. Given that
the SNI extension to the TLS ClientHello was not designed
with such actors in mind, that proposition seems to imply
that anything visible to on-path actors is of "legitimate
interest" to any on-path actor. While I'm unsure if the
phrase "legitimate interest" has some specific legal meaning,
I'd be very surprised if that proposition (as a general
thing) were consistent with regulatory regimes like the GDPR.

- section 3: I work in the "education sector" and my employer
does not suffer from any of the issues mentioned in this
section.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Mar 2022 11:17:40 +0100

{I wish the subject had been changed}

I found Mark's explanation very very well worded, and so I clipped parts of
it out (and top-quoted) below.  I think that

The Enterprise problem with TLS1.3 falls into this situation.
They have, up to now, imposed terminating TLS proxies on their employees,
without clearly informing them.  The problem that they have is the rise of
BYOD (and work from home, using my equipment, not theirs), and again the
problem is imposition of an unauthenticated intermediary without permission.

The argument against asking permission is that it is confusing for users.

While that is partly a UI issue, it's also because many things are occuring
which are not explicit.  The whole HTTP-Authentication vs
HTML-form-POST-authentication debate that we've come back to many times is an
example of that.  We haven't improved authentication in HTTP in a useful way,
so we continue to have authentication occuring at the wrong layer.

Mark Nottingham <[email-masked]> wrote:
    > The underlying problem is that such "transparent proxy" services are
    > unauthenticated -- they rely on the user understanding that the network
    > is going to perform these services, and accepting their
    > imposition. They're also disproportionate, giving complete access to
    > all data flows and capabilities on the connection.

...

    > Performing these tasks in this fashion allows not only legitimate
    > authorities to impose them, but also illegitimate attackers. As such,
    > they're inappropriate for deployment on the Internet, and that's why
    > we're seeing efforts like ECH -- use of this data and the associated
    > control channel without explicit user authorisation is not
    > "permissionless innovation" (as your draft states), it's an open door
    > to abuse. Put bluntly, you (as a network operator) don't have a right
    > to "innovate" with my data (as a user) -- especially without my
    > permission.

...

    > It also doesn't mean that the path forward will be easy. What's
    > required is a discussion and implementation of interfaces for
    > offloading these functions from operating systems, applications, and
    > IoT devices -- potentially to somewhere else on the network -- in a way
    > that maintains users' autonomy, privacy, and security, and in a
    > proportional way (i.e., only as much access to data as required to
    > fulfil the task). That is difficult not only because of the inherent
    > user interface subtleties and potential for abuse/hijacking, but also
    > because there is little current coordination or convergence at that
    > layer.

    > The IETF has a very clear responsibility to assure that the protocols
    > it ships are secure -- hence, ECH. It *could* have a role to play in
    > responsibly offloading these functions, especially where the work
    > intersects protocol design. There is also other work to be done that's
    > squarely outside our scope. I'd suggest that you and your co-authors
    > focus on assisting those positive, forward-looking efforts rather than
    > trying to stop ECH deployment.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-