Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12

denis bider <denisbider.ietf@gmail.com> Mon, 12 March 2018 09:41 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0E1242EA for <curdle@ietfa.amsl.com>; Mon, 12 Mar 2018 02:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 WjlgRgVU-wEn for <curdle@ietfa.amsl.com>; Mon, 12 Mar 2018 02:41:45 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 584661241F3 for <curdle@ietf.org>; Mon, 12 Mar 2018 02:41:45 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id s78so1095370qkl.8 for <curdle@ietf.org>; Mon, 12 Mar 2018 02:41:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LMba0FLUM3KI/eQG2aDAQQE6st0UYiHGxA8c7DRoW3Y=; b=qFYt2FBP96Dd1CkfH5vdXFHCHOgwVGCnwLcCgWLfCcyYOjPZpbahqvp0qzv72Y0tTb OdjHxgywIY0Xoc+bCwIu8opgrHPiTtPZD1JpsOiwoXh3D+wgcBfni0nkKS8wFoz+K6pN /R9UlD7c7S50phjJJgIIQ0ipQyZ+PjPA9aoeoY/TqK94VJ3EhoWSmFMs13OcpdVqPIIF 4DbYWikJXyvQN9uP9LXVKF8WNnZe3YNFwBJ0j6ZSbkXYjExL8KlmBQsBFYszoSl5uixw F3K6lwb0eyaQk5QTXK8YMNVHiUkotodhpz+ogKz71+Ir9h9WbxVzmHuC8THGLx0KCftc h8Gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LMba0FLUM3KI/eQG2aDAQQE6st0UYiHGxA8c7DRoW3Y=; b=duEP18JIspMKj0OahnGaFDy6oENebAu2V0yZpnYajsOfXXp1iudNOx7RmE52kpoQ2l I8UYRXVXZvKZORZgbz5CcqlaKZEm+V0BDof6njJwY2oBs4G+F5mimJpizCyRgBYh91gO tK0jdaJYiZBwtRgXKbJM9vjdBTJa7upIEwJ+6AV6CpkX+88QIi4bNCfddkRSksYx1J0m 2xK94yRh5E3eXK4ljfYWMC/mEGZNzEEWzvB+EH6pOxRClqPRLpJaEPAlTZDIf9G4Nyuc uYwi0ElW/B4ySwfUU7wHNu4H6KxA59IQmURo3Wwcln99CJeypegtKS+GajFV3Vuvd2B2 VG3A==
X-Gm-Message-State: AElRT7H/YJ+RTa6sP5I1uZrrOLZ4hiYQ8pbxRmiPlhozym5tOHvJERMD iH/3gTeruS4n3djyfFhqmFk6dhkQ6wmxJpykmyM=
X-Google-Smtp-Source: AG47ELuMmgp/IrSf4a+ZcfDkeLzHGxvrB0aXEnrwRnXhxqpiJnVl9T5lRgTmr2jACgamxJTaagHqcoCgMANOXOJimNg=
X-Received: by 10.55.79.78 with SMTP id d75mr9975492qkb.20.1520847704359; Mon, 12 Mar 2018 02:41:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.225.71 with HTTP; Mon, 12 Mar 2018 02:41:43 -0700 (PDT)
In-Reply-To: <17856.1520829824@eng-mail01.juniper.net>
References: <4C40F019-21FB-46AC-95D3-CC94BB976AAB@akamai.com> <12087.1520816187@eng-mail01.juniper.net> <CADPMZDCwRN-GHXhAe=-xPFHMnUBN39UWmENGNUeLbFkneEAgcA@mail.gmail.com> <17856.1520829824@eng-mail01.juniper.net>
From: denis bider <denisbider.ietf@gmail.com>
Date: Mon, 12 Mar 2018 04:41:43 -0500
Message-ID: <CADPMZDBnG1hv5D74vLv2bXqxZjceJgHQ9oYrufKHskLdV7nRSQ@mail.gmail.com>
To: "Mark D. Baushke" <mdb@juniper.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, "curdle@ietf.org" <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="001a114886822d05d1056733f342"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/TzWzURHGYRxZIn8SKA1E5FVF2Ew>
Subject: Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2018 09:41:47 -0000

I agree with either MAY or SHOULD.

I suggested MAY on the following grounds:

1. I was speculating it could help this new text, which I knew was too
late, be accepted more easily. This hasn't panned out, but that seems for
the best. :)

2. Years in the future, there may be a time when deployed implementations
all encode "S" correctly. At that point, we may no longer want to SHOULD a
special case that's no longer relevant.

3. It weakens the claim of implementations that don't send the zeros that
they follow the spec. They can more easily make this claim if there is a
"SHOULD" to accommodate them.


However, I also see the following arguments for SHOULD:

4. It's unavoidable current practice, so it may convey the more accurate
idea to a new implementer.

5. Quantum computing will likely make RSA irrelevant much before all
implementations encode "S" correctly.


All things considered, I prefer MAY, and the main reason is 3 - not letting
implementations who don't send the zeros to claim that they're doing it
right. I'm also okay with SHOULD, but it enables the implementations that
created the problem to begin with. :)



On Sun, Mar 11, 2018 at 11:43 PM, Mark D. Baushke <mdb@juniper.net> wrote:

> Hi denis,
>
> My question is answered.
>
> Rich asked:
>
> > Does anyone object?
> >
> >     > > The value for 'rsa_signature_blob' is encoded as a string that
> >     > > contains an octet string S (which is the output of
> RSASSA-PKCS1-v1_5)
> >     > > and that has the same length (in octets) as the RSA modulus.
> When S
> >     > > contains leading zeros, there exist signers that will send a
> shorter
> >     > > encoding of S that omits them.  A verifier MAY accept shorter
> >     > > encodings of S with one or more leading zeros omitted.
>
> I do not object.
>
> Given at approximately 1/256 signatures will have a naturally occurring
> leading zero for which some implementations do not send it and some do,
> I have no objection with the change in text.
>
> I do wonder if the text would better read:
>
>  A verifier SHOULD accept shorter encodings of S with one or more
>  leading zeros omitted.
>
> to encourage a stronger likelyhood that a valid, but short signature
> would still be accepted. However, I will leave that to others to
> determine.
>
>         -- Mark
>