Re: [TLS] rfc7366: is encrypt-then-mac implemented?

Nikos Mavrogiannopoulos <nmav@redhat.com> Sun, 02 November 2014 07:32 UTC

Return-Path: <nmavrogi@redhat.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 6C47D1A7003 for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 00:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KA_epd7hfsMJ for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 00:32:48 -0700 (PDT)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAB11A6FF3 for <tls@ietf.org>; Sun, 2 Nov 2014 00:32:47 -0700 (PDT)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA27WhTH009598; Sun, 2 Nov 2014 02:32:43 -0500
Date: Sun, 02 Nov 2014 02:32:42 -0500
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: c kahlo <c.kahlo@ageto.net>
Message-ID: <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com>
In-Reply-To: <5455577f.e402c20a.6dee.2253@mx.google.com>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz> <op.xonuwux33dfyax@killashandra.invalid.invalid> <54555161.1040606@polarssl.org> <5455577f.e402c20a.6dee.2253@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.5.82.6]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922)
Thread-Topic: rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg61IkWm8=
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T5zRa5NBeJvMp_DgVqkynovG0Fk
Cc: Manuel Pégourié-Gonnard <mpg@polarssl.org>, tls@ietf.org
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: Sun, 02 Nov 2014 07:32:54 -0000

----- Original Message -----
> Yes, SSLv3 is explicitly unsupported. As there is no handshake back-
> ward compatibility with SSLv3 "03 00" is forbidden at the record level.

That's pretty pointless and harms interoperability. With that you are not 
forbidding SSL 3.0, but all implementations which use 3.0 in the record 
version for client hello. That was widely used as a mitigation in the past
for other broken servers that only accepted SSL 3.0 version field.

In any case, the version in TLS record indicates the record format, not the 
negotiated version, which is present in the client hello handshake packet.

The last two paragraphs of http://tools.ietf.org/html/rfc5246#appendix-E.1
make that clear: "Thus, TLS servers compliant with this specification MUST accept
any value {03,XX} as the record layer version number for ClientHello.".

regards,
Nikos