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
- [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Colm MacCárthaigh
- Re: [TLS] Version in record MAC David Benjamin
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Russ Housley
- Re: [TLS] Version in record MAC Adam Langley
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC David McGrew (mcgrew)
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Ilari Liusvaara
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Adam Langley
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Eric Rescorla
- [TLS] Collision issue in ciphertexts. Dang, Quynh
- Re: [TLS] [Cfrg] Collision issue in ciphertexts. Watson Ladd
- Re: [TLS] [Cfrg] Collision issue in ciphertexts. Dang, Quynh
- [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Watson Ladd
- Re: [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Watson Ladd
- Re: [TLS] Data limit for GCM under a given key. Tony Arcieri
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Yoav Nir
- Re: [TLS] Data limit for GCM under a given key. Dave Garrett
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Dave Garrett
- Re: [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Quynh Dang
- Re: [TLS] Data limit for GCM under a given key. Yoav Nir