Re: [TLS] shibboleth and the nonce

Andy Lutomirski <luto@amacapital.net> Thu, 24 July 2014 21:13 UTC

Return-Path: <luto@amacapital.net>
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 9EB501A035D for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 14:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 NyPA0KNr45CX for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 14:13:08 -0700 (PDT)
Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5283D1A0146 for <tls@ietf.org>; Thu, 24 Jul 2014 14:13:08 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ey11so4706528pad.38 for <tls@ietf.org>; Thu, 24 Jul 2014 14:13:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KaxPNcDdxPR/g77ihirqOwX5QD1YhP37e5lpPpi4Vpk=; b=aIrOezNVudeL+U8ONvxdAzSmIB+Jx21F9G3sf5esDZ9BzW/794tADCXsqNR/2smET5 6bq4kPxSmzprZT3dSaFWWJ+s/QNxqtx6qL2s5v/1cwuSPxkqawXhguwLmR6YbueVl12y TCkqAyWN0b4/dChHlIMkzqXEtSJL+e67JI5NLvVJmTAMegyUhSUluFzkA8QjA2KMTQsm MaKejylJeIgpUEoDbWuoHPP1CehequcChuvq1+B/uXYfD7O+f+0SslNUXpJL+B4rUFP8 0XbDgs8ChHqrvWG/VkG9PGZKWEYY9x74urWRuyyc5LEVVSV1lWcyhN+55/nyd8UNMsd3 aHnw==
X-Gm-Message-State: ALoCoQk4nAkGNdFLBQl0lT3cRn/vDh2t1zSC9UsrGtFq2znvE8CxIr9YoRRoAxY9YKKgw/b0RB0W
X-Received: by 10.70.42.38 with SMTP id k6mr13932842pdl.120.1406236387724; Thu, 24 Jul 2014 14:13:07 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id be7sm8733282pdb.37.2014.07.24.14.13.05 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 14:13:06 -0700 (PDT)
Message-ID: <53D176E0.7060002@amacapital.net>
Date: Thu, 24 Jul 2014 14:13:04 -0700
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>, Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnXJ4c6DqZPG+Y5m1BRX+hCjVSg4xi40po4AOuU1F4TFQA@mail.gmail.com> <CAMfhd9Uca1drheHFywqCE-ZE8tzRT3g03qBTZw7YpP8ECZeaiQ@mail.gmail.com>
In-Reply-To: <CAMfhd9Uca1drheHFywqCE-ZE8tzRT3g03qBTZw7YpP8ECZeaiQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G6YYBhkKt06a2SOdZtZsKRhFB5Y
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] shibboleth and the nonce
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: Thu, 24 Jul 2014 21:13:09 -0000

On 07/24/2014 12:05 PM, Adam Langley wrote:
> On Thu, Jul 24, 2014 at 11:21 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> As far as I am aware, there are no concrete concerns about implicit
>> nonces from a straight-up security perspective.  Is that right?
> 
> For polynomial MACs, no. (For CBC mode, yes.)
> 
>> The previous response to suggestions that the nonce was a required
>> input was to have a counter produce the nonce input, with a matching
>> counter and validation in the module.
>>
>> The new information yesterday was that David McGrew suggested that the
>> nonce needed to be arbitrary.  In that case, do we actually need the
>> input to be validated?  Does the certification process check that the
>> module produces different output for different nonces by starting
>> separate module instances with the same values for all other inputs
>> (keys, ad, and plaintext) then varying the input nonces?
>>
>> I'm sure that there are other concerns, but it's hard for me to make
>> an assessment based on the information made available thus far.
> 
> I'm not sure that I understand David McGrew's reported suggestion here.
> 
> I thought that the concern was that the "crypto module" (being the
> thing that is validated) needs to ensure that nonces don't repeat
> because the security of the system should be a property of the crypto
> module alone.
> 
> In that case, the module can either generate random nonces itself, or
> it can use a counter. In either case, the nonce isn't an input to the
> module when encrypting. If it were then, in order to establish
> uniqueness, the module would need to remember a list of all previous
> nonces.
> 
> With AES-GCM, the nonces are explicit which allows the crypto module
> to generate them itself and report them to the TLS layer for
> transmission. With implicit nonces, the crypto module can use a
> counter and the counter keeps in sync with the TLS sequence number.

Would it be practical for the crypto module to have an interface
"encrypt this payload; choose your own nonce, but that nonce had better
be X"?

The implicit nonce (for AES-GCM, anyway) is a *counter*.  Surely the
crypto module and the TLS stack can agree on how to increment a number.

--Andy