Re: [TLS] Version in record MAC

Eric Rescorla <ekr@rtfm.com> Tue, 27 October 2015 12:50 UTC

Return-Path: <ekr@rtfm.com>
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 E44281A886F for <tls@ietfa.amsl.com>; Tue, 27 Oct 2015 05:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 sGRj6Tgs_JOh for <tls@ietfa.amsl.com>; Tue, 27 Oct 2015 05:50:16 -0700 (PDT)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 B76661A886B for <tls@ietf.org>; Tue, 27 Oct 2015 05:50:15 -0700 (PDT)
Received: by ykdr3 with SMTP id r3so216479165ykd.1 for <tls@ietf.org>; Tue, 27 Oct 2015 05:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uXGekH/igubDPMfYx/fSWEOBTWTBndLsXKj4VUz4ZEc=; b=Jsr6oH4uG99RtGCunXZRqzBVNIIDiuqSbMJvFzcj+nOApkD2DSA36g4B/gigoYLMDM +EvN9Pq1dUKtP5iYD4b36tQDNnR4BHuajOrepENdUHsZHp1c56bbVVWG+7OM/8kw4P7E MC+NcIapGfXj1o5wKgtloIXyhE56rVnYj9hnx1P3mlqD7r2aVta8LWK9uNjIIJtvmBn9 R3yulflW/Buy/n8rqQWigRkHFI39UciBCHjPoDRYI6GkzAa88cinnRGqMWO9/KjATSCV ec9hUkVNSREM8j4zn5J0i0Dv8pW5Eod0B7Zx71SX3dTVUDpqtGsDlXRiz2ofUCZBoRFL fTiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uXGekH/igubDPMfYx/fSWEOBTWTBndLsXKj4VUz4ZEc=; b=DzYekB9KrUbGbdMeJqDIRwIZp00KYTjtCVWWuxY1N6yDrk0DC72m2owtfNy8kY+Kig hWMfDKCU/RI4/hsZTqk7Qk/5+12AfCltX8AGSNi1P0Q6SIuVWrZqmii0NUcTGwb0dUZi HYMulTHNpfyfHVdhGPqP6/QARUTcUtRMbomSnujXhRmbETa6AIUae3hGGUguAogNIF6g jttnM5HG2sRrUfa/6GKt8mSJtUbJsiAgurtF7c9KJq2j4meBeWJeX6oNEhaQAztAuZJB mHzYB9a4N20W21aWyrpjWGHNIGYJu5kXzEVKiMi10JWqgsa2m/XhoU1TuBGp6XfQgYP9 m4ew==
X-Gm-Message-State: ALoCoQnH8yFC8vtSv/GMM1j/odzsSfTnqIHyrheZro8CNpDORKUwPfyTX3rP9XtKQ7bVoEZHa5+S
X-Received: by 10.13.213.138 with SMTP id x132mr10846606ywd.223.1445950214966; Tue, 27 Oct 2015 05:50:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.221.85 with HTTP; Tue, 27 Oct 2015 05:49:35 -0700 (PDT)
In-Reply-To: <CABcZeBNZJkrVsA9UEN-ywpzUOZy4wJ=2=QDg-KhjNUCvMKi=HA@mail.gmail.com>
References: <CABcZeBODjk8rapgbNTST8bmFFVzKqB4tJyrvje-CTgk1=gfqFw@mail.gmail.com> <CABkgnnV+QrjcXJdZwwAGW-SpX0Z0_JroEVT-kMJgUAVe7DDQUw@mail.gmail.com> <CABcZeBOrL=TosONYfM_QPPYfT5N4VH7yR4hFw3Qt8W4V0uznkw@mail.gmail.com> <CABkgnnXis0mwqcsd1D0S61kqL6kvq9=ZU0BRbwbLH7Jesj0Y-w@mail.gmail.com> <CABcZeBNpV3uqOF4YohiCrtq03hR7LPnPGdny6yWB+zysVufiqA@mail.gmail.com> <CABkgnnWVJeeBuMitweCj=nOSB5cA-R-6btdQeWp0Bdnomd2XtQ@mail.gmail.com> <CAMfhd9V4WVxKbJh6KkNdVFGBGKh=tG5kC_7sPthOwhrrUi5eoQ@mail.gmail.com> <CABcZeBOc_9i83j4rjxve8PuBPWdd8eCVN2wQth3G0=T_xz1UKg@mail.gmail.com> <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.com> <CABcZeBNZJkrVsA9UEN-ywpzUOZy4wJ=2=QDg-KhjNUCvMKi=HA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 27 Oct 2015 08:49:35 -0400
Message-ID: <CABcZeBNOJNwL9Akbhnpd2fg8rk80BNYRkODRpqDb9nk2K_m1mg@mail.gmail.com>
To: "David McGrew (mcgrew)" <mcgrew@cisco.com>
Content-Type: multipart/alternative; boundary="001a114fa914ed41130523158420"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fM4Zh9DE5acvWiJ660oreK9ZDDs>
Cc: Adam Langley <agl@imperialviolet.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Version in record MAC
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: <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: Tue, 27 Oct 2015 12:50:19 -0000

Thinking about this a little more:

If we ever change the nonce construction to have an explicit nonce or
otherwise
not depend on the RSN (e.g., something like SIV) we're going to be sad if
we don't have the RSN in the AD. Obviously, we'd also need to change the
text about the nonce construction, so it's not like you could drop in a
construction
like this, but it would be slightly easier to do if we already MACed the
RSN.

I'm not sure which side of the fence I'm on here. What do others think?

-Ekr


On Thu, Oct 22, 2015 at 10:07 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Thanks for the quick response, David. I now agree with Martin and
> Adam that we should remove this.
>
> Chairs, I haven't seen any objections any reason I shouldn't make this
> change?
>
> -Ekr
>
>
> On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) <mcgrew@cisco.com>
> wrote:
>
>>
>>
>> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
>> *Sent:* Thursday, October 22, 2015 9:33 AM
>> *To:* Adam Langley
>> *Cc:* Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)
>> *Subject:* Re: [TLS] Version in record MAC
>>
>>
>>
>> I'm mostly convinced by this text in RFC 5116:
>>
>> http://tools.ietf.org/html/rfc5116#section-2.1
>>
>>
>>
>>    Because the authenticated decryption process
>>
>>    detects incorrect nonce values, no security failure will result if a
>>
>>    nonce is incorrectly reconstructed and fed into an authenticated
>>
>>    decryption operation.  Any nonce reconstruction method will need to
>>
>>    take into account the possibility of loss or reorder of ciphertexts
>>
>>    between the encryption and decryption processes.
>>
>> It would probably be worth checking with the cryptographers in the room.
>>
>> CCing Hugo and McGrew.
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley <agl@imperialviolet.org>
>> wrote:
>>
>> On Monday, October 19, 2015, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>> On 19 October 2015 at 11:17, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Yeah, I think that's riding the nonce far too hard.
>>
>> On what basis?  Any change in the nonce will cause the record
>> decryption to fail.  That's the property we're looking for here, isn't
>> it?
>>
>>
>>
>> I don't believe that there's any reason to include the sequence number in
>> the AD input of an AEAD. I think that an empty AD for TLS would be fine now
>> that the content type is encrypted. (Not that I deeply care either way.)
>>
>>
>>
>> Agreed.  Any value that always goes into the nonce doesn’t need to go
>> into the AD.
>>
>>
>>
>> David
>>
>>
>>
>>
>>
>> Cheers
>>
>>
>>
>> AGL
>>
>>
>>
>> --
>> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
>>
>>
>>
>
>