Re: [TLS] Next steps for draft-agl-tls-padding

Manuel Pégourié-Gonnard <mpg@polarssl.org> Mon, 07 April 2014 17:23 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3642F1A027A for <tls@ietfa.amsl.com>; Mon, 7 Apr 2014 10:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.394
X-Spam-Level:
X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 8ozoQJJWHLLg for <tls@ietfa.amsl.com>; Mon, 7 Apr 2014 10:23:01 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 49D2E1A0221 for <tls@ietf.org>; Mon, 7 Apr 2014 10:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=kfdNDzBcHClysnwV+OTU/88j6vS7f0W5DOrBrls3fMo=; b=Ap0PT0zHLsnJ2i+aJHlmPnRay6KAj42y/0qS9tYVL7i3MFyXGG5uGZ4JsQqSr6MNvibkpSGIc4iHxP/0RiiM0W9wZt8t68OAvznklzZfLqIL8FvkVPvHrs4HJPdP5KPo9z0h27SNK+So//7QslGiU0Os5/kfbJGPp3eunT71Vk8=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1WXDFe-0003SN-At; Mon, 07 Apr 2014 19:22:31 +0200
Message-ID: <5342DEE7.3010706@polarssl.org>
Date: Mon, 07 Apr 2014 19:22:47 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Watson Ladd <watsonbladd@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> <CACsn0c=6j9GTPVkT0pGM4uu8XVmXOEqghU_gjDCVnd92z5kiyA@mail.gmail.com> <20140406211750.GA8953@LK-Perkele-VII> <CACsn0cm=_pkQeQPMUmcqTWzaP8NvfdpeFPUKCHEy6AikOThv3w@mail.gmail.com> <20140406213114.GA9363@LK-Perkele-VII>
In-Reply-To: <20140406213114.GA9363@LK-Perkele-VII>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mfEOlJA0LPZFbibPO29CZOLtlDs
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Next steps for draft-agl-tls-padding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Apr 2014 17:23:08 -0000

On 06/04/2014 23:31, Ilari Liusvaara wrote:
> On Sun, Apr 06, 2014 at 02:27:38PM -0700, Watson Ladd wrote:
>> All covert channels can be closed by auditing the software. But if I
>> introduce a leak in the nonce bits of ECDSA that is subtle, or encode
>> data I want to exfiltrate in the random padding of OAEP, even with the
>> private key, I cannot detect this.
> 
> Ah, the model is post-hoc auditing with access to private key. Got it.
> 
> And yeah, there are EC signature primitives that are deterministic and
> auditable in that model (such as Ed25519)...
> 
It seems to me that deterministic usage of ECDSA as documented in RFC 6979 is
also auditable in that model. Am I missing something?

Manuel.