RE: Bug 23097 - Underspecified behavior of verify() with regards to truncated signature

There are definitely use cases for things like 3DES or AES+CBC, but are
there any use cases for truncation beyond n/2?

Part of me says defer the min to the app/protocol, but I could live with a
non-normative minimum.
On Nov 19, 2013 10:44 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
wrote:

> I see. Thanks for the clarification, that was not clear to me from the
> conversation.
>
> Should we recommend that implementations refuse to truncate below a
> certain threshold? Or do you think that, as with deprecating weak
> algorithms, this unnecessarily reduces flexibility in favor of
> idiot-proofing?
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Tuesday, November 19, 2013 1:23 PM
> To: Vijay Bharadwaj
> Cc: public-webcrypto@w3.org
> Subject: Re: Bug 23097 - Underspecified behavior of verify() with regards
> to truncated signature
>
> On Thu, Nov 14, 2013 at 1:16 AM, Vijay Bharadwaj <
> Vijay.Bharadwaj@microsoft.com> wrote:
> > Thinking about this more, it really seems unadvisable to truncate MACs
> > without explicit instruction from the caller. I'm leery about issues
> > like with XMLSec:
> > http://www.w3.org/blog/2009/07/hmac-truncation-in-xml-signatu/
> >
> >
> >
> > Imagine a script that receives a signature from somewhere and passes
> > it to
> > verify() without checking its length (because people are lazy like that).
> > It's created a potentially exploitable oracle.
> >
> >
> >
> > Can we just add a truncation length parameter to the HmacParams and
> > recommend that implementations define a floor below which they will
> > refuse to truncate? That way the above example can be fixed, as the
> > input signature will be rejected if it wasn't exactly the expected
> length.
>
> Right, I think that was the proposal for how to deal with the truncation -
> the caller must explicitly request (as part of the algorithm's parameters)
> that a truncated signature be generated or verified.
>