Thursday, March 11, 2021, 17:00-19:00 CET (UTC+1) Chairs: Francesca Palombini (outgoing), Kathleen Moriarty, Richard Barnes, Mohit Sethi (incoming)
Original at https://codimd.ietf.org/notes-ietf-110-secdispatch Jabber: https://www.ietf.org/jabber/logs/secdispatch/2021-03-11.html Meetecho: https://meetings.conf.meetecho.com/ietf110/?group=secdispatch&short=&item=1 Minute takers: Philip Hallam-Baker, Kirsty Paine
Intro (Chairs) - 10 minutes
Mohit Sethi welcomed and thanked as new co-chair for secdispatch, taking over from Francesca. Francesca Palombini is thanked for her efforts in secdispatch, specifically for doing most of the heavy lifting for the last few meetings.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/VmFQCZGKlukgfnmgPh8ufQt_5Fo/
Martin goes through the slides. Under slide "Why?", he embellishes that Firefox uses telemetry as an example use case. "Why not?" It's not general purpose HTTP, so doesn't carry cookies between requests. Using HTTP for web browsing doesn't apply in this use case. If you don't have a basis for trusting the parties involved, i.e. the user can't trust the proxy, then this doesn't work for that use case. It's more expensive than a direct request. You are trading some security things for performance. You lose replay protection but fewer cryptographic operations.
The proxy has to not abuse its position to avoid overload. Replay attacks are possible if the proxy chooses to act in a bad fashion. You need either trust or mechanisms to be put in place to avoid this. If the server keys, which are static, all the messages can be read if the proxy makes those keys available to an attacker. Therefore, the trust in the proxy is somewhat higher than the baseline.
Why not reuse HTTP message format? HTTP/Message has dependencies between requests and responses, have to understand request to understand response.
This spec is small and self-contained, so suggests a short-lived WG.
Rich Salz: How does this relate to Chrome anonymous browsing mode? (thank you for helping with notes, Guest Stevens!)
Martin: a bunch of things do relate, where you have the ability to fetch things, more or less anonymously. This doesn't have the right set of guarantees for that work. Doing stateful pre-fetching things, which may include vulnerable resources.
David Schinazi: In favor of working on this in IETF, narrowly focused WG is right model.
Richard Barnes: 1) What is the distinction between apps for which this makes sense vs not? 2) Seems to be a range of intermediary schemes in IETF, should we group these - housekeeping between e.g. MASQUE, here so it's more understandable set of tools? Martin: This imagines a more atomic style of interaction. RB: is there a technical way to put a box around this and others, and say "it's safe"? Martin: General strategy of intermediation is being used for a number of privacy purposes, having the spread of the toolkit, identifying the pattern and being deliberate about these choices, is important. OHTTP aims to be generic and to be applied across a number of different places. I'm uncomfortable with Tommy's ODoH proposal for that reason. RB: Tor might not use it directly, but should use it directly. Support there for doing the work from Tor.
Tommy Pauly: Supportive. Of the options, having a short lived WG is the right option. Complimentary to MASQUE.
Daniel Migault: As proxy and server managed by same entity?
RB: Presumably, they are different, from clients perspective they should be. Otherwise they can collude.
Daniel Migault: Who is deploying the proxy?
Martin: Presumably an independent party selected by the client.
Eric Rescorla: Good presentation, in favor of this. Is a generalization of ODOH, can proceed with that in parallel as experimental and this be prefered way of doing it if it delivers
Kirsty Paine: On issue of replay attacks: to what extent are you aiming to mitigate these. You have to put trust in the proxy, is that a technical mitigation or a policy, chosen-by-client type mitigation?
Martin: Good question, draft mentions four. Interactions between the proxy entity and server entity are the trusted ones, requires a degree of trust but not a lot. Example, may be contractual, proxy undertakes to provide the degree of privacy required.
Kirsty: Would be useful to clarify extent to which this is out of scope. You said there are issues with overload, with replay attacks - that requests trust and is that technical or a policy mechanism?
Martin: Likey to be social constraints, might be able to do technical for replay.
Ekr: to what extent must you trust the proxy? A client would normally connect to the server. There are questions about replay and overload. Normal DDoS mitigations may not apply, because IP info is removed, so you have to trust the proxy not to DoS you. In MASQUE, it's more like Tor.
Jonathan Lennox: replay aspect - in DNS this is out of scope, is it the case here because "you don't care"? Martin: Like a simple page fetch, you might not care about replay attacks and multiple submissions. This limits what you can do with the mitigations.
Poll: Support for a short lived WG, Home to be determined by ADs. Is anyone opposed? 1/40/108
Kathleen: Outcome is short-lived WG with
Kirsty: Would a short-lived WG come with a BoF, I don’t have a good enough sense of what is in and out of scope? E.g. is discovery in scope or not.
RB: I have the tight scope in mind as proposed in first slide. Suggest including a document on security properties (bearing in mind replay issues) as well as the deliverables suggested.
Roman/AD: Need to sync with other ADs, in particular APPs.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/0P9SxOOBdKz0cPYqNi8h0H7h-3s/
Yaron Sheffer presented slides. Some use cases: you need a way to find what specific key was used for certain data, there are some needs to attribute data so you know who owns it. If access needs to be granted, there are some tools to do this. On header details: The two mandatory fields are the key manangement system - who owns the key - and a key identity, so you can hand over the right key to the key management system. Other fields are optional, e.g. to allow key rotation.
There are schemes of this sort in use (Intuit, AWS, Google) but there needs to be interopability.
He asks for a WG-forming BOF. Other ideas?
Watson Ladd: Lools like an XKCD927 issue (https://xkcd.com/927/), let's create a new standard and have everyone switch. Ekr: we have formats already that allow you to encrypt keys, and have IDs for those keys, COSE is one, CMS is another. What does this bring additionally? Yaron: COSE and CMS are different use cases. Here the risk focus is not on size (as in COSE, where every byte counts).
EKR: We should start with requirements. Does something bind this header to the contents?
Yaron: current answer is no. WG can decide to do otherwise.
EKR: Don't think we should do this without much more evidence
DKG: co-chair of OpenPGP. This seems to duplicate OpenPGP, also designed for data at rest as well as data at rest. Challenge that we need to tag information as PII, do we need to, and also how do you determine that? A lot of data is PII in aggregation. I'm dubious about the utility of this work and would like to see a gap analysis to see the problem it's trying to solve.
Yaron: Was not proposing to tag data as PII, using it as motivation to encrypt lots of data
DKG: Presentation suggested otherwise. The annotation could leak PII.
David Schinazi: Sounds like this has been solved before. Not seeing an IETF role, this is a file format, not network protocol. Without proof of interest, don't think we should move forward.
Yaron: IETF has done a lot of work not network related.
PHB: This resmbles two standards anti-patterns. One is there are 6 specifications, lets create a 7th. Another is, we have to focus on a very narrow set of concerns that only address my requirements. This does both. The results of these tend to become obstacles to standardization rather than a help
Dispatch outcome: ADs will create a new mailing list for discussion. A BoF might be correct, with reference to looking at the list of deliverables suggested by Eric Rescorla.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/TAk5H3u5CJehUB7EKAnfegxj0/
Rich Salz presents the draft on screen.
DKG: Have not read the draft, how does it correspond to non TLS uses. Esp S/MIME where Common name is used for the user name. Rich: only talks about TLS use. DKG: recommends to put it in the abstract.
Valery Smyslov: Needs to make clear it is to TLS. Rich: He can put in the abstract to use for TLS.
PHB: I like this, we should do it. Do it as AD-sponsored. Link up with CA/B forum. The existing specs obsoleted this in '97. Highly unlikely that there's something in TLS-land, with a browser especially, that's doing this - and if anything is, it'll be an old root that's probably expired. Rich: CA/B was fine with it, but please forward to it to a mailing list if you like. PHB: then you need them to agree, as they can stop every browser from doing this, they have that power. Rich: yes.
Robert Moskowitz: I like this draft, but using SAN with openssl was extremely hard on the command line historically. Using SAN without CN is hard. Rich: it was hard, but the cmd line has a flag that allows you to specify SAN. DKG and I are part of the openssl team, soon not to be part of the project. I could do a pull request to enforce it when published.
Dmitry Belyavskiy: I like this document but I think the CA/B recommendation should be included. It's current practice of CA/B forum so using this reference could be reasonable. Rich: please send me the CA/B reference.
Watson Ladd: Like this draft. The nits can be dealt with. In good shape.
Richard Barnes: Comments on the same lines - makes sense in TLS PKI structures.
DKG: Voicing support to put this in UTA. It doesn't seem to be constraining CAs, just the verifiers. What we're saying when you verify, don't look at this field. RB: I think there is a provision in the doc that does constrain the CAs. Rich: That's right but if the CA has to do it, put a CN field. We've been doing backward compatible SAN and CN fields for ~10 years.
Hannes Tschofenig: Please link to this for the IoT device folks, we've been struggling with this for years too.
Outcome: ship to UTA.
Link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/qjDScSsKpGN0mAPLBUB4YhRb-6w/
RH Presented slides.
PHB: I think we should do it! AD-sponsored. Clarification of documentation. Informational is fine and works.
Richard Barnes: I agree, straight forward piece of work.
Roman Danyliw: ecosystem question, can you give me a better sense of what implementors are hoping? RH: pi ASN.1 library, this is one of the specs missing - I had to do this to implement that. That's how this happened. I found other implementations in Github that I could pull test data from.
RH: no syntactic or semantic changes. RB: can someone review please to check that's the case.
Disptach recommendation/outcome: AD-sponsored. Roman confirms he'll pick it up.
Oblivious HTTP: short-lived WG, charter to be workshopped on the list to decide scope and whether a BoF is needed. Ciphertext format: set up a new mailing list for discussion - please contact the ADs to set this up. SAN: dispatched to UTA ASN.1 module: AD-sponsored, by Roman.