Re: [TLS] Requesting feedback on TACK draft
"Lewis, Nick" <nick.lewis@usa.g4s.com> Mon, 01 July 2013 09:03 UTC
Return-Path: <nick.lewis@usa.g4s.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9821F9C2B for <tls@ietfa.amsl.com>; Mon, 1 Jul 2013 02:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level:
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrOszs9wJA2K for <tls@ietfa.amsl.com>; Mon, 1 Jul 2013 02:03:03 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6D21F91BF for <tls@ietf.org>; Mon, 1 Jul 2013 02:03:01 -0700 (PDT)
Received: from [85.158.137.19:15876] by server-9.bemta-3.messagelabs.com id DA/94-31358-2C541D15; Mon, 01 Jul 2013 09:02:58 +0000
X-Env-Sender: nick.lewis@usa.g4s.com
X-Msg-Ref: server-13.tower-39.messagelabs.com!1372669378!3156364!1
X-Originating-IP: [89.206.228.155]
X-StarScan-Received:
X-StarScan-Version: 6.9.9; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29817 invoked from network); 1 Jul 2013 09:02:58 -0000
Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-13.tower-39.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2013 09:02:58 -0000
Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Mon, 1 Jul 2013 10:02:57 +0100
From: "Lewis, Nick" <nick.lewis@usa.g4s.com>
To: "'tls@ietf.org'" <tls@ietf.org>
Date: Mon, 01 Jul 2013 10:02:57 +0100
Thread-Topic: Re: [TLS] Requesting feedback on TACK draft
Thread-Index: Ac52Oe/4tq53Hc7oSVKyVV+P1lq9zw==
Message-ID: <AAE0766F5AF36B46BAB7E0EFB927320630E4A54175@GBTWK10E001.Technology.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54175GBTWK10E001Te_"
MIME-Version: 1.0
Subject: Re: [TLS] Requesting feedback on TACK draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 01 Jul 2013 09:03:10 -0000
>While people are looking at that, there's also the encrypt-then-MAC draft, >http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.txt, >which has been stable for about as long, has already been deployed by several vendors, >and for which TLS extension 0x10 has been de facto claimed, >so it'd be good to get this published to legitimise the use >(and to document what's already being deployed in production). As I recall there were three proposals for resolving the padding bug in TLS 1. An extension for Pad First (i.e. padding before an otherwise standard TLS mode of operation) 2. An extension for Encrypt-then-MAC (i.e. this draft) 3. The replacement of each existing cipher suite with an equivalent AEAD one Was any consensus achieved as to the best approach? -- Nick ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338. This communication may contain information which is confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs.
- [TLS] Requesting feedback on TACK draft Trevor Perrin
- Re: [TLS] Requesting feedback on TACK draft Peter Gutmann
- Re: [TLS] Requesting feedback on TACK draft Lewis, Nick
- [TLS] padding bug (was: Re: Requesting feedback o… Peter Saint-Andre
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Eric Rescorla
- Re: [TLS] padding bug (was: Re: Requesting feedba… Alfredo Pironti
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Yaron Sheffer
- Re: [TLS] padding bug (was: Re: Requesting feedba… Paterson, Kenny
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Adam Langley
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Dr Stephen Henson
- Re: [TLS] padding bug Nico Williams
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug (was: Re: Requesting feedba… Bodo Moeller
- Re: [TLS] padding bug (was: Re: Requesting feedba… Paterson, Kenny
- Re: [TLS] padding bug Brian Smith
- Re: [TLS] padding bug Martin Rex
- [TLS] Encrypt-then-MAC again (was Re: padding bug) Michael D'Errico
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Watson Ladd
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Michael D'Errico
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ben Laurie
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Bryan C. Geraghty
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- [TLS] Would this fix RC4 again? (was Re: Encrypt-… Michael D'Errico
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Watson Ladd
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Paterson, Kenny
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Nikos Mavrogiannopoulos
- Re: [TLS] Would this fix RC4 again? (was Re: Encr… Jacob Appelbaum
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Ralf Skyper Kaiser
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Alex Elsayed
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Paterson, Kenny
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- Re: [TLS] Encrypt-then-MAC again (was Re: padding… Martin Rex
- [TLS] draft-mavrogiannopoulos-new-tls-padding-00 Martin Rex
- Re: [TLS] draft-mavrogiannopoulos-new-tls-padding… Nikos Mavrogiannopoulos