Re: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature

Daniel Migault <daniel.migault@ericsson.com> Mon, 30 May 2016 13:14 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDB312D194 for <tls@ietfa.amsl.com>; Mon, 30 May 2016 06:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 zZoAzT9poSeg for <tls@ietfa.amsl.com>; Mon, 30 May 2016 06:14:08 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 ABF7A12D50E for <tls@ietf.org>; Mon, 30 May 2016 06:14:07 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id a136so86341331wme.0 for <tls@ietf.org>; Mon, 30 May 2016 06:14:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=MTw8cOpRrAcwAMyrwQhNwlUonjxU36nXLsWW4k/P7Ww=; b=Pd5qpeCenQHXOHA+QlrnOyrRq0Y6sGimg3qLDNHB8p9eaCJv1EjvtI5jtzKp+njUr6 5kQzoWdylzSJUKkntzkFAYvqtuRDyzeev+mWG88/UAhSXNSZ25/mnfmT9HOqZXfrlEpk p0qqA7bCiwL95Sw67bl+kUgkUQUxNDIxAZAN4xWH2XnjvaDcckVE4C6jh5+7nqOWveZZ 9JCfl7O0TEiuSVv67xuFOCohWMqWmcH43+ru6QoeXJFFWPNBK8JH26gU7rrXKzk8RDhn y6rYvc2Fl8nahC0ueb6b+Rjledb2OTwZrYwi8WohsUFxItbZxNkj5cEwfMJV3+2liibh teYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MTw8cOpRrAcwAMyrwQhNwlUonjxU36nXLsWW4k/P7Ww=; b=T4TPdhFKcrtci+2oyNikkoUSqK1+dZtjA9ePVAlq7ACo7CiFrkwwlr277iRKVdOYzN M9PhCf3t+PlX52+wsWFhEL7Res68XJfIs377L7aIgo6G6Pbjl5d6gCvwzsYAGcnB8S3T BLBkBfgb2jTYOPyedjEIYNZZAl8k0vzHOWlzZKq4Fr5lIc9XGndgKdMub1O6SKrllMMc aD2BY4AVC0VZ4TPXJJL7VTKtQNgMWflguAimiAUHV06AT5FkTddLnv49rPVqmYzDt9O/ lHbjyYV/JwutE7si5wbcdoi4M/YLSIJz1ZxS31/GpDblAGcdG/9UnX0NxqU9/wZQmX62 zTeQ==
X-Gm-Message-State: ALyK8tLE8++EChR57mEIFRyg338QKTYywB9KKg1VgR3hZy1eJ2sHcjOUrIpW5d55rJkHG0qqXhtjjdv9ydj0Iw==
MIME-Version: 1.0
X-Received: by 10.194.3.51 with SMTP id 19mr28185993wjz.57.1464614046114; Mon, 30 May 2016 06:14:06 -0700 (PDT)
Sender: mglt.ietf@gmail.com
Received: by 10.194.86.42 with HTTP; Mon, 30 May 2016 06:14:06 -0700 (PDT)
In-Reply-To: <CABcZeBPzXUT9WrL4i0tLWJhYwVZGAZtz=-PMENBawS3ra4WGcg@mail.gmail.com>
References: <CADZyTk=WDQ3yxvqY5vuczsoTtXb6LUPJk0T6fWDYOFCJXPeJAw@mail.gmail.com> <CABcZeBPzXUT9WrL4i0tLWJhYwVZGAZtz=-PMENBawS3ra4WGcg@mail.gmail.com>
Date: Mon, 30 May 2016 09:14:06 -0400
X-Google-Sender-Auth: boEATh-6laczbVWZB3Iw-odUed4
Message-ID: <CADZyTk=8ZkSfDDaY_O3vusYW3w=1AcZ70u=6wJKJgVo=fuQPkg@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="047d7b3a81fcf3edaa05340f07ab"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dMZ2l0FB8VODfbu1GswKKzKmNOI>
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 30 May 2016 13:14:12 -0000

Thanks a lot for your responses, they addressed my concerns.
BR,
Daniel

On Fri, May 27, 2016 at 5:58 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <
> daniel.migault@ericsson.com> wrote:
>
>> Hi,
>>
>> I have a few comments while reading 4.8.1 Digital Signature of
>> draft-tls-tls13.Hope it helps.
>>
>> BR,
>> Daniel
>>
>> Comment a)
>> "In previous versions of TLS, the ServerKeyExchange format meant that
>> attackers can obtain a signature of a message with a chosen, 32-byte prefix.
>> "
>>
>> My understanding is that the ServeKeyExchange format defines the bits
>> exchanged between the TLS Client and the TLS Server. I think the attack
>> vector is more coming from how the signatures are computed. I would rather
>> propose something like:
>>
>> "In previous version of TLS, the signature of the ECDH or EDH public key
>> is performed by concatenating the client random, the server random to the
>> public keys. The concatenation is hash and then signed. As the client
>> random is chosen by the TLS CLient, such design allows an attacker to
>> obtain a signature of a message with a chosen 32-byte prefix."
>>
>
> Hmm... I'm not sure this makes it much clearer. How about "The computation
> of the signature in the ServerKeyExchange...."
>
> Comment b)
>>
>> "Because TLS 1.3 servers are likely to also implement prior versions, the
>> contents of the element always start with 64 bytes of octet 32 in order to
>> clear that chosen-prefix.
>>
>> I think some additional steps need to be explicitly specified. I am not
>> completely sure of what is being signed.
>>     a) padding + context + H(client.random + server + random + ECDHE/DHE
>> Params)
>> OR
>>     b) padding + context + client.random + server + random + ECDHE/DHE
>> Params
>> OR
>>     c) padding + context + ECDHE/DHE Params
>> OR
>>    d) something else
>>
>> I assume that is a) in which case, the reason for choosing this format is
>> to constraint changes between TLS versions at the signing module. In
>> addition, if the correct scheme is a) maybe some additional text or
>> reference could explain why the padding and context solves this problem. By
>> prepending a fixed padding and some context, to the output of the hash
>> function, the TLS Client does not control the input that is signed as
>> cryptographic hash function are expected to be non-invertible.
>>
>
> None of these. The specific structs are indicated with digitally-signed,
> but generally the thing being signed is the concatenation of the handshake
> hashes and the hash of the resumption ctx.
>
>
>
>> Comment c)
>>
>> "A single 0 byte is appended to the context to act as a separator."
>>
>> When describing how the input to be signed is built, it may be clearer to
>> emphasize that string ends with 0, whihc leads to a "00" separator. I would
>> propose to add something like: "As the string ends with a "0" byte, the
>> binary representation will results in two zero bytes."
>>
>
> It's just one zero. TLS strings don't have trailing zeros. The 00 is 0x00.
>
>
> It would help the reader to add that “Example” is represented in hexa by 4578616d706c650
>> with the end of string character.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>