I am opposed to using CBOR. CBOR is not well deployed. Most codebases need XML
and JSON parsers but do not need CBOR parsers. So choosing CBOR significantly
increases the code complexity. My codebase has a JSON and XML parser but no
CBOR parser. I would strongly prefer to keep it that way, so CBOR would
introduce an unnecessary deployment barrier.
Binary formats have an extremely poor track record for security-sentive
applications. ASN.1 BER/DER has been an utter disaster for real-world security
in PKIX (there are probably hundreds of CVE reports due to ASN.1 parser bugs
including many in TLS/SSL/PKIX stacks). We should not repeat this design error
in a security-sensitive context again.
JSON parsers are widely used, simple and have been well analyzed for security
usage. They are a good choice for a security sensitive context (excluding the
naive Javascript implementation). Most deployed JSON parsers are
secure-by-default.
XML parsers are widely used, but are complex and have a large attack surface.
Many XML parsers are insecure-by-default (they resolve the schema URI by
default, even if the XML data is from a potentially untrusted source).
I think JSON is the best choice for this use case. I can personally live with
XML because I’ve built my own secure-by-default XML-subset parser (which is
about 3x the size/complexity of my JSON parser), but I think it’s an inferior
choice to JSON for security-sensitive applications.
If data size is a concern, then deflate is the answer. Deflate is likely to
compress JSON far better than CBOR. While deflate is subject to the security
problems that binary formats have (including several releases with known
security vulnerabilities), I believe it’s been around long enough that
reasonably trustworthy implementations are now available (including current
zlib releases). I’m not convinced data size is a concern.
- Chris
On April 29, 2016 at 21:14:29 , Aaron Zauner
([email protected](mailto:[email protected])) wrote:
> Hi,
>
> I'm now specifically reviewing the STS reporting draft. We currently have a
> discussion on file formats within STLE/LE/Certbot. I think CBOR would be a
> nice format if things get bigger. I'm aware you just switched to JSON and in
> your specific use-case JSON will probably suffice. The
> future-work/forensic-reporting mode is something I'd be specifically
> interested in in that regard. Once these reports get big, JSON might be
> suboptimal.
>
> What's the WGs opinion on that?
>
> Aaron
>
> On Tue, Apr 26, 2016 at 9:51 AM, Aaron Zauner wrote:
> >
> > > On 25 Apr 2016, at 20:37, Leif Johansson wrote:
> > >
> > > On 2016-04-25 15:29, Brotman, Alexander wrote:
> > >> Hello,
> > >>
> > >> We've incorporated much of the feedback we've received from the
> > >> community, and would like to present updated drafts.
> > >>
> > >> * One of the most evident changes is that we've split the draft into two
> > >> separate documents; one for the STS policy, and one for the TLS
> > >> reporting. These are meant to replace the original SMTP STS draft
> > >> (https://datatracker.ietf.org/doc/draft-margolis-smtp-sts-00).
> > >> * We've altered the name a bit from "SMTP STS" to "MTA STS" to be more
> > >> in line with DEEP, and have also added elements for the DEEP registry.
> > >> * After some deliberation amongst the authors, we've also decided to
> > >> remove the DNSSEC-related options for the STS policy, which should
> > >> simplify work for those wishing to deploy STS validation.
> > >> * Within the TLS reporting, we've explicitly mentioned several failure
> > >> modes, including those specifically relating to DANE and MTA STS.
> > >> * We've also altered the report syntax to use JSON instead of XML.
> > >>
> > >
> > > Thanks,
> > >
> > > In BA there was consensus (pretty strong at that) to adopt this draft as
> > > a WG document.
> > >
> > > This starts an adoption call for adoption as a WG document. Please
> > > indicate your support or objection (with motivation) for WG adoption
> > > no later than EOB (any TZ) May 1st
> >
> > I support adoption of these drafts as WG documents, they will need some
> > further work though. I'm of course reviewing and will provide feedback both
> > on list and have been talking with (some of) the authors backchannel as
> > well.
> >
> > Aaron
>
> _______________________________________________
> Uta mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
