W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2017

Re: [webauthn] Consider requiring canonical CBOR throughout

From: Adam Langley via GitHub <sysbot+gh@w3.org>
Date: Thu, 31 Aug 2017 16:47:37 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-326355444-1504198049-sysbot+gh@w3.org>
ASN.1 ECDSA signatures are a common case of having to serialise something in a format with minimum-sized lengths. (There is BER, with indefinite lengths, but DER, without them, utterly dominates.)

ECDSA hardware often returns signatures in a simple format where r and s are just 32-byte (for P-256), big-endian numbers. Thus an embedded system writing out an ASN.1 signature needs to find the number of leading zeros of these numbers, see whether the resulting MSB is set, calculate the lengths, write them out, maybe write a padding zero byte, write out a subslice of the r value, do another length and padding for s, and then write out a subslice of the s value.

It would save a little code in the short-term if the values didn't have to be minimal, sure.

However, complexity in formats is very costly to an ecosystem over time. Requiring canonical CBOR (and having a few, large implementations enforce it, in order to keep the ecosystem honest) means that there's only one serialisation of a given message. Thus interop testing and unit-tests are dramatically more effective. And that sort of testing is realistically all that we're going to get in an ecosystem as large and diverse as we hope security keys will be.

Otherwise, in time, we'll see interop issues where implementation A is emitting non-standard, but valid, CBOR that implementation B just doesn't handle correctly. These issues might not be found until devices are out in the world, at which point they are very expensive to fix.

In TLS, which has a comparatively simple serialization (all fixed-size length prefixes), several extension mechanisms have been abandoned because enough implementations screwed them up that they're non-functional in practice. Implementations have been found to be sensitive to the order of supposedly unordered maps, or to have exploitable bugs in the face of duplicate entries. (A canonical order from the start would have been great. It also makes detecting and rejecting duplicate entries easy.)

At this point, TLS implementations are injecting random extensions in real-world usage to try and ensure that the major extension point remains useful for the future.

I believe the costs over time of extra complexity in a serialisation format will completely dwarf the costs of having to write a little more code to implement. (Unless your ecosystem is a monoculture, in which case webauthn will have failed anyway.)

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/455#issuecomment-326355444 using your GitHub account
Received on Thursday, 31 August 2017 16:47:33 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:27 UTC