Re: [TLS] shibboleth and the nonce

Andy Lutomirski <> Thu, 24 July 2014 21:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9EB501A035D for <>; Thu, 24 Jul 2014 14:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NyPA0KNr45CX for <>; Thu, 24 Jul 2014 14:13:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5283D1A0146 for <>; Thu, 24 Jul 2014 14:13:08 -0700 (PDT)
Received: by with SMTP id ey11so4706528pad.38 for <>; Thu, 24 Jul 2014 14:13:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id k6mr13932842pdl.120.1406236387724; Thu, 24 Jul 2014 14:13:07 -0700 (PDT)
Received: from ( []) by with ESMTPSA id be7sm8733282pdb.37.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 14:13:06 -0700 (PDT)
Message-ID: <>
Date: Thu, 24 Jul 2014 14:13:04 -0700
From: Andy Lutomirski <>
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 <>, Martin Thomson <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] shibboleth and the nonce
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> <> 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.