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

"Christian Kahlo" <christian.kahlo@ageto.net> Sun, 02 November 2014 21:32 UTC

Return-Path: <christian.kahlo@ageto.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 1EF441A1A29 for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 13:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 ulMMSUMlYgtc for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 13:32:20 -0800 (PST)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA1C1A0410 for <tls@ietf.org>; Sun, 2 Nov 2014 13:32:20 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id d1so4958949wiv.15 for <tls@ietf.org>; Sun, 02 Nov 2014 13:32:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:reply-to:from:to:cc:references :in-reply-to:subject:date:organization:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=tY4C/s04Nve+tijRdOxzkEnfiNbla6jkg61zeraCNmg=; b=RB1K1SAiTLij7s7TsfpzVDiIkXATfQ2DGh/KSaDaoHa1OInC8zoEaeG5rh6L1e+OF3 vRjDxhOLcHbyDYRjrxfFeMYysP6kJEU5kjEZYvlbHYvzO6v+3wLz4l6QjiX8IsUSOQTm hn2gEe3j5d/9NkMc+pcnyzJ7/VUKosW1Lbx3dvx//+P1hNfhtzLoKD9hr+CXPR7tjpp/ gFb9G5qO6VvNDzSW+JfjgCq19hxysv8h5yLSwBfY3CsZWnDh6WriYFEy7W/ZLaVBWqqq 5tXzgHt3VmkEYwteW9dtAtSKwS+O4AC3nYjVrGrIRhHgCz/zhio90cdVGIv0luuImw/d eN7w==
X-Gm-Message-State: ALoCoQnqh7lBZrofHewTDQXG9fRVTE0ZNe/hR/SIJ6vjfK+JsUwUIoJJhi0dv+o3HV9KWRx/T9mX
X-Received: by 10.180.12.136 with SMTP id y8mr11897670wib.73.1414963938913; Sun, 02 Nov 2014 13:32:18 -0800 (PST)
Received: from THINK2 (cable-158-181-87-250.cust.telecolumbus.net. [158.181.87.250]) by mx.google.com with ESMTPSA id n4sm6499758wiz.17.2014.11.02.13.32.17 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Nov 2014 13:32:18 -0800 (PST)
Message-ID: <5456a2e2.4456b40a.3bc8.25c1@mx.google.com>
X-Google-Original-Message-ID: <002101cff6e4$7c751ce0$755f56a0$@kahlo@ageto.net>
From: Christian Kahlo <christian.kahlo@ageto.net>
To: 'Nikos Mavrogiannopoulos' <nmav@redhat.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> <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com>
In-Reply-To: <222598372.3223019.1414913562380.JavaMail.zimbra@redhat.com>
Date: Sun, 02 Nov 2014 22:32:20 +0100
Organization: AGETO Innovation GmbH
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/2G2jPupPc5GybTa6yRfBBtLAZ1wAAm4eg61IkWm/rUJe4sA==
Content-Language: de
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Brs1tf3FV8FIrhU6ijerUemeflY
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
Reply-To: c.kahlo@ageto.net
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 21:32:22 -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 fact there are very few and rare clients using "03 00" in the record
version field. The only clients I know of are some custom probers.

> 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.".

OK. Fixed. Checked In. Deployed.