Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Wan-Teh Chang <> Wed, 16 March 2016 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5C4E12D9FC for <>; Wed, 16 Mar 2016 08:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kqI0wkn2VyoG for <>; Wed, 16 Mar 2016 08:31:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B30312D9F5 for <>; Wed, 16 Mar 2016 08:31:07 -0700 (PDT)
Received: by with SMTP id h129so66225247ywb.1 for <>; Wed, 16 Mar 2016 08:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PgdWL+paBRvDUWk/fxD9OX9e1kmI6bTjr+tjHwgqGPg=; b=c4ebKaeGCx/4AxHZVBky4SL9FHLEvEAGBPhsooh5b2jdM6UCevs9yOxJrbl3ZuSJYG 65Vgyf0Thgh3pQmJrpRjbCwnnSa0X2W9vsQvqZMTLDw/F25X3QgJEmN/ppuhveTb3o9I ejtWbJfx+Xc6bdmuky4hBZLXeNP19aes3Sh1ZlAbOKFs8LtdB2LWxderLJvO7+7Ym9zk bX1AkAlCNfVFS0EunXrqbi6n5VI4xumMv7DoV9S/Kozf01k02XoI6RRk8sp2ZUXYJnyY lyXT1SKdg44oqmU6TAGqGgxUKlIOuwke4pSx8xJfaZ7ElAOdgIEP1Cuj7SAObBsaylpB SXWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PgdWL+paBRvDUWk/fxD9OX9e1kmI6bTjr+tjHwgqGPg=; b=a7un6L4FrXxzrF7nu7sOSUf5Y3GaUvqxzvfIWPldtjM7A7+BiwItEkwk7sn28RKnKL G1g/7xj3lLckZgAbgXUeKQyjlPqULFbTFISIiHNPcSgfhmosN+QyIDkkwyVvpoJeXh5s ewgyMUt9zkuOnNfLQiTxflWbVpEmDdh/quhsWS2DxXCkze4pwk3jIG0niPQbJZxuPIfR /n7iR/C12wSbZJ49T3ZEWvh1B8f32tFN1MddUTd40ptpOkeOMfLIcy9bOkYpP605n9Lh o9QxIb28f3PVOlyvZS7S6WkSAddayCmLU3QIoyuOVzSgfA4gQcws+9lZahlJs3CIiTGE ehZg==
X-Gm-Message-State: AD7BkJJzmmvl12YMZQEGV8V6iLu+1HEnzgs9fBrpYwJRspOMcvJsBLes9vvyGLOnv+6LexHfxPbBS2aARuf+O6Dc
MIME-Version: 1.0
X-Received: by with SMTP id q126mr2054691ywe.203.1458142266340; Wed, 16 Mar 2016 08:31:06 -0700 (PDT)
Received: by with HTTP; Wed, 16 Mar 2016 08:31:06 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 16 Mar 2016 08:31:06 -0700
Message-ID: <>
From: Wan-Teh Chang <>
To: Peter Gutmann <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Mar 2016 15:31:52 -0000

On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
<> wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back.  It's now available as:

Section 3.4. "Implementation Issues" says:

   TLS-LTS requires that RSA signature verification be done as encode-
   then-compare, which fixes all known padding-manipulation issues:

   o  TLS-LTS implementations MUST verify RSA signatures by using
      encode-then-compare, meaning that they encode the expected
      signature result and perform a constant-time compare against the
      recovered signature data.

This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section
8.2.2, with the additional requirement that the comparison in Step 4
be constant-time, right?

and the alternative procedure outlined in the Note at the end of that
section shall not be used?

   Note.  Another way to implement the signature verification operation
   is to apply a "decoding" operation (not specified in this document)
   to the encoded message to recover the underlying hash value, and then
   to compare it to a newly computed hash value.  This has the advantage
   that it requires less intermediate storage (two hash values rather
   than two encoded messages), but the disadvantage that it requires
   additional code.

Wan-Teh Chang