Tuesday, March 22, 2022, 13:30-15:30 UTC
SAAG chairs/security ADs: Roman Danyliw, Benjamin Kaduk
Secdispatch Chairs: Kathleen Moriarty, Richard Barnes, Mohit Sethi
Summary of DISPATCH outcomes:
a. draft-ciphersuites-in-sec-syslog - Dispatched to UTA
b. draft-yee-ssh-iana-requirements - AD sponsorship
c. draft-campling-ech-deployment-considerations - No IETF work to do
d. draft-birkholz-scitt-* - BoF is needed
Joe presenting
Roman: we did check with OPSAREA, OPSAWG would potentially accept this as work.
EKR: (suggests that UTA is appropriate, TLS is not)
Rich Salz: UTA is fine, it is TLS in an application.
Seems consensus on dispatching to UTA.
Peter presenting
Roman: Seems the only way to go without CURDLE. We will commit to AD sponsorship.
(suport in the chat for this as well)
Andrew presenting
Brendan Moran: We have MASQUE WG that is focused on protecting against this. Monitoring needs to be done on the end node.
Stephen Farrell: These considerations aren’t new, they were raised in the past. This document is not useful and we should not work on it.
Tommy Pauly: All references to RFC 8890 are in conflict with its meaning (see list discussion). Not a good foundation to progress this document.
We should not prevent encryption of SNI. look at draft-iab-path-authorization (?). There are tools for parental controls et all should work.
SNI is not an effective tool
Ted Hardie: join Tommy’s view. RFC 8744 is done by TLS, they would consider it quickly and drop it. No way to tell difference between an on-path attacker and an on-path manager. No real difference between the “desired effect” and “Actual effect” on your picture slide.
Kathleen Moriarty: not arguing for this draft, but we have a problem to solve. Doing the endpoint is very difficult, we use DNS (to protect against malware).
With DoH and other methods for bypassing (our security infrastructure) is a problem. Some users rely on the schools/etc to protect them. I don’t think we should do this with SNI though.
David Schinazi: Kathleen explained problem well. Networks with little resources have to do something (for security). How does this draft help with the problem.
Andrew: This draft shows the problem, not solution.
David: in ideal case, what would you hope to get?
Andrew: More thought about the end-user problem, then find a solution.
David: you are hoping for ECH not to happen. If you were successful, that won’t help you. Technology exists and malware will (work around SNI countermeasures).
Just delays technology we want to progress.
Andrew: It’s not about stopping ECH, but become more thoughtful about how to deploy, e.g., so it does not weaken security.
Eric Rescorla: This is not “new information”. It was discussed extensively. This is the 3rd doc I see about working against (ECH and encryption).
The endusers were taken into consideration. On-path inspector without endpoint control is the issue. In Firefox, ECH is tied to DoH and disabled when enterprise deployment is detected. If you cannot do that you are indistinguishable from an on-path attacker.
As for dispatch, it would have to go to TLS.
Andrew: Some large vendors said they won’t allow ECH to be disabled.
Jonathan Hoyland: Given certs are not visible on the wire with TLS 1.3, just doing SNI doesn’t give you the ability to block “bad websites”. Unless you do something very invasive of re-terminating the connection then the ship has sailed.
Andrew: There is software using SNI widely deployed.
Jonathan: This doesn’t cover connection coalescing, so even if you kill ECH, you won’t achieve the effect you want.
dkg: This work does not belong at the IETF. I have done maintance work at schools with content filtering and yes it is a burden and you have to do it on the endpoint. You won’t block it all with SNI detection.
Andrew: (dkg, you have more experience than the average school computer admin - most can’t do endpoint protection adequately)
Tiru Reddy: Lots of relying on SNI, but malware already works around this by lying about SNI. New malware families are not stopped by SNI monitoring.
Richard: No action on the IETF for the moment.
Henk Birkholz presenting
Antoine Delignat-Lavau: several comments in the chat that this is been discussed before and why should we standarize this at IETF ? Many deployed systems (Firefox, Google, Microsoft) and no interoperability at all.
Richard Barnes: (no hat) This is a big piece of work, if it is an IETF item, it would start with a BOF. Two areas of preparation. One, focus on a very specific problem with specific architecture or interoperability problem. Second, building up the community system to build it up. Is there a need for interoperability? Would anyone ship what IETF would produce?
Henk: Do people need the interoperability?
Eric Rescorla: This will need a BOF. Higher level question is what the relevant community is. Not sure if making another one cause implementations to migrate to it? What is the Minimal Viable thing we can do? We got pretty far with CT with no meaningful (deployment? of 6992bis?)
Stephen Farrell: Richard and ekr said what I wanted to say - a BOF seems the way. It’s a good topic. It is a giant topic. Try to do something small. Could be a BOF if you get more people involved.
Dave Thaler: Richard made all points I wanted to make. Make sure there is a need for interoperability. What is the set of people which represent implementations that would actually come to the IETF to work on it.
Phillip Hallam-Baker: Support having a BOF. Relevant amount presented that is needed is small. We don’t have all the people along the chain to come together to talk. I was involved in codesigning in the 1990s. It works but hasn’t moved on from that. We sign the code distribution, not the code that runs on the machine.
dkg: Work is interesting, BOF is the way to go. What actionable outcomes there are. If we cannot get concrete actions than we spend a lot of time without a practiacal goal. Think about the interoperable actions that can be taken. Reproducable-build people have done some of this work before.
David Schinazi: This problem is very big. First dispatch step would be a bar BOF. Great you are doing that already. Next steps, you need to figure out a way to present this without my head spinning. Teasing out which parts really belong in the IETF and which don’t. Focus on what parts we need. Dont spend time yet on the solution. spend the bar bof meeting the people who are interested to come back to the list or to a BOF. Scopeing it down you can make more progress.
Kathleen Moriarty: I do support this work, would like to see not just considering scale. E.g., also support smaller organizations. Recommendation to go to a BOF if ADs agree.
Richard:
any other business? No.