From nobody Fri Mar 1 13:39:22 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E29130F3A for ; Fri, 1 Mar 2019 13:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx4sLF1BoeHK for ; Fri, 1 Mar 2019 13:39:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A365D130FCD for ; Fri, 1 Mar 2019 13:39:10 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21Ld6Nk014254 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 15:39:09 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551476349; bh=JKjIQ9v7Z03ros1RwBo1D1sY72jXKACuyqMjA5rmnPw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=MbLLfnjToSAYUuf1xqYKWaeUB1Ys6OOHLwVXOo2aVVs08LQvOJkz1TozimXq7zDmM Io/eCGoA64KUn2sZbbl97MF7X+xiK1uF96sujYRp062Pnz/arBoFk+Ba5SkyZ/1FQP FfNWA/oTtM6W94OCtlYS7Cm+YNuj1q9bFTuhHdtM= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <80FC1A6B-CF74-4A4D-A202-913AD8D59D2A@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_74D76765-7A59-4DCE-84C2-E9B58C944848"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 15:39:05 -0600 In-Reply-To: <2c4399b6-69e1-d21d-a58d-972eb035a66c@matroska.org> Cc: cellar@ietf.org To: Steve Lhomme References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> <2c4399b6-69e1-d21d-a58d-972eb035a66c@matroska.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:39:22 -0000 --Apple-Mail=_74D76765-7A59-4DCE-84C2-E9B58C944848 Content-Type: multipart/alternative; boundary="Apple-Mail=_3A363E66-1F92-4995-9362-9D7BD6929EC9" --Apple-Mail=_3A363E66-1F92-4995-9362-9D7BD6929EC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, apologies for the delay. Catching up on the comments below. I=E2=80=99= m skipping the comments with =E2=80=9CDone in github=E2=80=9D responses = until I can review the draft update, which I will start in a few = minutes. Thanks! Ben. > On Jan 19, 2019, at 3:30 AM, Steve Lhomme = wrote: >=20 > Hi Ben, >=20 > On 07/01/2019 22:14, Ben Campbell wrote: >> Hi, >>=20 >> This is my AD Evaluation of draft-ietf-cellar-ebml-08. >>=20 >> Thanks for this work. It's generally on the right track, but I have a = number of comments that I would like to discuss prior progressing. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> *** Substantive Comments *** >>=20 >> - The Shepherd Report says "There are minor nits to be resolved = (adding one RFC 2119 keyword and some schema attributes which = are mentioned but not defined." >>=20 >> Do that comment still apply? To be clear, those are more than nits. = Adding a 2119 keyword is substantive change that needs to be agreed to = but the working group. >=20 > I don't understand this. RFC2119 has been mentioned in the header and = a link is generated at the bottom of the document since 2016. I don't = think we should include the whole document, so what is missing ? The document shepherd will need to answer this, since it is a shepherd = review comment. But I assumed that by =E2=80=9C2119 keyword=E2=80=9D he = meant that there was some normative language in the form of a a MUST, = SHOULD, MAY, etc was needed somewhere in the document. That is what I = mean by it being a substantive change. Also, I don=E2=80=99t know if the comment is still applicable; again the = shepherd would need to answer. >=20 >> Undefined attributes suggest that the draft is incomplete. If the = comment is still accurate, then these need to be fixed prior to = progressing the draft. If it is not accurate, then I ask the shepherd to = please update the shepherd report. >=20 > Which attributes are mentioned but not defined ? All the "attribute" = mentions I see in the text are all attributes described further in their = own section. Again, the draft shepherd will need to answer that. It=E2=80=99s = possible these were comments on an earlier revision that may have been = resolved. The point of my questions was to make sure that was the case = before moving forward. >=20 >>=20 >> - I'm a little surprised to see the draft describe EBML as a general = purpose markup language format, as opposed to one designed to be used by = Matroska and similar technologies. I suspect others will also be = surprised during the IETF LC and IESG review. The review bar is higher = for the IETF to recommend EBML as a general purpose markup language than = it is to recommend it for specific purposes. I also note that the CELLAR = charter talks about EBML in terms of being used by Matroska and FFV1. >=20 > It's actually not used in FFV1, only Matroska. But we are aware of = other people using EBML for other purposes/formats and some considering = to use it. >=20 >> Would it be acceptable to add some scoping language to the effect of = "EBML is used by Matroska[citation] and FFV1[citation]. It MAY be used = for use cases similar to those. The applicability of EBML for other use = cases is beyond the scope of this document". >=20 > Yes, (apart from the FFV1 part). > Done in this PR = https://github.com/Matroska-Org/ebml-specification/pull/199 = >=20 >>=20 >> - There are several defined elements/attributes related to = versioning, but I don't find an explanation of how they all work = together. Please add a section describing versioning in general. >=20 > Done in PR https://github.com/Matroska-Org/ebml-specification/pull/200 >=20 >>=20 >> =C2=A72: Please use the newer boilerplate from RFC 8174. >=20 > Done in PR https://github.com/Matroska-Org/ebml-specification/pull/201 >=20 >>=20 >> =C2=A73: Can you offer guidance on the specific impacts of the = mentioned attacks, and how to mitigate them? (If there is no way to = mitigate an attack, it's okay to say that.) >=20 > Partially covered by = https://github.com/Matroska-Org/ebml-specification/pull/202 > I'm not sure how to mitigate side channels errors, or rather if we = have to go in deep details for each (it could go very deep on all kinds = of security things). >>=20 >> =C2=A75: Please elaborate on how this is similar to UTF8. I assume = this refers to using prefix bits to indicate the field length. UTF8 does = that to maintain backwards compatibility with Ascii. What is the design = motivation for using that approach for EBML, which I presume doesn't = have such a requirement? >=20 > Done in https://github.com/Matroska-Org/ebml-specification/pull/203 >=20 >=20 >>=20 >> =C2=A75.3: "If the number of bits required for "VINT_DATA" >> are less than the bit size of "VINT_DATA", then "VINT_DATA" SHOULD be >> zero-padded to the left to a size that fits." >>=20 >> Why not MUST? What happens if this is violated? >=20 > Done in https://github.com/Matroska-Org/ebml-specification/pull/204 >=20 > I'll try to continue with the rest ASAP >=20 > Thanks a lot for all your comments. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_3A363E66-1F92-4995-9362-9D7BD6929EC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = apologies for the delay. Catching up on the comments below. I=E2=80=99m = skipping the comments with =E2=80=9CDone in github=E2=80=9D responses = until I can review the draft update, which I will start in a few = minutes.

Thanks!

Ben.

On Jan 19, 2019, at 3:30 AM, = Steve Lhomme <slhomme@matroska.org> wrote:

Hi = Ben,

On 07/01/2019 22:14, Ben Campbell = wrote:
Hi,

This is my AD Evaluation of = draft-ietf-cellar-ebml-08.

Thanks for this = work. It's generally on the right track, but I have a number of comments = that I would like to discuss prior progressing.

Thanks!

Ben.

*** Substantive Comments ***

- = The Shepherd Report says "There are minor nits to be resolved (adding = one RFC 2119 keyword and some <element>schema  attributes = which are mentioned but not defined."

Do = that comment still apply? To be clear, those are more than nits. Adding = a 2119 keyword is substantive change that needs to be agreed to but the = working group.

I don't = understand this. RFC2119 has been mentioned in the header and a link is = generated at the bottom of the document since 2016. I don't think we = should include the whole document, so what is missing ?

The = document shepherd will need to answer this, since it is a shepherd = review comment. But I assumed that by =E2=80=9C2119 keyword=E2=80=9D he = meant that there was some normative language in the form of a a MUST, = SHOULD, MAY, etc was needed somewhere in the document. That is what I = mean by it being a substantive change.

Also, I don=E2=80=99t know if the comment is still = applicable; again the shepherd would need to answer.



 Undefined attributes suggest that the draft is = incomplete. If the comment is still accurate, then these need to be = fixed prior to progressing the draft. If it is not accurate, then I ask = the shepherd to please update the shepherd report.

Which attributes are mentioned = but not defined ? All the "attribute" mentions I see in the text are all = attributes described further in their own section.

Again, = the draft shepherd will need to answer that. It=E2=80=99s possible these = were comments on an earlier revision that may have been resolved. The = point of my questions was to make sure that was the case before moving = forward.




- I'm a = little surprised to see the draft describe EBML as a general purpose = markup language format, as opposed to one designed to be used by = Matroska and similar technologies. I suspect others will also be = surprised during the IETF LC and IESG review. The review bar is higher = for the IETF to recommend EBML as a general purpose markup language than = it is to recommend it for specific purposes. I also note that the CELLAR = charter talks about EBML in terms of being used by Matroska and FFV1.

It's actually not used in FFV1, = only Matroska. But we are aware of other people using EBML for other = purposes/formats and some considering to use it.

Would it be acceptable = to add some scoping language to the effect of "EBML is used by = Matroska[citation] and FFV1[citation]. It MAY be used for use cases = similar to those. The applicability of EBML for other use cases is = beyond the scope of this document".

Yes, (apart from the FFV1 part).
Done in this = PR https://github.com/Matroska-Org/ebml-specification/pull/199=



- There are several defined elements/attributes related to = versioning, but I don't find an explanation of how they all work = together. Please add a section describing versioning in general.

Done in PR https://github.com/Matroska-Org/ebml-specification/pull/200=


=C2=A72: Please use the newer boilerplate from RFC 8174.

Done in PR https://github.com/Matroska-Org/ebml-specification/pull/201=


=C2=A73: Can you offer guidance on the specific impacts of = the mentioned attacks, and how to mitigate them? (If there is no way to = mitigate an attack, it's okay to say that.)
Partially covered by https://github.com/Matroska-Org/ebml-specification/pull/202=
I'm not sure how to mitigate side channels errors, or = rather if we have to go in deep details for each (it could go very deep = on all kinds of security things).

=C2=A75: Please elaborate on how this is = similar to UTF8. I assume this refers to using prefix bits to indicate = the field length. UTF8 does that to maintain backwards compatibility = with Ascii. What is the design motivation for using that approach for = EBML, which I presume doesn't have such a requirement?

Done in https://github.com/Matroska-Org/ebml-specification/pull/203=



=C2=A75.3: "If the number of bits required for = "VINT_DATA"
are less than the bit size of "VINT_DATA", = then "VINT_DATA" SHOULD be
zero-padded to the left to a = size that fits."

Why not MUST? What happens = if this is violated?

Done in = https://github.com/Matroska-Org/ebml-specification/pull/204=

I'll try to continue with the rest ASAP

Thanks a lot for all your comments.

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_3A363E66-1F92-4995-9362-9D7BD6929EC9-- --Apple-Mail=_74D76765-7A59-4DCE-84C2-E9B58C944848 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx5pnkACgkQgFZKbJXz 1A1fQhAAhweJxR+OhGmCMtPg0QMISHsrXs4iCavQi3Nygof+aemtFnHI+G1dGM4c qBU6AZsiZ3ZCzFhHLSRQx6acN3cBDmGdgtZ8Z5fX6TRFD5qpAQTmHxLDz3VqlV9s dou90FfdHg8yauhksxNyY0otu2RqAlsHSnKBWAiTNrG1L9lI3lR7IJ7Z3+c0ro3g F21xQRjdUixybtc2gcDVy/6lYWT+pbGBZF0kTl9L5OBlEWYwli0EzStBN8b/fiyj satcHXkMMqZoZFNKpFTO8HocgoQ6GYgR+touiw/CgiZ1vHuvkbPiOT11YUuQpgMk M8gawZb2q2pce8Rd+wvA8DV3pgl+Nq2zHtGSo3zNP2+Yrujhm90z+5EBwgQW1vhV wYFhj5gG/BjFuZitrYh0uZSIOLfqzpvF6P7t31abPYZ/e2iThz+3qrhXtXC5PqfQ UMd1kJwGoSP7THHIuHgJ7L+cE+t4aSZbfour6SV624jVAGU9y1s/KXcNjNYXE/js zzOTjM+XOtwb+y2CfuUQGx0K2laaZJuOaa2/ibLI4J0ayxcNmNZOlLnOzoc1eFHW e3rZ9ME/MmuC3+KUssR7F0Vxjn7zS9GWXw/0EPPota+cCypG/v8MWkKhv9k/VEOC 3Dbl6Z3tXUUUD3yWyHjcUs7Pt8UD1gTi72usRFoxez0XqF8OH60= =IgK3 -----END PGP SIGNATURE----- --Apple-Mail=_74D76765-7A59-4DCE-84C2-E9B58C944848-- From nobody Fri Mar 1 14:02:16 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD59129524; Fri, 1 Mar 2019 14:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znoeCYmgOZdz; Fri, 1 Mar 2019 14:02:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F406B128766; Fri, 1 Mar 2019 14:02:11 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21M28UD018178 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 16:02:10 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551477731; bh=R3oAC6Xk+BcbD8sow3dP5iwePTWXgVQSwVreOfDK0+I=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=q0IIzZ1sDfAWIBCk2ogZCul2QYEPMrUS0iYvlkFiZbYqULZHWWWuyRmUhSYMO7w0y 4U7j7wdLYxxz2lr9kUiU4hxNhzNta5SL714a/aYBPJJyY0Xigoe8DqwEG76mNY00V4 FNPVyppxxIBoDgm6orKuDsuJqaWrwDdRty/4YRGc= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <151ED0F0-28DB-46E4-836C-8743F523E8F5@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A37293E7-6DE7-4E57-8AA5-E861A1D59C1A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 16:02:07 -0600 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-ebml.all@ietf.org To: Steve Lhomme References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 22:02:15 -0000 --Apple-Mail=_A37293E7-6DE7-4E57-8AA5-E861A1D59C1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 27, 2019, at 9:31 AM, Steve Lhomme = wrote: >=20 > Hi,Some more comments on the comments: >=20 > Le lun. 7 janv. 2019 =C3=A0 22:15, Ben Campbell a = =C3=A9crit : >>>> Hi, >>> This is my AD Evaluation of draft-ietf-cellar-ebml-08. >>> Thanks for this work. It's generally on the right track, but I have = a number of comments that I would like to discuss prior progressing. >>> Thanks! >>> Ben. >>> *** Substantive Comments *** >>> =C2=A76: >> - "The "VINT_DATA" component of the "Element ID" MUST >> NOT be either defined or written as either all zero values or all one >> values." >> Why? >=20 > There is no technical reason why these values can't be used. For > example VINT_DATA all set to 0 is valid for the Element Size (and all > ones has a special meaning). These are rather reserved values that may > help expand EBML one day if necessary. Should we call them reserved > rather than invalid ? I think =E2=80=9Creserved=E2=80=9D would make more sense. >=20 >> =C2=A78.7: "In this case, the "EBML Reader" should skip data >> until a valid..." >> Should that be a normative statement? If so, why should and not MUST? >=20 > It can't be a MUST if we tolerate values to be there, someone might > want to make use of these data. It could also be data that have been > damaged and don't appear as EBML Elements anymore. In that case the > reader should do its best to skip over these data. In any case the > behaviour of the reader when such data is found not normative. Thanks, I think some text to that effect in the document would be = helpful. >=20 >> =C2=A78.8: If the EBML reader does not interpret Binary Elements, why = add them at all? What does interpret them? is the point that the EBML = reader treats Binary Elements as opaque, and just hands them to the = application? >=20 > Yes, it's exactly that. Binary is a blob that is unknown to the EBML > Reader. Only an app that knows the particular Element in the DocType > can interpret what is in this blob. Okay. It might be helpful to mention they are handed to the application. >=20 >> =C2=A710.1.3: "NOT RECOMMENDED" seems overly strong, especially in = light of the MAY in the first paragraph. Is the point to say "MUST = NOT... except when the implementation needs to update an element without = rewriting the entire document"? >=20 > The MAY means zeros can be added after a string, but one shouldn't do > that. > The NOT RECOMMENDED also says that it shouldn't be used unless > you know what you're doing (the definition of NOT RECOMMENDED).Should > we rephrase the paragraph ? Saying that use Null terminated should not > be used in general but must be handled by a Reader because it's a > possibility ? I think the problem is in the normative MAY, which effectively says = it=E2=80=99s okay, which conflicts with the NOT RECOMMENDED, which says = that it=E2=80=99s not okay unless you fully understand the consequences = and have a really good reason. Perhaps the MAY was intended as a statement of fact? That is, doing this = is NOT RECOMMENDED, but since some implementations might do it anyway a = reader SHOULD/MUST be able to handle it? [=E2=80=A6] >=20 >> =C2=A713.1: "The "DocType" >> value for an "EBML Document Type" SHOULD be unique and persistent." >>> What is the scope of uniqueness? How should it be achieved? Is there = an expectation to register Document Types? (Also, why not MUST)? >=20 > There is a IANA registry and it MUST be unique (see 15.2 CELLAR EBML > DocType Registry), although if people use the same separately string > separately without going through IANA registration, it's possible they > won't be unique. That being said I think it should be a MUST. If there is a registry, then that would normally avoid collision = problems without needing a separate normative statement about = uniqueness. Is there a requirement that all DocTypes be registered? >=20 > See Pull Request = #213https://github.com/Matroska-Org/ebml-specification/pull/213 >=20 >> =C2=A713.1.4.1: Are there uniqueness requirements for name? >=20 > No, it's a human readable name that's only there for readability. > never ends up in the actual EBML data. The same name could be found in > different path for example. Okay. >=20 >> =C2=A713.1.4.2: >> - The idea behind "path" needs elaboration. I'd like to see some = high-level discussion of how you indicate where an element is allowed, = and how you encode the structure. >=20 > I don't understand what you mean. I am deferring this one until I can look at the update. The example = might be sufficient to resolve my concern. >=20 >> An example (local to the section) would be helpful. >=20 > Added in Pull Request #214 > https://github.com/Matroska-Org/ebml-specification/pull/214 >=20 >> =C2=A713.1.4.4: >> - "The "minOccurs" value MUST be >> equal to the "EBMLMinOccurrence" value of the "path"." >>> Why have both if they have to be the same? (Same question for = =C2=A713.1.4.5) >=20 > EBMLMinOccurrence is just a coded name in the path definition. It's > not found in the path itself. Whereas minOccurs is found in the XML > Schema describing the format.The former has a long name to make it > clearer what it does in this context. The latter has a short name to > be more readable and is always found in its context anyway. This goes back to my comment about elaborating the use of Path. I will = check the example. [=E2=80=A6] >=20 >=20 >> =C2=A713.1.10: >> - Please state (and cite) which XML schema format is used here. >>> - Has the schema been mechanically verified? >=20 > I'm not competent on that one (I suppose Dave or Jerome have used it = ?) This depends on which schema format is being used. >=20 >> =C2=A713.3.1: >> - "The CRC value MUST be computed on a little >> endian bitstream and MUST use little endian storage." >>> Please elaborate. Most elements have been big-endian so far. Do = there have to be converted to calculate the CRC? >=20 > The EBML headers and integers are in Big Endian. But the Binary data > can be anything. For convenience with modern CPUs the CRC-32 is done > on little endian reading of the EBML header+data and stored as such.I > can't access the ISO spec, but the ITU one doesn't mention anything > about endianess. >=20 =E2=80=9CConvenience with modern CPUs=E2=80=9D explains why the CRC = needs to be little-endian. But it would be useful to have an explanation = why byte order is not consistent for all aspects. (=E2=80=9CHistorical = reasons=E2=80=9D is a perfectly good answer, but if that is the answer = it would be good to say so.) >> =C2=A715.1: >> - "The numbers 0x3FFF and 0x4000 are RESERVED.", "The numbers = 0x1FFFFF and 0x200000 are RESERVED.", and "The numbers 0xFFFFFFF and = 0x1000000 are RESERVED." >> What is the purpose of reserving them? >=20 > The answer can be found here > = https://github.com/Matroska-Org/ebml-specification/pull/179#discussion_r19= 6481366 > There are invalid values, but that's not a word used for IANA > registration. Should we mention that they are invalid anyway ? So they can never be valid? Is there a potential that a revision to EMBL = could use them? >=20 >> =C2=A715.2: >> - "The strings may be allocated according to >> First Come First Served" >>=20 >> Is there a requirement to register them, or is this optional? >=20 > We can't force people to do it, but it's encouraged. We can=E2=80=99t force people to do anything. But saying =E2=80=9Cmay be = allocated=E2=80=A6=E2=80=9D makes it look completely optional. And = it=E2=80=99s pretty common to see language along the lines of =E2=80=9CMUS= T be registered=E2=80=9D in other RFCs, to strongly discourage = code-point squatting. --Apple-Mail=_A37293E7-6DE7-4E57-8AA5-E861A1D59C1A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx5q98ACgkQgFZKbJXz 1A3Avg//cU8aJkzYIjd1huAQLMp5/2hGN7oivkSnB7ip+gZDjS/MAS685pk5PPU+ XVFF76xicPveXyr4EUe3CBf97DYkvnJYnWtUphph5PzXqn5QKzUCILrT5bq4TmG5 tNt1qD4YfGneOaE2j23f12CyXOMDBhwCDmVcTYjpVW+yXNNpz3wxMTZ3/dbleaMO Yf/4m70djZJhwTFJvXP42/hjzu9XnMlC1KcUqMb4hfHTupy6auakob5p/xn+OkbN FPVRptCkc2xpuS2A885cvdft99scPExQT8JeiXFdWICkQVukvWYFSx+C1GwaMaM0 zOWRqXLq3ywAGTG+ISlqGjFNVPb01+X7b/dRwL59dXQPfODbDo6jwPMwGE7Vsx7D gk8RUieja2BKhP6Jv+MoeX3ZP8JVvzVMKvmHq/zVBmNNrt+37vzKWvNi3OiQHAVE DivXuKFeTdYYM0U8BqHPgaH4RyGEZ+ZEG4bIQ33gkRcsh8njvd0O/oSvbQOMbJ3p x6a+OBlWVLlg6e5xyyzY9duZOayG7iE8Et1VdZhQRYXGTsRKfAxBEOLZf0e6TVE6 8dbD4Wgsn2aAP6oLnCHJ12exqR/Ff6eAsW+ZUQGWOdx+O+TU3e6x4xuHX6200W4l B8C3PtIZ6JwzQrLGXAayIU2w3r9drsCpNj4gy/y5ESg/FcvxVpo= =1rbj -----END PGP SIGNATURE----- --Apple-Mail=_A37293E7-6DE7-4E57-8AA5-E861A1D59C1A-- From nobody Fri Mar 1 14:11:52 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96AF128766; Fri, 1 Mar 2019 14:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRp40t6m7XWQ; Fri, 1 Mar 2019 14:11:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0335F128D52; Fri, 1 Mar 2019 14:11:48 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21MBkDx019815 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 16:11:47 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551478308; bh=qsZr1zcQGSwYN5YK35MJo732rfzQcdlCc/Wq5PRuLwA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=M/PB4WEuV14qWapvKexZLhJ1YMeG/Uwb0n/cmO46kRmvGopL6o79/ANoTm79v+Bm6 pCvzdDIq9Op1a2+K884Z4b/7+pOxKLTdftucYns4umNBbxwe9Cf2QW3ZQgSZ/qUa3Y njH/N0UUdRA1vY8WGoUSCoXiw7STykuAdxvveP1s= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6034836A-898C-41BB-8D47-0B4E48D80359"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 16:11:45 -0600 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-ebml.all@ietf.org To: Steve Lhomme References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 22:11:51 -0000 --Apple-Mail=_6034836A-898C-41BB-8D47-0B4E48D80359 Content-Type: multipart/alternative; boundary="Apple-Mail=_7897CC02-6DEA-46A4-A073-579BE0894457" --Apple-Mail=_7897CC02-6DEA-46A4-A073-579BE0894457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 27, 2019, at 9:48 AM, Steve Lhomme = wrote: >=20 > More: > Le lun. 7 janv. 2019 =C3=A0 22:15, Ben Campbell a = =C3=A9crit : >=20 >> *** Editorial Comments and Nits *** >>=20 >> - General: The draft puts double quotes around every mention of terms = that it defines. That is unconventional for IETF documents. I personally = find that it makes the draft harder to read. I suggest quoting them on = the first mention, then just capitalizing them in subsequent mentions. >=20 > I suppose you don't mean full capital letters ? The idea is that if > you read a particular section and not the whole document you can still > understand what is internal terms or generic names. No, I meant writing in the form of proper names. But to be clear, I find the use of double-quotes everywhere to create = visual noise that makes the document hard to read. >=20 >=20 >> =C2=A711.1: >> - Is the concept of a file concrete (in the sense of a unit of = persistent storage) or abstract (as in any stream of data)? I had = assumed the latter, but with the different rules about data outside of = EBML elements for "files" and "streaming applications", I am not so = sure. If you mean "file" concretely, does there need to be additional = text in this section describing the structure for streaming = applications? >=20 > It's more of an abstract thing. When we mention streaming it's some > kind of reading where you can't seek forward (and only backward is > there's a cache). But in general the storage itself doesn't matter. Okay >=20 >> =C2=A713.4.1.2: >> - "The "EBMLElementOccurrence" part is interpreted as an ABNF = Variable >> Repetition. >>=20 >> I don't understand what that means. There won't be ABNF in an actual = schema, will there? (Same for "VariableParentOccurrence") >=20 > The path is in the Schema and is interpreted as ABNF So if someone were to use a schema-aware encoder to create EBML data, = the interpreter would need to understand ABNF? [=E2=80=A6] >=20 >> =C2=A713.1.4.7 >> - The attribute is called "size" but defined to be "length". Why not = call it length? (Or describe it as "size")? >=20 > That must be for historical reasons. I'm fine with renaming it to > length since that's the term we use everywhere else. > See Pull Request #217 > https://github.com/Matroska-Org/ebml-specification/pull/217at = I=E2=80=99m okay with calling it size for historical reasons if people = prefer. If so, it would be good to make a comment to that effect in the = text. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_7897CC02-6DEA-46A4-A073-579BE0894457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 27, 2019, at 9:48 AM, Steve Lhomme <slhomme@matroska.org> wrote:

More:
Le lun. 7 janv. 2019 =C3=A0 22:15, Ben = Campbell <ben@nostrum.com> a =C3=A9crit :

*** Editorial Comments = and Nits ***

- General: The draft puts = double quotes around every mention of terms that it defines. That is = unconventional for IETF documents. I personally find that it makes the = draft harder to read. I suggest quoting them on the first mention, then = just capitalizing them in subsequent mentions.

I suppose you don't mean full = capital letters ? The idea is that if
you read a = particular section and not the whole document you can still
understand what is internal terms or generic names.

No, I = meant writing in the form of proper names.

But to be clear, I find the use of double-quotes = everywhere to create visual noise that makes the document hard to = read.



=C2=A711.1:
- Is the concept of a = file concrete (in the sense of a unit of persistent storage) or abstract = (as in any stream of data)? I had assumed the latter, but with the = different rules about data outside of EBML elements for "files" and = "streaming applications", I am not so sure. If you mean "file" = concretely, does there need to be additional text in this section = describing the structure for streaming applications?

It's more of an abstract thing. = When we mention streaming it's some
kind of reading where = you can't seek forward (and only backward is
there's a = cache). But in general the storage itself doesn't matter.

Okay


=C2=A713.4.1.2:
- "The = "EBMLElementOccurrence" part is interpreted as an ABNF Variable
Repetition.

I don't understand = what that means. There won't be ABNF in an actual schema, will there? = (Same for "VariableParentOccurrence")

The path is in the Schema and is interpreted as ABNF

So if = someone were to use a schema-aware encoder to create EBML data, the = interpreter would need to understand ABNF?
[=E2=80=A6]



=C2=A713.1.4.7
- The attribute is = called "size" but defined to be "length". Why not call it length? (Or = describe it as "size")?

That = must be for historical reasons. I'm fine with renaming it to
length since that's the term we use everywhere else.
See Pull Request #217
https://github.com/Matroska-Org/ebml-specification/pull/217at 



_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_7897CC02-6DEA-46A4-A073-579BE0894457-- --Apple-Mail=_6034836A-898C-41BB-8D47-0B4E48D80359 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx5riEACgkQgFZKbJXz 1A0g0xAAyYn24GXtT3LVaIAC4N5n0Or3IjPmiw7lNsfD10SPQR95PxKLttPzN9FQ sHRGC0SAafLfGf/uPYdR/8djCVfuQ4NQqcZP9TV0LYdLl4Bp/ezTzXpDLnyEAgII MeNX5lg1K+O/rlLZKjAjy4x6a7VUJ7mYVem0+sxuWNw4UjSRp10qwg7ZpYcCAkTe 0JiFGHIOn0idFQf5qoujqR0weKS9Zmh1Xh2q8fSi6RRUw3yAPsZzsFIrz5j/qc/m r05ZV4qkb//GOis6pEs/RBDIz48iBMtbYAHbNJWEiyEb/tgvNxSNW9I7gAJ10rXz 2vFQjEa0jslLm+4bJ4Ms7/FF9y5rpF0JB+eJHO85rgMxpjg9an9WNl99chDLg/h8 20QcswJfhSOOQ8bAMIbYKDYxVp+ZjSO6BzzWU6lLaL+mi9x28SXddKBP5W2dMk0o 0o6C0h+JphSvuqwSN4EOwtBAPGuLzG+OvpkJZ//+2fU0kXx9XLIBJ/WXTQYbH9Vj ECAeMDG2LF4xS874S+cn0Hhg9L0OkkGzMudTrINkALTCfpyv/paV9iENJrUz0S5S 65NWT4mHue3aYeiWkmZD5t8At08I+JJj66ZT/sBw6WJBGmdunAVy8U3Of6nvthtr S0NjtV8qREPR5heAHot2Y2gsMk+L5/MSdaTCuByfwwrEJZfhkgs= =OGg9 -----END PGP SIGNATURE----- --Apple-Mail=_6034836A-898C-41BB-8D47-0B4E48D80359-- From nobody Fri Mar 1 14:22:15 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694F2128D52 for ; Fri, 1 Mar 2019 14:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZaIBMYJop03 for ; Fri, 1 Mar 2019 14:22:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86652127AC2 for ; Fri, 1 Mar 2019 14:22:12 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21MM9JA021562 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 16:22:11 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551478931; bh=fpqOQOr2TJgYP+zIkFHpe5SxCodXRmHjoJrxMeXXqFc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=RfIlKGXghrQGA20yZttlJ9HlMSAXpFiW37g32ZRIwYbNizkjTck98wkMtIdNDDuyw OpmEP6RdXjRgiqtAZkhrxKlyFtEp9vdgBmUd7ciNpBcFb+2SRpoZdl6zgTYrdAjMx0 L7ad8GdO5bk6kP9eKDjSh1EbkD8zuGOueuLLsEZM= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F52D2DF2-180D-42F9-86F7-D326714FE94B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Mar 2019 16:22:08 -0600 In-Reply-To: <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> Cc: cellar@ietf.org To: Steve Lhomme References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 22:22:15 -0000 --Apple-Mail=_F52D2DF2-180D-42F9-86F7-D326714FE94B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 26, 2019, at 1:56 PM, Steve Lhomme = wrote: >=20 >=20 > On 26/02/2019 19:04, Steve Lhomme wrote: >> The third paragraph of the Security Considerations section (including = the >> bullets) appears to say its ok to treat the following invalid things = as valid. >> If that's the case, why are they invalid in the first place? I think = for some >> of them, perhaps text has drifted and they are no longer invalid, but = just >> to be avoided when it is reasonable to do so? For those that really = are invalid, >> some text should be added describing _why_ they are ok to accept. >=20 > The following are considered usable even if not strictly valid: >=20 > - Invalid "Element IDs" that are longer than the limit stated in the = "EBMLMaxIDLength Element" of the "EBML Header". > - Invalid "Element IDs" that are not encoded in the shortest-possible = way. > - Invalid "Element Data Size" values that are longer than the limit = stated in the "EBMLMaxSizeLength Element" of the "EBML Header". >=20 > These are not really invalid, just that they don't match what the EBML = header says. They might be perfectly usable despite that. Why would one create an EBML document that way? Or is this about = recovering corrupted documents? Thanks, Ben. >=20 > - Invalid "Element IDs" comprised of reserved values. >=20 > This is more problematic. But the reserved values mean they could be = used one day, so you may not choke on them. Either way it's fine to be = strict or not. >=20 > - Usage of "0x00" octets in "EBML Elements" with a string type. >=20 > If found at the end of the string this is a waste of space. It may = also be shortened strings in the middle. This may be explained better. >=20 > All these seem to just allow a parser to be very strict or very = forgivable. But it's all usable data. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_F52D2DF2-180D-42F9-86F7-D326714FE94B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx5sJAACgkQgFZKbJXz 1A3qRA//fEYoLpkmT8hTsFUSqch+HbocMoJLDQPOp72hiBQS6QzXJKwdiNm6Wf/Q GKebD/vclUo63bMlUAre+HH6J1uaLF8R43HQbCWs2szeC1hB5HkdiRFlptHfi2T7 PORAVsuF088LbBEtHXdzAD/i2+wtl7emvCzk+QpCT4wrCdKSJEkX+6mZ+oVRy5L7 JCgznmG7bhlnAnA0roc0GbCIoPfMrX+04dRVNKEhZA4wwGwK8pF1/ojwll7JQZc6 eB3XEWUoIKrJY8uvJBwH3XY2jFN7tFQ6pM/fxTWPFAyCEcfOHZzQpV7p5M7fXtM4 dGFgKPLW5KYIMAoU/AKNGpiGyUeCjJE7PUD10bR/KgxW8jejSo+Y5HZjCXm40frj buy/JH4ohSfdv/EV9hNAI3COC+jpcali0uDfSKiuex8yKd29e9iu6/FX3FyZSuRO 0j5fEZvuG7RkXo+GSCCXRYaOgPYDZ/K49H/QX91ao+nPadqrGeSnmrpN6my1p6ac xe2Gakfh6ONbwVeyNsZclcGw6hLdMXSiPu28CKozkjV6EmyoQnGbtX3aPILRgY8b 5mGjMh2iWvfoTtxi4ru2VVXrQ/QpVOVrXlYjA1F+yzJbPpBMb6ItHFor1okf5BrW dmA7juCImTpu/GSNRhxEpZEv9ZYz9kGFOM9LEnv1iXDQAXrOHPk= =kUkD -----END PGP SIGNATURE----- --Apple-Mail=_F52D2DF2-180D-42F9-86F7-D326714FE94B-- From nobody Sat Mar 2 16:05:55 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DCA130EDF; Sat, 2 Mar 2019 16:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezs9ebWZ-ync; Sat, 2 Mar 2019 16:05:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDBD12941A; Sat, 2 Mar 2019 16:05:51 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2305m6W083482 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 2 Mar 2019 18:05:49 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551571550; bh=QAq2ECMqwuZyr5g3XMIm0dZkIDffA7DVuhq1cbcYkvk=; h=From:Subject:Date:Cc:To; b=odMbk7CRX182i4kCIzoZmycjZAcOzqmRuQ0q/tNwJdlyUU7t6OgAkdE/lJNKLqXFS r02I8L9BJ2lhC4ZsP4c0Dtqh95Ep86y4dptunbGHW72a3LgQ88wJVk/IHNl/cC3YZY vMct0yYalfccFbBgoV4oEXTPiFa0JUigKxfXyBOM= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_7DB3A06A-7037-4A84-93FC-BE40B9BE5711"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> Date: Sat, 2 Mar 2019 18:05:39 -0600 Cc: Codec Encoding for LossLess Archiving and Realtime transmission To: draft-ietf-cellar-ebml.all@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 00:05:54 -0000 --Apple-Mail=_7DB3A06A-7037-4A84-93FC-BE40B9BE5711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for submitting the update. Version 9 is an improvement on version = 8, but I still have a few remaining (or new) comments. Please note that = I have not repeated all of the comments I made yesterday in response to = the discussion thread from my original review. Thanks! Ben. --------------------- *** Substantive Comments *** - A number of the pull requests the authors referenced in response to my = original review have not made it into this version. Please check; if = these have been left out on purpose, then please explain the reasoning. =C2=A71: After some side discussions with a few people, I think it would = be best to remove the sentence, "It MAY be used for use cases similar to = those.=E2=80=9D. That sentence is not necessary to allow usage for = cases similar to Matroska, and it is likely to still be a red flag for = reviewers who are concerned about the draft scope. If people really want to keep that sentence, note that there is now a = plural disagreement between =E2=80=9CMatroska=E2=80=9D and =E2=80=9Cthose=E2= =80=9D. =C2=A73: The changes here do not seem responsive to my previous comment: = "Can you offer guidance on the specific impacts of the mentioned = attacks, and how to mitigate them? (If there is no way to mitigate an = attack, it's okay to say that.)=E2=80=9D In particular, I=E2=80=99d like = to see a brief discussion of the potential security-related harms that = could result from the issues in the three bullet lists. Additionally, the new final paragraph "An "EBML Reader" MAY use the data = if it considers it doesn't create any security issue.=E2=80=9D seems = underspecified. The security considerations should offer guidance to = implementers about how to think about whether the data might create a = security issue. (I assume that paragraph refers to the side-channel = attack list immediately preceding it, but that=E2=80=99s not clear from = the text. Finally, the security considerations section is still in the wrong = place. The RFC style guide requires the security considerations and the = IANA considerations to be the last two sections in main body of the = textr (not counting things like references, authors=E2=80=99s addresses, = acknowledgements, etc.) =C2=A713.1.10: The document still needs to identify (and cite) which XML = schema format it uses. (For example, is this XSD? RELAX NG? Something = else?) I don=E2=80=99t think we resolved the question about whether the schema = has been validated. *** Editorial Comments *** =C2=A73, first paragraph: Please expand CRC on first mention. (Which may = or may not be this instance once the Security Considerations are moved = to the proper place.) =C2=A75.4, paragraph after first table: "Data encoded as a "Variable = Size Integer" MAY be rendered at octet lengths larger than needed to store the data." Is that intended as permission, or a statement of fact? If the latter, = then the normative keyword is not appropriate. =C2=A713.1.5.10: - "A boolean to express if an "EBML Element" MAY be used as an "Unknown- Sized Element"" Statement of fact. =C2=A715.1: "Numbers are be allocated within this range=E2=80=9D s/are be/be --Apple-Mail=_7DB3A06A-7037-4A84-93FC-BE40B9BE5711 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx7GlMACgkQgFZKbJXz 1A1b5w//XjVyG7MrbVAUgo7Xa5vTKyCIRACMiqzFU3gnM5kqYqArAAwl1fuSD5JZ 5hIHbi8zw8Fmm/GsAqvYOvN/b/pdSDtc48K25y/AupW+QwHODKIlpejFQKTGPFFA fKKIIEsRSFiJ+mQYMpyuZMpuEz44Z3LcOosk+sJJ5QcsTG9bMUsTTerLbfZ4X6Wq MCcxp0I6cxXqFfD0tFXo/HqPovP6a8xmE7gokm9tyWIedzIO3/cE0px9puzwSLTg yD3W0xAExBdwx61EgPrHvhhb1B3/ERmCJ9LTLNnagdQ0XDai3PifkWN498aFnd0a DmNYJNA+lfj5vqA7LkHygOmQWQIZVVMJ1RCRjUaZrPqEMUHu8mpF+LAjuWeFPQSB fxK+rJnS7xNKpHv5oBS84CmqUEwden06uX2448W7+v6hRx/pa2xxY+eqTHw3favP fsejiRGsACwvdO+s4POXymrgZepCMeEDPhQ3Cbwl8ZnY8Zi190HZa9Or7vlU8wWO uACJkGi7ic+/bb6zKGEhvrXBRwIwAdpADrLJyrnLetjrITd+ACbHMg95KSYV+lnz ANCtlEW2iECbT1wZLD4ZNyW8BCUjIXSd3tQJrISthQp91b6aLGm+0MQ+kXDLJ1Yo WPHD2kPA2P82Yjmvh/mvu4xf7w/QzQGxXcnknONHyKzuOrXYuh0= =CGUp -----END PGP SIGNATURE----- --Apple-Mail=_7DB3A06A-7037-4A84-93FC-BE40B9BE5711-- From nobody Tue Mar 5 06:20:02 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C1131140 for ; Tue, 5 Mar 2019 06:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2TtMhZO6Gt6 for ; Tue, 5 Mar 2019 06:19:58 -0800 (PST) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE6B13118E for ; Tue, 5 Mar 2019 06:19:58 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id q1so9665722wrp.7 for ; Tue, 05 Mar 2019 06:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=+Y9CQVBQ8/VYmbC5So58rhEvmhI8wY8yNWpcik1ploY=; b=qIfzB8oMS8nlwnTHGEbyuYMGQtaU54BpoBWfNQVYOnAcRrR1tdVHE0oxaQtkLc3Knw mhoEIumpF9SvVbGWfYhytmZ5Di9Jx2RtjvDuJMEFkystwniOzBX4CzUoSoh1jDrFWCTz +Y2R9Ryb6zpfbgSNtpf33EpSsiyxpq0ixtfJ/ry6cSGTtDoEve532D93QNRtm95/3qqL 3tQUp5BWeRRcHv66L8KBUKLYYCP2/tOJxYdtEIUWqBYMJXMgJsm158IkM1XLdD6QWnxM MMkNbr7lV12L0/ObrbV4GTWaydFwmieSCVyysMAjjcQfBMQM5Tsnflrv/rCghc33vla8 QYXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+Y9CQVBQ8/VYmbC5So58rhEvmhI8wY8yNWpcik1ploY=; b=U1NYiJJteoGHcWH6e1UOJhwX2Gs6kU6GWD8YsG/IdsjUc+hbDgnpccrV6v2I9j4j7g YJx+410TXomaaG0iS8T7/XNn40NC4M6RyTRzLga3jjzoqBNVORJBAaGnP4id/oyywjVS fvSTmMJibtBv1qU3d3JcShuHBgBfPYtUyWIoxrZPL4jaq+FLsjbV75PrfArK02lJtyxw CDnSQULSXa65FW53sWP5QMi8eZoYbRWn3OfyvDWMbjYrCKiaZHNEUHtihf6sWX9c46pP FImvmO4FpS/6D2kkkAITGxLlVxgnXkwq6v8ZfT6OoSlrsnZt6rP1Y5Z3GKDtTyN7Mgj6 +bTg== X-Gm-Message-State: APjAAAWYoeBgq/kazc49zaNAy2Zu6Qep5nS923iCLEf289dNAUrCMf2Q Fz/hwHGjUN9mPjp+1Iz/+yETcBSY50tCdw== X-Google-Smtp-Source: APXvYqzo4OfBYgGp1H977nqyPgs7jb9DeDYAS+1c8u3oyfKXJTyq380UyUf80WkVclp99pswjf7DjA== X-Received: by 2002:adf:d0c9:: with SMTP id z9mr16330598wrh.132.1551795596153; Tue, 05 Mar 2019 06:19:56 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id d9sm10414719wrn.72.2019.03.05.06.19.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 06:19:54 -0800 (PST) To: Ben Campbell Cc: cellar@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> From: Steve Lhomme Message-ID: <8792e93f-c6fe-735e-0903-a1774bde9353@matroska.org> Date: Tue, 5 Mar 2019 15:19:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 14:20:01 -0000 Hi, On 3/1/2019 11:22 PM, Ben Campbell wrote: > >> On Feb 26, 2019, at 1:56 PM, Steve Lhomme wrote: >> >> >> On 26/02/2019 19:04, Steve Lhomme wrote: >>> The third paragraph of the Security Considerations section (including the >>> bullets) appears to say its ok to treat the following invalid things as valid. >>> If that's the case, why are they invalid in the first place? I think for some >>> of them, perhaps text has drifted and they are no longer invalid, but just >>> to be avoided when it is reasonable to do so? For those that really are invalid, >>> some text should be added describing _why_ they are ok to accept. >> The following are considered usable even if not strictly valid: >> >> - Invalid "Element IDs" that are longer than the limit stated in the "EBMLMaxIDLength Element" of the "EBML Header". >> - Invalid "Element IDs" that are not encoded in the shortest-possible way. >> - Invalid "Element Data Size" values that are longer than the limit stated in the "EBMLMaxSizeLength Element" of the "EBML Header". >> >> These are not really invalid, just that they don't match what the EBML header says. They might be perfectly usable despite that. > Why would one create an EBML document that way? Or is this about recovering corrupted documents? It may not be intentional but a code that assumes it will write a short/simple file and ends up having to use larger elements and forgetting to update the header (or crashing before editing the header in the end). Since it's in the security section it may also be intentional to create bogus file to crash parsers that are tuned to only use the minimum resources. From nobody Tue Mar 5 07:18:16 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E321275F3 for ; Tue, 5 Mar 2019 07:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7QtFfqj6I38 for ; Tue, 5 Mar 2019 07:18:10 -0800 (PST) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D222130F97 for ; Tue, 5 Mar 2019 07:18:10 -0800 (PST) Received: by mail-wm1-x341.google.com with SMTP id x7so2949440wmj.0 for ; Tue, 05 Mar 2019 07:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GMIS1Gb8FgNoGbgbVKTBbxO972MGUxrSeqwQ4Qop8Zg=; b=TDkL2CQzwcZzARzcwuOdWDU2UVIk5NvYUMjLwO/kkEWmkeoP/G4tZDOyN9dmu1cPkz VrW9i2Szs0C/sjorTEkFVVlBhk1Z0DOAvkSlevhPuTXIjDhg1CNhLiS2E+eguwaeS9nQ b0oMj3inhXdOXI4Hf/7DBE2V0AMffuD8SqA/7plJOcAACImIi3U7Kr05bCH3btMpa96Z JLYccr6YQpmItfxEas8YuG1pln5HzbyeqW+VzLUvvp6TIzadsncLvWjx3XtxEry/aH90 vpGVioDrH9KSxHwtwlhIkJ07uYaI4IcbUAuyZ9MJhC/om0Djq0BjQ7bYb89FkaO48dcw Hb4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GMIS1Gb8FgNoGbgbVKTBbxO972MGUxrSeqwQ4Qop8Zg=; b=eXRx3la12FamnNDAdDQY7ofR8dsfa6rpxrFQx+H7MqZbhW9FPMDaX7Wlolj3GNu/WF P5wsapVzR/QIJ4n6SUU2Ny0I43ZV7MAWfCPhHNTVqyOrGDE9oOdjjSj/Y4ZM/w2sla6H 0TztskGqQX3dIfL5k8zVynwvxjGFi7DSTKedlZF8yJTEJ4uADPiFA5Hcu+fywN/4Q9dt A3Ae/EwX96RBWKVspvL090+L2UiEsu8EEfmS8e0Fb24xiTCFqmGyRQCPW3dyQBcaS3n6 1QC3wm/zsGvHmQZc5UYIhg1zv3qGOjwsOADFhvX8aK6FZyc6qwfKtd7ZdqJDhNQi2Wn6 jyDQ== X-Gm-Message-State: APjAAAUPzjiKBhmZ19Q90CdEESXLuBAqiOqjGQBHuV2CUeFy3EyHcwN2 6JekNCKkgKRoC0uSJYOylwB2pVgMnTz83g== X-Google-Smtp-Source: APXvYqzFXvy8eHwCrIAVIu5NybPPsTLdP7rqYOLd3Jn+dx3+wNbw7wOcNF5qj+KTj2BFe2/bar74cQ== X-Received: by 2002:a7b:cc18:: with SMTP id f24mr3309020wmh.42.1551799088041; Tue, 05 Mar 2019 07:18:08 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id s5sm32108947wra.77.2019.03.05.07.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 07:18:06 -0800 (PST) To: Ben Campbell Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <932C4B93-44CE-4FBD-9DFC-DE1EC94DFAEA@nostrum.com> From: Steve Lhomme Message-ID: <634b85e1-a9a5-3c1d-984a-a601127ea069@matroska.org> Date: Tue, 5 Mar 2019 16:18:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] AD Evaluation of draft-ietf-cellar-ebml-08. X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:18:13 -0000 On 3/1/2019 11:11 PM, Ben Campbell wrote: > > >> On Jan 27, 2019, at 9:48 AM, Steve Lhomme > > wrote: >> >> More: >> Le lun. 7 janv. 2019 à 22:15, Ben Campbell > > a écrit : >> >>> *** Editorial Comments and Nits *** >>> >>> - General: The draft puts double quotes around every mention of >>> terms that it defines. That is unconventional for IETF documents. I >>> personally find that it makes the draft harder to read. I suggest >>> quoting them on the first mention, then just capitalizing them in >>> subsequent mentions. >> >> I suppose you don't mean full capital letters ? The idea is that if >> you read a particular section and not the whole document you can still >> understand what is internal terms or generic names. > > No, I meant writing in the form of proper names. > > But to be clear, I find the use of double-quotes everywhere to create > visual noise that makes the document hard to read. This is gone in the new/future version. > >> >>> §13.4.1.2: >>> - "The "EBMLElementOccurrence" part is interpreted as an ABNF Variable >>> Repetition. >>> >>> I don't understand what that means. There won't be ABNF in an actual >>> schema, will there? (Same for "VariableParentOccurrence") >> >> The path is in the Schema and is interpreted as ABNF > > So if someone were to use a schema-aware encoder to create EBML data, > the interpreter would need to understand ABNF? > […] Yes > >> >>> §13.1.4.7 >>> - The attribute is called "size" but defined to be "length". Why not >>> call it length? (Or describe it as "size")? >> >> That must be for historical reasons. I'm fine with renaming it to >> length since that's the term we use everywhere else. >> See Pull Request #217 >> https://github.com/Matroska-Org/ebml-specification/pull/217at > > I’m okay with calling it size for historical reasons if people prefer. > If so, it would be good to make a comment to that effect in the text. We use "length" now. From nobody Tue Mar 5 08:55:11 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0D12F1A2 for ; Tue, 5 Mar 2019 08:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDp0cS1jjqYj for ; Tue, 5 Mar 2019 08:55:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0F612D4F3 for ; Tue, 5 Mar 2019 08:55:06 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x25Gt3Ib017520 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 5 Mar 2019 10:55:04 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551804905; bh=DL4fiiZauoSPXV1PNZmphbqa22s4aK5RolTySB4LANA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=IGxPTvmH9ppf7wIt6XylJ1DtpQC9Roq/+raUvUuLdJG+Mg5aHKTvZLSRWdfsPLiYY S3lizqq71GCWHEJKyTTt2uAwbIknjDo+wNExIxsnugq2emsINKln2vwPtZ8fmZttrR 5Nhme0g57F72OPXSmQl6zJroqW3JjEAwnO9/h4c0= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <1D9E9F06-69E6-40E0-A573-BB3B616FB514@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1FB656D1-0EBF-4351-8676-234091EBE695"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 10:54:56 -0600 In-Reply-To: <8792e93f-c6fe-735e-0903-a1774bde9353@matroska.org> Cc: cellar@ietf.org To: Steve Lhomme References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> <8792e93f-c6fe-735e-0903-a1774bde9353@matroska.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:55:09 -0000 --Apple-Mail=_1FB656D1-0EBF-4351-8676-234091EBE695 Content-Type: multipart/alternative; boundary="Apple-Mail=_12D77BEA-DA2C-4D00-AFBC-F935CDABA638" --Apple-Mail=_12D77BEA-DA2C-4D00-AFBC-F935CDABA638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 5, 2019, at 8:19 AM, Steve Lhomme wrote: >=20 > Hi, >=20 > On 3/1/2019 11:22 PM, Ben Campbell wrote: >>=20 >>> On Feb 26, 2019, at 1:56 PM, Steve Lhomme = wrote: >>>=20 >>>=20 >>> On 26/02/2019 19:04, Steve Lhomme wrote: >>>> The third paragraph of the Security Considerations section = (including the >>>> bullets) appears to say its ok to treat the following invalid = things as valid. >>>> If that's the case, why are they invalid in the first place? I = think for some >>>> of them, perhaps text has drifted and they are no longer invalid, = but just >>>> to be avoided when it is reasonable to do so? For those that really = are invalid, >>>> some text should be added describing _why_ they are ok to accept. >>> The following are considered usable even if not strictly valid: >>>=20 >>> - Invalid "Element IDs" that are longer than the limit stated in the = "EBMLMaxIDLength Element" of the "EBML Header". >>> - Invalid "Element IDs" that are not encoded in the = shortest-possible way. >>> - Invalid "Element Data Size" values that are longer than the limit = stated in the "EBMLMaxSizeLength Element" of the "EBML Header". >>>=20 >>> These are not really invalid, just that they don't match what the = EBML header says. They might be perfectly usable despite that. >> Why would one create an EBML document that way? Or is this about = recovering corrupted documents? >=20 > It may not be intentional but a code that assumes it will write a = short/simple file and ends up having to use larger elements and = forgetting to update the header (or crashing before editing the header = in the end). Has that been a problem in the field? We don=E2=80=99t normally write = specification for handling bugs, unless we think the bugs are = specifically likely to happen. >=20 > Since it's in the security section it may also be intentional to = create bogus file to crash parsers that are tuned to only use the = minimum resources. That=E2=80=99s worth mentioning in the text. While Postel=E2=80=99s law says we that an implementation should be = liberal in what it accepts, it can be dangerous to make implementations = make judgement calls about whether an otherwise invalid document can = still be used. That seems especially dangerous in light of the potential = for this as an attack. Do existing implementations attempt this? Thanks! Ben. --Apple-Mail=_12D77BEA-DA2C-4D00-AFBC-F935CDABA638 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 5, 2019, at 8:19 AM, Steve Lhomme <slhomme@matroska.org> wrote:

Hi,

On 3/1/2019 11:22 PM, Ben = Campbell wrote:

On Feb 26, 2019, at 1:56 PM, Steve Lhomme = <slhomme@matroska.org> wrote:


On 26/02/2019 19:04, Steve Lhomme wrote:
The third paragraph of = the Security Considerations section (including the
bullets) = appears to say its ok to treat the following invalid things as valid.
If that's the case, why are they invalid in the first place? = I think for some
of them, perhaps text has drifted and = they are no longer invalid, but just
to be avoided when it = is reasonable to do so? For those that really are invalid,
some text should be added describing _why_ they are ok to = accept.
The following are considered usable = even if not strictly valid:

- Invalid = "Element IDs" that are longer than the limit stated in the = "EBMLMaxIDLength Element" of the "EBML Header".
- Invalid = "Element IDs" that are not encoded in the shortest-possible way.
- Invalid "Element Data Size" values that are longer than the = limit stated in the "EBMLMaxSizeLength Element" of the "EBML Header".

These are not really invalid, just that they = don't match what the EBML header says. They might be perfectly usable = despite that.
Why would one create an EBML = document that way? Or is this about recovering corrupted documents?

It may not be intentional but a code that assumes it will = write a short/simple file and ends up having to use larger elements and = forgetting to update the header (or crashing before editing the header = in the end).

Has = that been a problem in the field?  We don=E2=80=99t normally write = specification for handling bugs, unless we think the bugs are = specifically likely to happen.


Since it's in the security section it may also be intentional = to create bogus file to crash parsers that are tuned to only use the = minimum resources.

That=E2=80=99s worth mentioning in the = text.

While Postel=E2=80=99s law = says we that an implementation should be liberal in what it accepts, it = can be dangerous to make implementations make judgement calls about = whether an otherwise invalid document can still be used. That seems = especially dangerous in light of the potential for this as an = attack.

Do existing implementations = attempt this?

Thanks!

Ben.

= --Apple-Mail=_12D77BEA-DA2C-4D00-AFBC-F935CDABA638-- --Apple-Mail=_1FB656D1-0EBF-4351-8676-234091EBE695 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx+qeAACgkQgFZKbJXz 1A1XLw/9GgX0MT1XN7bai1gELmJ7s3taId1AOcLkfkL5fhSqLxdarCDccHRYwt4I +IfOFZysg/XbWY/76P3zl67AIEwMBkAD/SNZwul46EfVppC6r/kTtcq+DSumFgko ZG5Ty5M1RzMa4wJmcfa/r0S/3qNZ/1Vgt8TVNHKg/3QBU2VX9CYkTzAdUNttdEsE /P6U/la8gqKgpwdxwLwrVl4U1bMqPIgGLY5/bOkqVCbPjspBILJDMb0p8dXw5iCm 3HWObhtu97c4OsngPmDUpEFTscUSH/P+xaqaxy0ldUw0FkB/b+TckXqS+P718T8C zNRsQa8f6KzBYrVpN4m2nusbdlpY/Afo78Bl9RjmZ1lFxzWL3k7Ck39Rw7W+dkUb ZwHnbozbV8pWkPgLLkwF5vTMtrZsoD6kq4hZr30YRLZs3tx0p1b7o9NX6q7hVqWP mYBm4K5zxCn5/XsUao8EeiXAMeDVWBxlWs3kZIbNuKt0L5QBg2b6GX2znADyRHAz kgTLkwdrln1krGj+kE1MPjhE/eSjHUeoXM1OIT9WXYYGBf/7gUK66w9ppeYjkelw /ERSH2ajcuXA1DxQRjhBWPBpZPGyh7L1sGIiBM4inD/3cZSQm4PaRt1k8KBdbBaw fAEeRArBvD6OmGGC/z7ue4+FgDItaO9IdiAIcWYZaGSl6hFkf2Y= =+TYR -----END PGP SIGNATURE----- --Apple-Mail=_1FB656D1-0EBF-4351-8676-234091EBE695-- From nobody Tue Mar 5 09:10:07 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAA91312AC for ; Tue, 5 Mar 2019 09:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPaScPk-zOkH for ; Tue, 5 Mar 2019 09:10:03 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650ED1311B7 for ; Tue, 5 Mar 2019 09:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=fILTc7ijw42gCYfCU7qgtpxbcdEf7Lc6LIHKYUKE6V0=; b=gSVQF3Afh/L9IQ8AybQvBz6H2YlTNT/Dj9gGzy5sHM9f0d21/AXY0dUMuDbu3l+gFREat9X9ITTqiS9Y+Yc16X+QSI/tnxthD6Q6/aIPDmtRdN6of1/cz6FQViiGJHutQZ1t4maH/QZAy1YxVNZrydm/vcDfwJD14YzczoYvmNA=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:43902) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1h1DZf-0001r5-38; Tue, 05 Mar 2019 18:09:52 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 0A95A6543B5B; Tue, 5 Mar 2019 18:09:46 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 99C725D56678; Tue, 5 Mar 2019 18:09:45 +0100 (CET) X-CTCH-RefID: str=0001.0A0B0201.5C7EAD60.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> <8792e93f-c6fe-735e-0903-a1774bde9353@matroska.org> <1D9E9F06-69E6-40E0-A573-BB3B616FB514@nostrum.com> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Ben Campbell Cc: Steve Lhomme , cellar@ietf.org In-reply-to: <1D9E9F06-69E6-40E0-A573-BB3B616FB514@nostrum.com> Date: Tue, 05 Mar 2019 18:09:45 +0100 Message-ID: <87mum9jlie.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 17:10:06 -0000 Hey, > Do existing implementations attempt this? Partially, yes. The implementations that I know of don't care about these two: >>>> - Invalid "Element IDs" that are longer than the limit stated in the >>>> "EBMLMaxIDLength Element" of the "EBML Header". >>>> - Invalid "Element Data Size" values that are longer than the limit >>>> stated in the "EBMLMaxSizeLength Element" of the "EBML Header". They simply read up to eight bytes for the Element Data Size and up to four bytes for the Element ID, no matter what the corresponding header values state as the maximum. Kind regards, mosu From nobody Sun Mar 10 06:20:07 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CA01200ED for ; Sun, 10 Mar 2019 06:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDQD0GUX-Hv0 for ; Sun, 10 Mar 2019 06:20:03 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B89126D00 for ; Sun, 10 Mar 2019 06:20:03 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id h11so1924148pgl.0 for ; Sun, 10 Mar 2019 06:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y8QoKktrcJXEPSWcCcIbYFTBp1vt/9dusL77DkHEdPk=; b=QP05nF80KXaJJdFdGGmFE1+VoaU4DmfStQ1GbI6Eud8HB4wDBzcJXW/B/xK8fQwpnF UgaUjASYct7D1Dl1GKaFgZnXMAjsSBr5xgkeufReUNBG2tN2hDP5SSeM7P3qEDadEKtf kiCFtp96p7ImCZCAHG8zDMPAXAPdX8wXs8Eq1R4J1ecM5gJarUiM/fHcy/OG+9iDZ/kI Ke6U4lSMopazbjVaLRucolvx/jF2BVf7/8UKhkSe4ouwcEyCuv8CTc/MZHF2YcsUnvN9 odrW1USK6Jclu5W78iuDzlDNW9jB6XAT72v5hd4J2EhNKhhCrHVeYige8xzSSUfjY4Wc KRvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y8QoKktrcJXEPSWcCcIbYFTBp1vt/9dusL77DkHEdPk=; b=BeTMj/nczrSEqn+JLpZyYv1p2vwsDJZFewwK2TSgX7X35dAqUPMpQMJuItplMI59MI puWPSXmds0marAXPhKl8HPDhERDdw2z/tz+DfeWhc9FzWvANRwKf+NeB+AVmxeiiXLCI 1XUIwwCHUU8mVwdRU+imPF5HxVLWhfINYAjQ8+Yu4HOQxo/MyiuNxkdqkdfx5Jn5aNXT uj/s7TRFKoqL1C99cfviDGu5dBJu2UPug5oh+E9tXey0jdTLHMT/OKy4KVsDXmlmRayd im87YU2o7XS1JFX95eM/JNa9BQMPtEls35rs5J0Qxc1u+iV+j1kfezYW/A98segqR2R9 u6ag== X-Gm-Message-State: APjAAAXs+mDcvoKyvWY1EAVAsFKC70B5xKXNMiGYLBO40GG+ZHN+Xu2X O79VS8AeHi3o2Nxn2Fky8Ak23K5U+6/KDFIkUXVAYk2VhUcZmw== X-Google-Smtp-Source: APXvYqymWubaQ2ShdBLDp6aPMx+WDmKpZrtpgsGHjVwxR4F0WSM7oC+6eJfMnogRuAjh4DWN2wUjt/ZGptn9EtFcKC4= X-Received: by 2002:a63:29c3:: with SMTP id p186mr25881889pgp.24.1552224002987; Sun, 10 Mar 2019 06:20:02 -0700 (PDT) MIME-Version: 1.0 References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> <3c906300-1dcd-8567-e960-542a4e6b9a16@matroska.org> <25763.1551282358@localhost> In-Reply-To: <25763.1551282358@localhost> From: Steve Lhomme Date: Sun, 10 Mar 2019 14:19:51 +0100 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 13:20:05 -0000 Le mer. 27 f=C3=A9vr. 2019 =C3=A0 16:46, Michael Richardson a =C3=A9crit : > > Steve Lhomme wrote: > >> I didn't think of this as a courtesy. After all, if these are dist= inct > >> namespaces with the potential for overlapping, then resynchronisat= ion > >> might be affected (in case of errors). In order to prevent this, t= he > >> ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to b= e > >> reused by any EBML Schema. > > > The resynchronization is indeed a good case for avoiding reuse. I'm= less sure > > about the sub element IDs of the EBML header. On one hand there's n= ot many so > > it's not a big restriction on the main EBML-based format. On the ot= her hand > > the number might grow in the future and collide with EBML-based for= mats that > > used the same IDs. > > Should the resynchronization goals be stated somewhere? Not sure, it seems like an algorithm that could be done in different ways. For example you can take the size in account (like we do in libebml) to find proper resynchronzation points and allow any upper elements to the context you last had (we also do in libebml). Or you could just look for any top level element and stick to that. > > IMO it still goes down to the namespace. The ID makes sense at one = level and > > none at any other level. So reusing the ID should not be an issue. = This is by > > design. The same ID in different places could be used and this is f= ine. > > > So IMO we should add a note that the 0x1A45DFA3 cannot be used anyw= here in > > the EBML-based format, as well as the EBML global elements. > > Exactly. Done in 7f78a306748d2f44098df72527989e96396bbb22 From nobody Sun Mar 10 06:35:03 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39950124B91 for ; Sun, 10 Mar 2019 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHKk-cwD0hYc for ; Sun, 10 Mar 2019 06:35:00 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30665124B0C for ; Sun, 10 Mar 2019 06:35:00 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id h11so1939792pgl.0 for ; Sun, 10 Mar 2019 06:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lhmtC/iHk+nrjzo1fEebgNObRV2IMBzM4uSN6IFyLfI=; b=0yek7AgdsHyhR+n5qRdTxlJTTKWeae1i0Cx9ugBLP50hA0RvRnPbD/Z9Z/jkrHZQ4d 964C4sXI9wvWujvrGhXTgWWoAW20SrNf6bVMFIWq5xNH13K23OE/r1N8C0jGazyMLve9 uB5SjjIcXpMJ4wm43F6b5/3xTaU/jEns8ZNY4AxSUl46etVaNANSzRZl2wx2krbRNXPN OagA+zsvCAWogaqsGoFqF+MFvKZqex0yNez2eCvtaFATB7JyglNyEMzCAsfYia/5Pqtp hluunQyaESIvy8j2B4HVTGEYQh3E2VwkCzI9bILnzNC685wZ8vObrUBFNpVnoASXlDd7 o01A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lhmtC/iHk+nrjzo1fEebgNObRV2IMBzM4uSN6IFyLfI=; b=QzA0V9d5YFGLkTQEWXva/BUQ4LJzfyik8RSEXdQTOGOXQnwABxp/U4tNv2/fABrgPQ isrw7J/686LRgrVWoJi7Z/Mum+Nv2e6MC6rRN5Uaewk92N39CZUEA8RtPWEYIQ8AAAPq KrbYO16EFzH6zy3R85FxWy+Kjd/PqLyI5n/QRqNx/yjUejGMC9truP4qrLobdF+p8uew 5tru8Xn+9P47BaU8jAPVDwckklV1P+6i5zTC4nyRFc+bbraOaqZIXRf3Rzfu62qBHb2e 0YFxRlgF740fCQqx2JyICHTiqb2Ibx2+zAsXd76bq3n9//T3Lt81NcWfjj/eUbZ7hShh kpwQ== X-Gm-Message-State: APjAAAVZq0K9v3qIDy6ulOV+bhIzU7cYzzFxUJd/IexnYwnhbdrzErLq LvvgFDv3/XJENDN+1mnug6O0IQ2bqbrlDZDouhOt3vb0G9w= X-Google-Smtp-Source: APXvYqzy41Y6Suy2jh/XF76HIslYxzK3p454X7XdQBUQVBNy8ZC0k69x0m3DUjlFFb9rrjeiTL7MvXbB3YSSqCsopxM= X-Received: by 2002:a63:f544:: with SMTP id e4mr8584380pgk.145.1552224899728; Sun, 10 Mar 2019 06:34:59 -0700 (PDT) MIME-Version: 1.0 References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> <05C55E6D-0690-429C-95B0-FE40893BB34F@nostrum.com> <8792e93f-c6fe-735e-0903-a1774bde9353@matroska.org> <1D9E9F06-69E6-40E0-A573-BB3B616FB514@nostrum.com> In-Reply-To: <1D9E9F06-69E6-40E0-A573-BB3B616FB514@nostrum.com> From: Steve Lhomme Date: Sun, 10 Mar 2019 14:34:48 +0100 Message-ID: To: Ben Campbell Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 13:35:01 -0000 Le mar. 5 mars 2019 =C3=A0 17:55, Ben Campbell a =C3=A9cr= it : >> Since it's in the security section it may also be intentional to create = bogus file to crash parsers that are tuned to only use the minimum resource= s. > > > That=E2=80=99s worth mentioning in the text. We split the potential security issues in 3 categories: can be handled (not totally invalid), data to discard, potential secutiry attacks. > While Postel=E2=80=99s law says we that an implementation should be liber= al in what it accepts, it can be dangerous to make implementations make jud= gement calls about whether an otherwise invalid document can still be used.= That seems especially dangerous in light of the potential for this as an a= ttack. > > Do existing implementations attempt this? > > Thanks! > > Ben. > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 10 07:07:26 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F0812796B for ; Sun, 10 Mar 2019 07:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk5NtZeyLr3Y for ; Sun, 10 Mar 2019 07:07:12 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B9C127817 for ; Sun, 10 Mar 2019 07:07:11 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id b2so1954849pgl.9 for ; Sun, 10 Mar 2019 07:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=URdOpHf7q3jJiOWSwlL+myeEbwS/AK9RxIzcCd7wOYU=; b=B0YLeEjoKlRdl/b7m67o7ojSkM8iV8eTjkGJ0iouDZyiwVxtVALSVNLC+xhTevMwCp LxQDgTBGHki1C9+Lpo0+TJ1Yopqirgun9tOoIqyCEBPukKpSjHG3+hut6YUle1TPjWa8 FgoNAaEBtrFEYuhIEDzyl+mVtCyk5821+J3o0S1MUi9FvdTb3nQspoD3VRR7i65GqKyG xuS1XD6/rspvw3ESFIRQsrAXXB2Q1JWh03XIP/Kq6Q/Qvs6GvtVf7orPxt6HgGb7HUEc gdvvLZc6CkqUHvVk2ORTxD9KX2VjzjHjhrcRnlc1VhJtpnYFVOtTSUdOy7PYzYMe5bSj MxxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=URdOpHf7q3jJiOWSwlL+myeEbwS/AK9RxIzcCd7wOYU=; b=TSM6yXQZlimCN6IzMPwtWEdl8fCTI7hDAVTkLUlp+5TLbWeyLAPrOo+ziaB/N3pqLF VxfdTSLo9YBR3yk4gCaN6tIZDVd5MohbztSNf08PD1s3a1qJ5phx2ear8jxDzRuOH9gm 4eTDKo9+c7lNyO2OY0584sAIkVTiOkUuKy/XWACCbuGoXhmA7zGDP7Xpx3ne5W6oqR7B lAHYgpQdZDVwGTyzytHI/rFkJbQIKawnlD1xW5y6/ZJ39L+7i9x1WHth1nUx8Yzpsf9Y 4IXlnyATCBbyVJ7ydG21y3WsOCYKO2KpJRZOUbIjfkLfT59EzJJAES+wy/qKEn7VZF2N 2BpQ== X-Gm-Message-State: APjAAAUinkJsYVwcx02t6C1QQU/3lTvMTC6FzP8qWh0eJwuk0EeBCZ3+ EE+VA/muP2/ahB+4C2fgYydX/BUVJwQfWs+gs/pjGQ== X-Google-Smtp-Source: APXvYqzoEwDFfW30kWfViMePG+5RC0sbdQvszQNgmg1JROqt9Ho9FCzPA2+gUowZvuNzLPnIuMhMkWx39JP7rWJ/hmQ= X-Received: by 2002:a17:902:b618:: with SMTP id b24mr27809038pls.73.1552226831177; Sun, 10 Mar 2019 07:07:11 -0700 (PDT) MIME-Version: 1.0 References: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> In-Reply-To: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> From: Steve Lhomme Date: Sun, 10 Mar 2019 15:06:59 +0100 Message-ID: To: Ben Campbell Cc: draft-ietf-cellar-ebml.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 14:07:15 -0000 Le dim. 3 mars 2019 =C3=A0 01:05, Ben Campbell a =C3=A9cr= it : > > Hi, > > Thanks for submitting the update. Version 9 is an improvement on version = 8, but I still have a few remaining (or new) comments. Please note that I h= ave not repeated all of the comments I made yesterday in response to the di= scussion thread from my original review. > > Thanks! > > Ben. > > --------------------- > > *** Substantive Comments *** > > - A number of the pull requests the authors referenced in response to my = original review have not made it into this version. Please check; if these = have been left out on purpose, then please explain the reasoning. Do you have any in mind ? They are at least discussed on Github. Some may be in version 10 (unpublished yet). > =C2=A71: After some side discussions with a few people, I think it would = be best to remove the sentence, "It MAY be used for use cases similar to th= ose.=E2=80=9D. That sentence is not necessary to allow usage for cases sim= ilar to Matroska, and it is likely to still be a red flag for reviewers who= are concerned about the draft scope. I agree, I created this PR https://github.com/Matroska-Org/ebml-specification/pull/249 > If people really want to keep that sentence, note that there is now a plu= ral disagreement between =E2=80=9CMatroska=E2=80=9D and =E2=80=9Cthose=E2= =80=9D. > > =C2=A73: The changes here do not seem responsive to my previous comment: = "Can you offer guidance on the specific impacts of the mentioned attacks, a= nd how to mitigate them? (If there is no way to mitigate an attack, it's ok= ay to say that.)=E2=80=9D In particular, I=E2=80=99d like to see a brief di= scussion of the potential security-related harms that could result from the= issues in the three bullet lists. Mh, OK. This is tricky though because it's easy to tell how things could be abused (and security researchers may find others), but it's another thing to explain how that could be exploited. The first list already mentions that the elements could be used and consider there's no issue. As for mitigating it depends a lot on what the parser is trying to achieve and what level of strictness it wants to achieve. I'm not sure we want this to be normative. For example "Use of Void Elements" could be used to hide content from regular parsers, create fake resync points that are seen by some parsers and some others. And there's probably other creative ways to use it. But I don't think it's possible to be exhaustive here. > Additionally, the new final paragraph "An "EBML Reader" MAY use the data = if it considers it doesn't create any security issue.=E2=80=9D seems unders= pecified. The security considerations should offer guidance to implementers= about how to think about whether the data might create a security issue. (= I assume that paragraph refers to the side-channel attack list immediately = preceding it, but that=E2=80=99s not clear from the text. OK. I'll try to come up with something more detailed. > Finally, the security considerations section is still in the wrong place.= The RFC style guide requires the security considerations and the IANA cons= iderations to be the last two sections in main body of the textr (not count= ing things like references, authors=E2=80=99s addresses, acknowledgements, = etc.) It was moved just above the IANA considerations in 1ec57eecf82e94f64a81ac8d0dd72d0d3f8c106d > =C2=A713.1.10: The document still needs to identify (and cite) which XML = schema format it uses. (For example, is this XSD? RELAX NG? Something else?= ) > > I don=E2=80=99t think we resolved the question about whether the schema h= as been validated. Indeed, and I have no idea. Dave ? > *** Editorial Comments *** > > =C2=A73, first paragraph: Please expand CRC on first mention. (Which may = or may not be this instance once the Security Considerations are moved to t= he proper place.) Done in PR https://github.com/Matroska-Org/ebml-specification/pull/250 > =C2=A75.4, paragraph after first table: "Data encoded as a "Variable Size= Integer" MAY be rendered at octet > lengths larger than needed to store the data." > Is that intended as permission, or a statement of fact? If the latter, th= en the normative keyword is not appropriate. The former. Updated in PR https://github.com/Matroska-Org/ebml-specification/pull/251 > =C2=A713.1.5.10: > - "A boolean to express if an "EBML Element" MAY be used as an "Unknown- > Sized Element"" > Statement of fact. I think it was fixed in 0a26e3ac2c7767fb3509d914e5b57daac870d19f > =C2=A715.1: "Numbers are be allocated within this range=E2=80=9D > > s/are be/be I think it was meant as "numbers are to be allocated within this range". I did that in 0acceca50d63ceb46c1b94223f0da49f6c1ad580. Now I wonder if it should be more normative than that, with a MUST. From nobody Sun Mar 10 07:50:51 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4D11278CF for ; Sun, 10 Mar 2019 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dQeCBrV7TMp for ; Sun, 10 Mar 2019 07:50:47 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9C012787D for ; Sun, 10 Mar 2019 07:50:46 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id e17so2015380pgd.2 for ; Sun, 10 Mar 2019 07:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f9NNw1OISxSSNa7f5/vWzoiI2xr9qMMUTb9RWly/+lQ=; b=JZyUhWek5T9VMnhBRRr+2Q6AGqanY1aE13zG4ZbV9B0v0hMqx7YySyBY/qfxlhd64Z TwqnWC90KuA6S2MsSug1TmMlpM52b455dVgCVVE+llhId/+BiPnpDITi5hNiWyLntF1g OLQ94qpQ9mZl3FBTOhwCOD244b9EwacJ3y2FE0d3Cs/8WVkJ6WxFYA9p4q/9sbx1gpk3 3/9a406H/Dfeo8RIZBiFAw7NXIjPFn9fwHtJWQCDSc3R9qXTkX35DcG6hNaoS3QC4xNR dEQXEhjdmzPG2/SfjhlvO2bPZ6A6dH5HA4tPgW3Gr1Vtf5I0iYkIi0AH8dLwBWej4Ox2 gbpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=f9NNw1OISxSSNa7f5/vWzoiI2xr9qMMUTb9RWly/+lQ=; b=Dc5iplTTcHJXMgZwy+zDyEqVfpht5C0WzGKmoVf6x1kV9Zky8Bj3Wdl2sc5obq/RJD ZNVW+6wxdUk2ygyUsLCsD3A/kWtTn7k+vWq4hzQnrMrYEe2DzVX/QmgfQBMDWFSp1qSA 5BsJ1O0YmtjuKvROrd5nYGwwubJE+FtWe+5WE0sSc8SVQmHwOTJNj7b0PNJpf20VNNEG VViiKNgILu6d9LHQiNEy+fDj0l92VmcEMBkgg4LrRe4gCW+WNJPizuPoXoRXz8XA9TEe XLl0L2NZCWrbeDFpRFF+p09Mgqa8ZJrPieoQ0QB6eFzbo57UAKu7zGR+W5ejFmS8VF3t +KHw== X-Gm-Message-State: APjAAAUN6oOB3bhQuHnkixFitCK1GCPT/9vw0qC7apmcX3cctZi4Kx4a 0HkTbdcxCu9I+90inE/XNCLXQ8NTJHsGRg9GtCVvng== X-Google-Smtp-Source: APXvYqx+A7MH7lYp3sUBMEDoOvgaVuQTFXPyKXh5ogGflOjdfyy1l0mscICiaOpIhFlHvDFLC+lACY4gOcWD+59waMw= X-Received: by 2002:a63:6e84:: with SMTP id j126mr12117740pgc.253.1552229446431; Sun, 10 Mar 2019 07:50:46 -0700 (PDT) MIME-Version: 1.0 References: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> In-Reply-To: From: Steve Lhomme Date: Sun, 10 Mar 2019 15:50:35 +0100 Message-ID: To: Ben Campbell Cc: draft-ietf-cellar-ebml.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 14:50:49 -0000 Le dim. 10 mars 2019 =C3=A0 15:06, Steve Lhomme a = =C3=A9crit : > > Le dim. 3 mars 2019 =C3=A0 01:05, Ben Campbell a =C3=A9= crit : > > =C2=A73: The changes here do not seem responsive to my previous comment= : "Can you offer guidance on the specific impacts of the mentioned attacks,= and how to mitigate them? (If there is no way to mitigate an attack, it's = okay to say that.)=E2=80=9D In particular, I=E2=80=99d like to see a brief = discussion of the potential security-related harms that could result from t= he issues in the three bullet lists. > > Mh, OK. This is tricky though because it's easy to tell how things > could be abused (and security researchers may find others), but it's > another thing to explain how that could be exploited. > > The first list already mentions that the elements could be used and > consider there's no issue. > > As for mitigating it depends a lot on what the parser is trying to > achieve and what level of strictness it wants to achieve. I'm not sure > we want this to be normative. For example "Use of Void Elements" could > be used to hide content from regular parsers, create fake resync > points that are seen by some parsers and some others. And there's > probably other creative ways to use it. But I don't think it's > possible to be exhaustive here. I added some text where it was not obvious (IMO) how the security consideration items could be interpreted: https://github.com/Matroska-Org/ebml-specification/pull/252 I did a commit for each, I may split in many PRs if there are too many issues to merge. From nobody Tue Mar 12 15:10:25 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4DF1277E0 for ; Tue, 12 Mar 2019 15:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd0ctVrKGqIi for ; Tue, 12 Mar 2019 15:10:22 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC38A1200ED for ; Tue, 12 Mar 2019 15:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=IGY/RF8ZBWQKG97m7Bc6i1afXR4uIkg3/4MYQ85ssdU=; b=zR0bPN1Xbb48yxJUMR2N7Kchbk00uvGzdf5xdiN5KflWxBOVejji+NP1dgjauc39h6HE8rcCaeV0cCqJrqgN9lmXXgNh/RV0HVEWiLjqb35g8R/r177NfWurhVkjcY8n09ZrJdP7bNnCQK/exZ1i6zrZuX2lT04nBm7tDulpDYc=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:34006) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1h3pb7-0004m0-0h; Tue, 12 Mar 2019 23:10:09 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 56BF5654008C; Tue, 12 Mar 2019 23:10:02 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 86CAA5DB8ECC; Tue, 12 Mar 2019 23:10:01 +0100 (CET) X-CTCH-RefID: str=0001.0A0B0211.5C882E41.0026, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: help Questions , Cellar list Date: Tue, 12 Mar 2019 23:10:01 +0100 Message-ID: <871s3bkame.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v32.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 22:10:25 -0000 Hey, Here's MKVToolNix v32.0.0, a really small bug fix release, the most important probably being the handling of Unicode code points > U+ffff (e.g. Emojis). For that to work a bug-fixed libEBML is also needed, which is why libEBML v1.3.7 is now required. It was released earlier today. Other than that nothing has changed for package managers since v31.0.0. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 32.0.0 "Astral Progressions" 2019-03-12 ## New features and enhancements * mkvinfo: when sizes are output the size of the element's data portion is output in addition to the element's total size. * MKVToolNix GUI: info tool: the element's data portion is shown as an extra column. * MKVToolNix GUI: multiplexer: added column "Delay" to the track list containing the additional delay to apply during multiplexing. Implements #2506. ## Bug fixes * all: fixed handling of Unicode code points > U+FFFF. Fixes #2516. * mkvmerge: Windows: mkvmerge was crashing with an exception when trying to identify certain files that can be used on Blu-rays (such as MPEG transpo= rt streams of MPLS play list files) and when the file name was given as a UNC path (e.g. `\\servername\sharename\path\to\file.m2ts`). The GUI emitted errors such as "the JSON output could not be parsed" in that case. Fixes #2507. * MKVToolNix GUI: the portable mode wasn't detected correctly when the curr= ent working directory the GUI was started from wasn't the directory the GUI's executable file was located it. Examples for when this is the case are Windows' "send to" or "open with" functions. Fixes #2501. * MKVToolNix GUI: multiplexer: using button to change the current destinati= on directory to one of the recently used ones did not update the file name according to the "make file name unique" setting. Part of the fix of #251= 9. * MKVToolNix GUI: multiplexer: the function "set destination file name from selected file's name" will now only change the destination file's name but not its path. Part of the fix of #2519. ## Build system changes * libEBML v1.3.7 and libMatroska 1.5.0 are now required as they fix their handling of Unicode code points > U+FFFF (see #2516). ------------------------------------------------------------ Have fun :) mosu From nobody Sat Mar 23 06:06:10 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B4F12008A; Sat, 23 Mar 2019 06:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzSD1L1uIb7T; Sat, 23 Mar 2019 06:06:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59301277C9; Sat, 23 Mar 2019 06:06:06 -0700 (PDT) Received: from dhcp-9259.meeting.ietf.org (dhcp-9259.meeting.ietf.org [31.133.146.89]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2ND62pf028264 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 23 Mar 2019 08:06:05 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553346366; bh=EAnku1azLyFa4ykklvtjUJw4s2mkiMrN9H/t1klsLyU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Os/IbNWSQuq/ZV4t4fdfr15Orpdt2CIkmGx5qCXpbfPc/eOrXWXdf8Qg6j7z7N8WX q8BcPIZ+/q5p3rC+uOkgaTpBn2TbgbIFI++vJjInF/aJqOYTpdLZXbcBGgHp+LwG04 uG6XETAIgvtnDSwz6g8oo+BISO3ehvM231vAPecI= From: Ben Campbell Message-Id: <9A0D288E-4C60-4208-9C15-7C95D1356023@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0B66F755-5D6B-4C12-9A0E-B9E7C0209D95"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sat, 23 Mar 2019 14:06:01 +0100 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-ebml.all@ietf.org To: Steve Lhomme References: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 13:06:09 -0000 --Apple-Mail=_0B66F755-5D6B-4C12-9A0E-B9E7C0209D95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Apologies for the delay in responding. Your reply caught me on = vacation. Also, I=E2=80=99m copying Alexey, who will likely take over as = responsible AD for CELLAR when I step down this week. Please see inline: Thanks! Ben. > On Mar 10, 2019, at 3:06 PM, Steve Lhomme = wrote: >=20 > Le dim. 3 mars 2019 =C3=A0 01:05, Ben Campbell a = =C3=A9crit : >>=20 >> Hi, >>=20 >> Thanks for submitting the update. Version 9 is an improvement on = version 8, but I still have a few remaining (or new) comments. Please = note that I have not repeated all of the comments I made yesterday in = response to the discussion thread from my original review. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> --------------------- >>=20 >> *** Substantive Comments *** >>=20 >> - A number of the pull requests the authors referenced in response to = my original review have not made it into this version. Please check; if = these have been left out on purpose, then please explain the reasoning. >=20 > Do you have any in mind ? They are at least discussed on Github. Some > may be in version 10 (unpublished yet). Here=E2=80=99s some that I could find that were not in 09, but it may = not catch all of them. I see some have been merged since 09, but for the = AD evaluation process, I prefer to see issues resolved in actually = published draft versions before we consider them closed. https://github.com/Matroska-Org/ebml-specification/pull/212 https://github.com/Matroska-Org/ebml-specification/pull/213 https://github.com/Matroska-Org/ebml-specification/pull/215 https://github.com/Matroska-Org/ebml-specification/pull/216 >=20 >> =C2=A71: After some side discussions with a few people, I think it = would be best to remove the sentence, "It MAY be used for use cases = similar to those.=E2=80=9D. That sentence is not necessary to allow = usage for cases similar to Matroska, and it is likely to still be a red = flag for reviewers who are concerned about the draft scope. >=20 > I agree, I created this PR > https://github.com/Matroska-Org/ebml-specification/pull/249h I agree with the pull request. [=E2=80=A6] >>=20 >> =C2=A73: The changes here do not seem responsive to my previous = comment: "Can you offer guidance on the specific impacts of the = mentioned attacks, and how to mitigate them? (If there is no way to = mitigate an attack, it's okay to say that.)=E2=80=9D In particular, = I=E2=80=99d like to see a brief discussion of the potential = security-related harms that could result from the issues in the three = bullet lists. >=20 > Mh, OK. This is tricky though because it's easy to tell how things > could be abused (and security researchers may find others), but it's > another thing to explain how that could be exploited. >=20 I may be making this sound harder than it needs to be. I don=E2=80=99t = think we need detailed =E2=80=9Csecurity-expert=E2=80=9D level analysis. = I=E2=80=99m looking more along the line of why people thought a given = =E2=80=9Cthing someone could do wrong=E2=80=9D is security-relevant. For example: There is a section labeled: =E2=80=9C An "EBML Document" = that has the following issues may still be handled by the "EBML Reader" and the data accepted as such:=E2=80=9D Does that mean there are no (known) security problems related those = issues? For the section: "An "EBML Reader" may discard some or all data if the = following errors are found in the "EBML Document=E2=80=9D:=E2=80=9D It looks like at least some of these could result in buffer-overrun type = errors. Is there a concern that such overruns could contain executable = code? Or are we just talking about denial-of-service? Do missing = mandatory elements create a security issue, or just useless data? Is it = safe to say just a reader =E2=80=9Cmay=E2=80=9D discard data with these = errors, or should it say something stronger? (For example, would it ever = make sense to _not_ discard data with missing mandatory elements?) In the side-channel section; what sort of information do you think can = be inferred from the mentioned side-channel attacks? Is this mostly = about implementation finger-printing? > The first list already mentions that the elements could be used and > consider there's no issue. >=20 > As for mitigating it depends a lot on what the parser is trying to > achieve and what level of strictness it wants to achieve. I'm not sure > we want this to be normative. For example "Use of Void Elements" could > be used to hide content from regular parsers, create fake resync > points that are seen by some parsers and some others. And there's > probably other creative ways to use it. But I don't think it's > possible to be exhaustive here. It doesn=E2=80=99t have to be normative guidance. (It=E2=80=99s pretty = common for security considerations to be non-normative.) >=20 >> Additionally, the new final paragraph "An "EBML Reader" MAY use the = data if it considers it doesn't create any security issue.=E2=80=9D = seems underspecified. The security considerations should offer guidance = to implementers about how to think about whether the data might create a = security issue. (I assume that paragraph refers to the side-channel = attack list immediately preceding it, but that=E2=80=99s not clear from = the text. >=20 > OK. I'll try to come up with something more detailed. >=20 >> Finally, the security considerations section is still in the wrong = place. The RFC style guide requires the security considerations and the = IANA considerations to be the last two sections in main body of the = textr (not counting things like references, authors=E2=80=99s addresses, = acknowledgements, etc.) >=20 > It was moved just above the IANA considerations in > 1ec57eecf82e94f64a81ac8d0dd72d0d3f8c106d >=20 >> =C2=A713.1.10: The document still needs to identify (and cite) which = XML schema format it uses. (For example, is this XSD? RELAX NG? = Something else?) >>=20 >> I don=E2=80=99t think we resolved the question about whether the = schema has been validated. >=20 > Indeed, and I have no idea. Dave ? Any updates here? >=20 >> *** Editorial Comments *** >=20 [=E2=80=A6] >=20 >> =C2=A713.1.5.10: >> - "A boolean to express if an "EBML Element" MAY be used as an = "Unknown- >> Sized Element"" >> Statement of fact. >=20 > I think it was fixed in 0a26e3ac2c7767fb3509d914e5b57daac870d19f >=20 >> =C2=A715.1: "Numbers are be allocated within this range=E2=80=9D >>=20 >> s/are be/be >=20 > I think it was meant as "numbers are to be allocated within this > range". I did that in 0acceca50d63ceb46c1b94223f0da49f6c1ad580. Now I > wonder if it should be more normative than that, with a MUST. My git fu is not quite up to quickly finding the commit from just the = string; can you send the URLs for these last two? Thanks! Ben. --Apple-Mail=_0B66F755-5D6B-4C12-9A0E-B9E7C0209D95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyWLzkACgkQgFZKbJXz 1A3oRw/+PVTXx84a4/Q9ZrCQQYg4KOwoImcGMV8VnrSSLdIvfaczvYzrnMXdkdmJ jbqi7ObUMj9TE+0Gr/ivPw6jJj5ZIOALzBqx3Jo8ZMEEXhFxJTPrMXS0qD0QsRHT jMmpO5FjI1cpCn6Ld1RPVrR83d/MiUJ99N6uwUFGXddS0zhLcC9rHy3LY84P6wa0 6cvFtW4dkY0RIP0dholwxbomohrTGoEZJxwXiF7d9g1ckFFvqa//JazQWJQZRNwI GkT1Ji820vet3DNKcZl7gmVTXrzy+taGDJrpdjdGM4+LiVzchBFb0qbioIoGgnaL +AfsCTwjHmupgAjLlJFddLzDj3B23EdHA5iPotEmzKgaxh9glICffqJxRbkUceih yLq+2pEBuk49oGJ7cDJT4FmVXfqWOmPIMI6Y4PL62FNPIlDcsaJAXwzI2wEfaGaS YRCud9XmBb45ODpQlj0FaIlxuI6KWuHOmeuTIOG3Z+OWiDMzQWNMDGXyitCTYWT3 LgoI+xdf58CGo+3gz/CX8+f5rZ/91CeL8JtwwGjtVCJR/t43fzlWshwl46dipW8e OxHBOL+4xDfR399jdxaSDpCpNChsW1UusJc5p6hVMQqx0X2LWGsh5ofXbl9b3g7h ARXCYho5YpeUtqkEL7AXvdFtm7vpYk8dKjkCQ9yGmw57wblFM8I= =BbyV -----END PGP SIGNATURE----- --Apple-Mail=_0B66F755-5D6B-4C12-9A0E-B9E7C0209D95-- From nobody Sat Mar 30 04:20:09 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA92120197 for ; Sat, 30 Mar 2019 04:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV4p7G-Bwb_E for ; Sat, 30 Mar 2019 04:20:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52804120189 for ; Sat, 30 Mar 2019 04:20:04 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [89.248.140.11]) by relay.sandelman.ca (Postfix) with ESMTPS id B25D31F45B; Sat, 30 Mar 2019 11:20:01 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 836F7343E; Sat, 30 Mar 2019 12:20:06 +0100 (CET) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 30 Mar 2019 12:20:06 +0100 Message-ID: <20823.1553944806@dooku.sandelman.ca> Archived-At: Subject: [Cellar] virtual interm meeting - 2019-04-02 - 20:00 UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 11:20:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Note that Europe changes it's clocks this weekend, I think. The meeting is still anchored to UTC, so the actual time probably changes if you are in Europe. CELLAR -- DRAFT AGENDA for Virtual Interim Meeting April 2, 2019 20:00 UTC DRAFT MINUTES FROM 2019-02-26 below INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-03/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-03-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. These notes at: https://github.com/cellar-wg/chair-notes (send pull requests on the draft minutes if you like) Proposed Agenda: 1. Note Well. 2a. Accept draft minutes from December meeting 2b. Accept draft minutes from January meeting 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is waiting on AD to proceed - FFv1 is past WGLC and awaits AD attention - new AD is Alexey.Melnikov at isode.com 5. issues raised and/or closed since Feb 26 CELLAR -- DRAFT MINUTES for Virtual Interim Meeting Feburary 26, 2019 20:00 UTC Probably best to turn off camera. Set your name in the upper right. Attendees: * Michael Richardson * Steve Lhomme * J=C3=A9r=C3=B4me Martinez * Dave Rice * Michael Niedermayer * sign-in here INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-02/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-02-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. These notes at: https://github.com/cellar-wg/chair-notes Proposed Agenda: 1. Note Well. 2a. Accept draft minutes from December meeting -- accepted unanimously 2b. Accept draft minutes from January meeting -- accepted unanumously 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is waiting on AD to proceed AD will change from Ben Campbell to one of: Barry Leiba, Adam Roach, or= Alexey Melnikov -10 will come out this week, with changes asked for Robert Sparks -change "general format"... need a better introduction which narrows = the scope. =20=20=20=20=20=20 - ffv1: 2 week WGLC. No objections. - Peter is the Shepherd, and posted first version today.=20=20 -- sent his own pull request, Jerome will take care of this, post new= version. 5. EBML IANA concerns raised with Matroska. - the top-elements of EBML should be reserved in all "children" document,= Steve Lhomme created a pull request to EBML. -- Dave approved this and it will be in -10. - mention in the Matroska spec that we must not use reserved EBML ID from= the EBML spec 6. Steve LHomme on Matroska document changes since last meeting. - not a lot of work on it in the past month... Andreas has been working o= n it too in the last month. -=20 7. WG plans for advancing documents. - address EBML issues, get it into IESG publication queue. - send ffv1 to AD/IESG before IETF104. (legacy protocol) Q: someone sent a security review https://mailarchive.ietf.org/arch/msg/cel= lar/Dnr_x0oOTToyd8mRwlx0l1ul1Lc https://datatracker.ietf.org/wg/cellar/archives/ https://datatracker.ietf.org/wg/cellar/about/ =20=20=20=20=20=20 =20=20=20=20=20=20 Next meeting April 2, and then April 30. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyfUOYACgkQlUzhVv38 QpB3ywf+KzpAE1htPbLO5aW59UbHHDyrjUuRFlTdsnWYRcieBTWiQVG0vmfEIavR hMTOr1WqX4iv5a3RrCkfNYziwSESkiUABjFeN5kdadXpMV1m2LXEunexSu/Yubbv aqcJHnXyyNx9YwLRlRj68e1JYCGiJJWn8R2cnOuhlKsxGW8LAOEX7L+5jriOMLGq hkVjtg4/D9y56PxN1m48Z1h2jwJTiZQk3kSi6TSPY0vRxsV3NNVIzHUCqoO63n4c ijmUxn1aDdu8A9sUzJJfIDmRTMIXnX2/hK1AAWuwW8vaqgh7Ir/fCB+5UCvIToif F/elvHn29GPyXiKwkui8hVixkdZZnw== =iMBu -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 31 01:28:24 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9D412008F for ; Sun, 31 Mar 2019 01:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQb6qg53t5AP for ; Sun, 31 Mar 2019 01:28:20 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B8212015D for ; Sun, 31 Mar 2019 01:28:19 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id c8so3029645pfd.10 for ; Sun, 31 Mar 2019 01:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=91WINuLV6D5C7BYafElSZahvyKLh000YlDBAZxJsQMI=; b=TMbnSde/ua1eYxo3MAY1ku3CP54JvQ2fmJ+h2VuaZkLhMEPgXdBSkdama3Nccq+1eO n2E6Q+fBjqnHbyn+CGcg+2e6+M8lXMisbAH6+HSKDDkVbL3b5m3ZLNXUUBhomsAGR2Y8 8LnvczizCebJwfkkOHPY/6VsnLn23GHqP/hikViGyYPPlL5cxtupwWeBrbHGbykuE4PT 26/ga2xHnDK4iLf0hlCuP4yHWd251RcxqMTwcFyUTQkEmOV7cxIA6f0Xij0FvcAAa8v2 aDfT2s9xB7/fI9RS+Ibv2Kcz6lQpAWQ1o1kR9vYfiITyGgIkAZQyP6gWwznjyGyuKgX1 GdtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=91WINuLV6D5C7BYafElSZahvyKLh000YlDBAZxJsQMI=; b=OVlba0blrbVnyzPKVoN9BoQzO3ZwRGGEnrzLeqwmggR3RROvTI48vGWDbsGl3f5t0A k/8wqSoU67lIa3xyXZLpJQiYflh2npRlH2cydQ2udpwSgK5mHqZTIjz2YmiyBo54+3WL +T3WlGkbzvylG81KcYUbzKDf0Z+taFuNgO4Fff5ZNbsoQXntZObhRa0fGT5pyvKWqB5g wfCxuOGihmSaMuZ9EXcjoNRkcP2xfBdERoKukVusweGcItIxhZtNgc0aIDa+pIPwyeVB vCn9JO1C5HApD/naUZag6dTvemapGYPjp+tKVTThXc6BfRZLlLLTdtyywV33AjtiZQQJ 4EIg== X-Gm-Message-State: APjAAAXzQ8HNGd9Tka1isBV44mwS9uzCzNGVbCsZ9TCI+uW+ozDP/diY 2ulYmQDEcSf3guGlclx+2rCUSpsA8pHqdJ0IAE6vDHPfVKAO8Q== X-Google-Smtp-Source: APXvYqw3u3/REX8Roi5tk0/y7JkD/jM77JhORchodTzKPFS9yChoriGx6x/P+jiT3cantp724np6HWVI655tAkfTq0A= X-Received: by 2002:aa7:9296:: with SMTP id j22mr28670256pfa.140.1554020899307; Sun, 31 Mar 2019 01:28:19 -0700 (PDT) MIME-Version: 1.0 References: <9B0A60E4-0A68-4A13-BAB5-FECBDED95A45@nostrum.com> <9A0D288E-4C60-4208-9C15-7C95D1356023@nostrum.com> In-Reply-To: <9A0D288E-4C60-4208-9C15-7C95D1356023@nostrum.com> From: Steve Lhomme Date: Sun, 31 Mar 2019 10:28:10 +0200 Message-ID: To: Ben Campbell Cc: Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-ebml.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 08:28:22 -0000 Hi, Le sam. 23 mars 2019 =C3=A0 14:06, Ben Campbell a =C3=A9c= rit : > > Hi, Apologies for the delay in responding. Your reply caught me on vacati= on. Also, I=E2=80=99m copying Alexey, who will likely take over as responsi= ble AD for CELLAR when I step down this week. > > Please see inline: > > Thanks! > > Ben. > > > On Mar 10, 2019, at 3:06 PM, Steve Lhomme wrote: > > > > Le dim. 3 mars 2019 =C3=A0 01:05, Ben Campbell a =C3= =A9crit : > >> > >> Hi, > >> > >> Thanks for submitting the update. Version 9 is an improvement on versi= on 8, but I still have a few remaining (or new) comments. Please note that = I have not repeated all of the comments I made yesterday in response to the= discussion thread from my original review. > >> > >> Thanks! > >> > >> Ben. > >> > >> --------------------- > >> > >> *** Substantive Comments *** > >> > >> - A number of the pull requests the authors referenced in response to = my original review have not made it into this version. Please check; if the= se have been left out on purpose, then please explain the reasoning. > > > > Do you have any in mind ? They are at least discussed on Github. Some > > may be in version 10 (unpublished yet). > > Here=E2=80=99s some that I could find that were not in 09, but it may not= catch all of them. I see some have been merged since 09, but for the AD ev= aluation process, I prefer to see issues resolved in actually published dra= ft versions before we consider them closed. I agree. > https://github.com/Matroska-Org/ebml-specification/pull/212 Only this one in the list is still not merged. Dave seem to have some disagreement on this, that EBML MUST strictly contain EBML but it contradicts the streaming case were the data are sent mid-element/level to simplify the code. As said in the comments GStreamer used to do that but it may not be the case anymore. I know in VLC/libavformat the header of the format is sent first and then waits for keyframe to actually start sending the data to avoid this. You don't lost any latency, you have a clean stream on the output. The only drawback is that the receiver has to wait for a keyframe to start seeing data. In any case it won't be able to start decoding before that so it's not an issue at all. So I may lean on the stricter (Dave) point of view here. That means we have to change the streaming paragraph not to allow this anymore. I'll close #212 and open another one. https://github.com/Matroska-Org/ebml-specification/pull/254 For old streams using this feature, the error/bogus EBML data recovery still apply and the reader will still have to look for valid data after it finds bad data. > https://github.com/Matroska-Org/ebml-specification/pull/213 > > https://github.com/Matroska-Org/ebml-specification/pull/215 > > https://github.com/Matroska-Org/ebml-specification/pull/216 > > > > > >> =C2=A71: After some side discussions with a few people, I think it wou= ld be best to remove the sentence, "It MAY be used for use cases similar to= those.=E2=80=9D. That sentence is not necessary to allow usage for cases = similar to Matroska, and it is likely to still be a red flag for reviewers = who are concerned about the draft scope. > > > > I agree, I created this PR > > https://github.com/Matroska-Org/ebml-specification/pull/249h > > I agree with the pull request. > > [=E2=80=A6] > > >> > >> =C2=A73: The changes here do not seem responsive to my previous commen= t: "Can you offer guidance on the specific impacts of the mentioned attacks= , and how to mitigate them? (If there is no way to mitigate an attack, it's= okay to say that.)=E2=80=9D In particular, I=E2=80=99d like to see a brief= discussion of the potential security-related harms that could result from = the issues in the three bullet lists. > > > > Mh, OK. This is tricky though because it's easy to tell how things > > could be abused (and security researchers may find others), but it's > > another thing to explain how that could be exploited. > > > > I may be making this sound harder than it needs to be. I don=E2=80=99t th= ink we need detailed =E2=80=9Csecurity-expert=E2=80=9D level analysis. I=E2= =80=99m looking more along the line of why people thought a given =E2=80=9C= thing someone could do wrong=E2=80=9D is security-relevant. > > For example: There is a section labeled: =E2=80=9C An "EBML Document" tha= t has the following issues may still be handled > by the "EBML Reader" and the data accepted as such:=E2=80=9D > > Does that mean there are no (known) security problems related those issue= s? Not exactly security issues, more abuse or bad uses of the format. It's more a reminder of tricky things parser need to be able to cope with, otherwise they might end up misbehaving and hiding/skipping usable content. That might have an impact on other elements and cascade into bigger issues at the semantic level. > For the section: "An "EBML Reader" may discard some or all data if the fo= llowing errors > are found in the "EBML Document=E2=80=9D:=E2=80=9D > > It looks like at least some of these could result in buffer-overrun type = errors. Is there a concern that such overruns could contain executable code= ? Given Matroska has attachments, such errors in the EBML could lead to issues. Executables are not common as attachments (or if at all) but Fonts are and compromising such data could lead to crashes in the OS/program when it parses the font. > Or are we just talking about denial-of-service? Do missing mandatory elem= ents create a security issue, or just useless data? Missing mandatory elements could lead to semantic incoherences. Depending on how the parser is done it may lead to infinite loops and/or crashes/ > Is it safe to say just a reader =E2=80=9Cmay=E2=80=9D discard data with t= hese errors, or should it say something stronger? (For example, would it ev= er make sense to _not_ discard data with missing mandatory elements?) I don't think it's good to tell how a parser should behave. Given one of the goal of CELLAR is long term storage, what makes sense to a player may not to an error recovery reader to figure out how to use the data it finds. I think making the people who writes parsers aware of the possible issues is enough for them to make the decision on how to treat these errors. And also the fact that giving one direction means we have to be sure that security-wise it's actually the best thing to do. > In the side-channel section; what sort of information do you think can be= inferred from the mentioned side-channel attacks? Is this mostly about imp= lementation finger-printing? Some can lead to issues at the semantic level to compare values, making parts of the data unusable. The Void element can be used to hide or "void" content that should have been there. > > The first list already mentions that the elements could be used and > > consider there's no issue. > > > > As for mitigating it depends a lot on what the parser is trying to > > achieve and what level of strictness it wants to achieve. I'm not sure > > we want this to be normative. For example "Use of Void Elements" could > > be used to hide content from regular parsers, create fake resync > > points that are seen by some parsers and some others. And there's > > probably other creative ways to use it. But I don't think it's > > possible to be exhaustive here. > > It doesn=E2=80=99t have to be normative guidance. (It=E2=80=99s pretty co= mmon for security considerations to be non-normative.) OK > > > >> Additionally, the new final paragraph "An "EBML Reader" MAY use the da= ta if it considers it doesn't create any security issue.=E2=80=9D seems und= erspecified. The security considerations should offer guidance to implement= ers about how to think about whether the data might create a security issue= . (I assume that paragraph refers to the side-channel attack list immediate= ly preceding it, but that=E2=80=99s not clear from the text. > > > > OK. I'll try to come up with something more detailed. > > > >> Finally, the security considerations section is still in the wrong pla= ce. The RFC style guide requires the security considerations and the IANA c= onsiderations to be the last two sections in main body of the textr (not co= unting things like references, authors=E2=80=99s addresses, acknowledgement= s, etc.) > > > > It was moved just above the IANA considerations in > > 1ec57eecf82e94f64a81ac8d0dd72d0d3f8c106d > > > >> =C2=A713.1.10: The document still needs to identify (and cite) which X= ML schema format it uses. (For example, is this XSD? RELAX NG? Something el= se?) > >> > >> I don=E2=80=99t think we resolved the question about whether the schem= a has been validated. > > > > Indeed, and I have no idea. Dave ? > > Any updates here? Nope > > > >> *** Editorial Comments *** > > > > [=E2=80=A6] > > > > >> =C2=A713.1.5.10: > >> - "A boolean to express if an "EBML Element" MAY be used as an "Unknow= n- > >> Sized Element"" > >> Statement of fact. > > > > I think it was fixed in 0a26e3ac2c7767fb3509d914e5b57daac870d19f > > > >> =C2=A715.1: "Numbers are be allocated within this range=E2=80=9D > >> > >> s/are be/be > > > > I think it was meant as "numbers are to be allocated within this > > range". I did that in 0acceca50d63ceb46c1b94223f0da49f6c1ad580. Now I > > wonder if it should be more normative than that, with a MUST. > > My git fu is not quite up to quickly finding the commit from just the str= ing; can you send the URLs for these last two? Sure: https://github.com/Matroska-Org/ebml-specification/commit/0a26e3ac2c7767fb3= 509d914e5b57daac870d19f and https://github.com/Matroska-Org/ebml-specification/commit/0acceca50d63ceb46= c1b94223f0da49f6c1ad580 > Thanks! > > Ben. > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Mar 31 02:12:52 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B1912008F for ; Sun, 31 Mar 2019 02:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayQw9rvUwxZ9 for ; Sun, 31 Mar 2019 02:12:49 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3814E12016C for ; Sun, 31 Mar 2019 02:12:48 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2V9CkjI022563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 31 Mar 2019 11:12:46 +0200 Received: from Castor ([IPv6:2a02:aa13:4680:f280:d452:4163:5aed:a82e]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x2V9Cj58182144 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 31 Mar 2019 11:12:46 +0200 Date: Sun, 31 Mar 2019 11:12:46 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] AD Comments on draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 09:12:51 -0000 Steve Lhomme wrote: >>Is it safe to say just a reader =E2=80=9Cmay=E2=80=9D discard data with t= hese >>errors, or should it say something stronger? (For example, >>would it ever make sense to _not_ discard data with missing >>mandatory elements?) > >I don't think it's good to tell how a parser should behave. >Given one of the goal of CELLAR is long term storage, what >makes sense to a player may not to an error recovery reader to >figure out how to use the data it finds. I think making the >people who writes parsers aware of the possible issues is >enough for them to make the decision on how to treat these >errors. =46ull agreement on my end! Best regards, Reto