Re: [TLS] rfc7366: is encrypt-then-mac implemented?
"Yngve N. Pettersen" <yngve@spec-work.net> Sat, 01 November 2014 19:25 UTC
Return-Path: <yngve@spec-work.net>
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 124001A0396 for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 12:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6] 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 6YndZJ-p3E_z for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 12:25:47 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2274B1A0390 for <tls@ietf.org>; Sat, 1 Nov 2014 12:25:46 -0700 (PDT)
Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:52511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <yngve@spec-work.net>) id 1XkeIy-0002G7-Sv for tls@ietf.org; Sat, 01 Nov 2014 20:25:44 +0100
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
Date: Sat, 01 Nov 2014 20:25:32 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.xonuwux33dfyax@killashandra.invalid.invalid>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KVtX4BW67fZeIYnatUYS1mVKFtc
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
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: <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: Sat, 01 Nov 2014 19:25:50 -0000
Hi, Warning, long post. For reference, I have tried to implement RFC 7366 in my TLS Prober, but I have not been able to establish a connection with the "eid" server. It seems to have some non-standard requirements to the client that AFAICT have not been documented anywhere. On Wed, 29 Oct 2014 15:38:41 +0100, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote: > Manuel Pégourié-Gonnard <mpg@polarssl.org> writes: > >> What I'm doing to get this is interpret TLSCipherText.length exactly as >> it is >> defined in RFC 5246 (6.2.3.2, page 22): >> >> The encrypted data length (TLSCiphertext.length) is one more than the >> sum of SecurityParameters.block_length, TLSCompressed.length, >> SecurityParameters.mac_length, and padding_length. >> >> Apparently to interoperate with the implementation at eid.vx4.net (and >> with >> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding >> SecurityParameters.mac_length. I couldn't find this explicitly stated >> anywhere. > > Section 3 of RFC 7366 says: > > In [2] notation the overall packet is then: > > struct { > ContentType type; > ProtocolVersion version; > uint16 length; > GenericStream/BlockCipher fragment; > opaque MAC; > } TLSCiphertext; > > This is identical to the existing TLS layout with the only difference > being that the MAC value is moved outside the encrypted data. I am starting to wonder if the confusion about this spec update is partly due to the way the record structure is defined, with the length separate from the data vectors. This separation have been a problem in connection with at least some extensions. The way a TLS Protocol record is defined in previous versions (Using TLS 1.2), before this update is, can a generic way be rewritten as: struct { ContentType type; ProtocolVersion version; opaque record_data<0..maxlength> } TLS_Record; This is how all clients and servers will parse current SSL and TLS versions' records on the wire, and also how all the intermediate servers (the ones that are causing concern for version rollback recovery) will be parsing the TLS traffic. The field record_data containing a strucure of exactly the length of record_data struct { select(encryption_mode) { case plaintext: TLS_Plaintext_data; case stream_encrypted: TLS_Stream_Encrypted_data; case block_encrypted: TLS_Block_Encrypted_data; } } TLS_Record_payload; struct { opaque plaintext[TLS_Record.record_data.length]; } TLS_Plaintext_data; stream-ciphered struct { opaque [TLS_Record.record_data.length-MAClength]; opaque MAC[MAClength]; } TLS_Stream_Encrypted_data; struct { opaque IV[SecurityParameters.record_iv_length]; block_encrypted_stream struct { opaque [TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1]; opaque MAC[MAClength]; uint8 padding [paddinglength]; uint8 paddinglength; } encrypted; } TLS_Block_Encrypted_data; With RFC7366 the format for the encrypted record payloads got changes, and it seems to me that the problem is a disagreement of what the length field in the TLSCipherText record applies to. In the following I will assume that we (the TLS WG) while implementing peers that understand the Encrypt then MAC record format, also wants to Maintain backwards compatibility with all existing infrastructure (such as firewalls) that processes the TLS ciphertext records, but which do not know about RFC 7366. Given these requirment, I think the TLS_Record_payload structure have to be redefined as struct { select(encryption_mode) { case plaintext: TLS_Plaintext_data; case stream_encrypted: TLS_EtM_Stream_Encrypted_data; case block_encrypted: TLS_EtM_Block_Encrypted_data; } } TLS_Record_payload; struct { stream-ciphered opaque fragment[TLS_Record.record_data.length-MAClength]; opaque MAC[MAClength] } TLS_EtM_Stream_Encrypted_data; struct { opaque IV[SecurityParameters.record_iv_length]; block-ciphered struct { opaque fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1]; uint8 padding [paddinglength]; uint8 paddinglength; } encrypted; opaque MAC[MAClength]; } TLS_EtM_Block_Encrypted_data; I think one thing that is to be determined is whether this rewritten structure definitions accurately describes both the old format and the new RFC 7366 format. Do they? If RFC 7366 means to say that the MAC field is no longer part of the record_data field (and not counted in the length field), then that is going to cause trouble, because processors that are not aware of the extension will then read the first bytes of the MAX as the ContentType field and the version field, probably resulting in a connection closure. The second issue that seems to have developed is which value to use as the length part of the MAC calculation. RFC 7366 version: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + IV + ENC(content + padding + padding_length)); Adapted to my rewritten structure the question is if the MAC (for block cipher encryption) is calculated as MAC(MAC_write_key, seq_num + TLS_Record.type + TLS_Record.version + TLS_Record.record_data.length + IV + ENC(content + padding + padding_length)); or MAC(MAC_write_key, seq_num + TLS_Record.type + TLS_Record.version + TLS_EtM_Block_Encrypted_data.fragment.length + IV + ENC(content + padding + padding_length)); As written, as I understand it, and assuming compatibility with ignorant intermediates, RFC 7366 specifies the first formula. However, I have the impression that some think that either 1) the MAC field is not part of the bytes counted as TLSCipherText.length or 2) the length field in the MAC is really the length of the fragment field. IMO case 1 will lead to interoperability problems with intermediates, and case 2 is not what the specification says if we assume interoperability. I think that before we continue the discussion we need to decide what the record format is on the wire, and if it is compatible with the old format, or not. Then we need to decide which value is used in the MAC formula. My suggestion for an answer to the first question is that we have to maintain backwards compatibility with ignorant intermediates, which means that TLSCipherText.length MUST count the MAC bytes, not just the fragment (including padding). Regarding the second question, IMO it does not really matter much which value is used. However, it is probably easier to use the length of the encrypted block, rather than TLSCipherText.length, since TLSCipherText.length have to be calculated instead of derived from the MACed encrypted block. Given the current confusion we need at least an errata that accurately specifies which values include which data. However, given that such changes may modify the meaning more than a normal errata do, perhaps a better idea is a new RFC that either replace RFC 7366 or one that specifies a new extension ID and deprecate the old one, so that we reduce the potential for confusion among implementations? After all, some implementers might miss the existence of the errata, and in this case the errata would be important for the proper understanding of the specification. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/
- [TLS] rfc7366: is encrypt-then-mac implemented? Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Ilari Liusvaara
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Henrick Hellström
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- [TLS] record-level version number in ClientHello Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] record-level version number in ClientHe… Martin Thomson
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- [TLS] rfc7366: status Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: status Martin Rex