Re: [TLS] Version in record MAC

"David McGrew (mcgrew)" <mcgrew@cisco.com> Thu, 22 October 2015 14:00 UTC

Return-Path: <mcgrew@cisco.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 1AB261ACDB9 for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 07:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 KbS5M7Me2f2C for <tls@ietfa.amsl.com>; Thu, 22 Oct 2015 07:00:04 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5AE1ACDBF for <tls@ietf.org>; Thu, 22 Oct 2015 07:00:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13522; q=dns/txt; s=iport; t=1445522404; x=1446732004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6hNTz1zQpWmao2ZcWoHU7CJi5bC23GwQCntSxWGbO/4=; b=cDEH5MktrvLXKjQyHO3tzSYEJn2krQq1MJlVDJFtwkRfTW+xCNOFM8qz 5M7sdQJwCAesPRigCg9CwN16h0f8wQQ6WYbCFlovx48w/hHLWIJYeR8R+ MaN3uYPijbyHagM1HN/twbtOBjZVwT6TCwVR+Zplwl3dHmj1p0Jho4pjH o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D2AQBl6yhW/4oNJK1egmlNVG8GvhUBDYFZIYV8AhyBKDgUAQEBAQEBAYEKhC4BAQEEIwpMEAIBCA4DBAEBARUSAwICAh8RFAkIAgQBDQUIiBMDEg2yFY4ZDYRnAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1glCCOQQGAQqCX4FFBZJdg04BhRiGEIFugieSOYdMAREOAQFChANyAYU8gQYBAQE
X-IronPort-AV: E=Sophos; i="5.20,182,1444694400"; d="scan'208,217"; a="38074362"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP; 22 Oct 2015 14:00:03 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9ME03RX006064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 14:00:03 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 08:59:42 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 08:59:43 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Eric Rescorla <ekr@rtfm.com>, Adam Langley <agl@imperialviolet.org>
Thread-Topic: [TLS] Version in record MAC
Thread-Index: AQHRDM4vbQUJq0igmkWy2KnwRiRoYZ53iiqA
Date: Thu, 22 Oct 2015 13:59:42 +0000
Message-ID: <811734cd29d64adc98c5388870611575@XCH-ALN-004.cisco.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>
In-Reply-To: <CABcZeBOc_9i83j4rjxve8PuBPWdd8eCVN2wQth3G0=T_xz1UKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.41.221]
Content-Type: multipart/alternative; boundary="_000_811734cd29d64adc98c5388870611575XCHALN004ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/69PhdkyJu0HY36-MkGJyvtfDqok>
Cc: "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: Thu, 22 Oct 2015 14:00:11 -0000

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<mailto:agl@imperialviolet.org>> wrote:
On Monday, October 19, 2015, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 19 October 2015 at 11:17, Eric Rescorla <ekr@rtfm.com<mailto: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<mailto:agl@imperialviolet.org> https://www.imperialviolet.org