CBOR WG Meeting IETF 106 - Singapore Thursday, Nov 21, 2019, 17:40 - 18:40 Chairs: Francesca Palombini, Jim Schaad Recordings: https://www.youtube.com/watch?v=3lJZ4dZuaPA Session's material: https://datatracker.ietf.org/meeting/106/session/cbor Minute takers: Michael Richardson * Introduction [5'] : Chairs Agenda bashing and WG status update STATUS: 6 interims since 105, lots of progress made on documents. RECHARTERING has been finalized since 105. CBOR Array Tags and CBOR SEQ are in RFCEDITOR QUEUE. CBORBIS version -09 is in WGLC, up to Dec. 12 (extra long time) Interim meetings: December 18, 2020-January 15 and 2020-Jaunary 29. Wednesday at the same time slot (16:00 to 17:00 UTC) Avoid conflict with CORE interim. Carsten: the CORE interims will also not be every two weeks, so there will be no collision. WG documents: * CBOR specification status [25'] : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis - WGLC start on 14th to run for 4 weeks - Shepherd - Francesca This document is going to Internet Standard, so not adding anything fancy. 29 issues closed since IETF105. Sean Leonard: asks about JSON situation. Jeffrey Yasskin: ask security team about JSON vulnerabilities caused by duplicate keys. Paul Hoffman: has seen situation where the duplicate replaces the original, vs ones where it ignores the other case. Jim: one of the types of cases where you can have vulnerabilities is in the COSE if you use the "critical" header parameters and you put 2, different applications could chose either one and you could have problems. CB: yes. Laurence: wrote the code Jim talked about last IETF, because COSE says "no duplicate header parameters". That duplication I want to pick up in COSE layer not in CBOR layer. CB: But you wouldn't see it in COSE because some parser would discard at CBOR layer. Laurence: Seems there is a lot variability MCR: pull parser and indefinite map, you wouldn't know if there is another key. so any ability to say to validate mean you should go to the end of the stream. You would have to process all amount of data. Very bad to say something like this. We should make recomendation if we should keep the first or the last, not a must. CB: There is no good recomendation MCR: Picking none is worse Sean Leonard: Picking none could be ok It is much more serious when the attacker can control the production of the map keys. If you ask for user supplied data, but not keys, then the "secure" can control production of keys. Henk: I am in favour of no change. I always assume that the last key is the correct key. Carsten: JSON maps are essentially indefinite, because there is no up-front size. Stuart: check RFC6763, what did it say? take the first, ignore the rest (there is precedent for that). Jeff: take the first or error would be my preference. Carsten: If you can do take the first, you can fully validate. FP: hard time reading consensus. Alexey: take first or error. I hope that No change not mean not discussed in the text. Carsten: the text discusses the problem. It says the application MUST handle this problem. Q: What are the situations. Carsten: if you turn it into a platform dictionary, processing things naively results in the last one winning. Jim: 3 choices, 1 take first, 2 error, 3 return all of them and let the application deal with it. Jeffrey: You can always check for presence before you insert, and some maps API that require you to do that, but some don't MCR: says that most lookup/dictionary/hash code will have to do a lookup to find out where to put the item, so there does not have to be 2x the work. LL: there is cases where you are not going to store the whole thing. FP: asks LL what his preferred option is? SL: if you just care if some key is present, once you get the hit you stop processing. Then the value does not matter. Pete Resnick: if we find a security problem in the field, what are we going to do? Carsten: we have already found it? Carsten: literature is full of examples of (check for duplicates?), just none have been documented for JSON. PH: we argued about this for IJSON, and decided not to allow them to be valid (punted) Alexey: if we were designing a new protocol, we would have picked one. Jeffrey: two options are: "protocols have to decide pick first or error" vs "leave that decision to application" (clarifying discussion, HUM requested) LL: whatever they do, protocols have to have the option to say "don't care". FP: if we do a change, then the change would say, "either you do not care, or if you care, you pick the first or return error" Paul suggests we do not hum here. FP: third option: do not change the processing, and make sure there is sufficient language to explain why all the options are bad. Alexey Melnikov: we have a protocol that has discovered an issue. We could make implementations that are broken to be fixed. Suggesting to add text ruling out certain choices. Jeffrey: there is a ZIP example of arbitrary choice. JS: what Michael said is true for COSE. The only place this is an issue is with the protected attributes. LL: whether or not there is a problem depends upon the protocol. LL: If you are designing a protocol that has a problem with duplicate keys then pick one method. If there is no problem, then you don't have to pick. SL: the security problem comes from whether a second software takes it from a second source material. if the first process takes the map and picks arbitrarily and passes the processes things, then there is not a problem. It's when two different decoders are used. PaulHoffman: gone down a rathole. This whole discussion is about decoders that validate. Decoders that do not validate are perfectly good decoders. We can only make it safer for decoders that validating. Jeffrey: validating decoders will error here. It's non-validating will not. The other mistake is a specification of the format that there are two possible parses of the data. PaulHoffman: are you saying that all parsers have to be validating? Jeffrey: no, we need to pick which value a non-validating parser would use LL: the duplicate detection can be done in two layers, ... but only if the decoder does not discard duplicates. If your protocol can not tolerate duplicates, then you need to use the right decoder. Jeffrey: would be happy with three results. (1) all non-validators pick the first, (2) protocols have to pick which one to pick, (3) or declare that there is no security impact. FP: the room is against "no change" option. (That is, for change) We need more discussion. Alexey Melnikov: Jeffrey please send a message to the mailing list FP: two new issues in tracker, but no discussion needed for those. Also all please do review the document. Other: * CDDL cont. - Ways forward [15'] : Carsten / Chairs 1) Alexey adds +1 to Module work Carsten says that this part is hard. 2) Computed Literals are easy says Carsten Sean Leonard, item (3) will be hard to implement. (1) and (2) are easy to implement, but will clutter specifications. Henk: claims blame for (1). Because CDDL from old world, and there are byte offsets that have to computed. Sean is in favour of syntatic suger. For (1), can we have a list where increment is implied.... or do we really need general math? Turing machine math? Henk: no... do not want too much, but it winds up going there. FP: can this be done separately from CDDL 2.0? Carsten: CDDL has defined extension points, and they can be used to do this. 3) CBOR and JSON in one spec. 4) co-ocurrence constrained FP asks for permission to share the answers, and asks for objections from those who participated in the survey. Ways forward: + start 2.0 document with the features discussed today. Paul will volunteer other people. * Flextime [10'] * Wrap-up [5'] : Chairs