IETF Logo Mail Archive

Re: [TLS] WGLC: draft-ietf-tls-session-hash

Stephen Checkoway <s@pahtak.org> Mon, 24 November 2014 11:58 UTC

Return-Path: <s@pahtak.org>
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 431FA1A6EE6 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 03:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aHkiwQ0kUJPQ for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 03:58:53 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EF41A6EE5 for <tls@ietf.org>; Mon, 24 Nov 2014 03:58:53 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id k15so6081380qaq.24 for <tls@ietf.org>; Mon, 24 Nov 2014 03:58:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=unUXnrLb8sKjuH9n7qAos+R+lgG8niKlfR1EHSLjc8E=; b=AOABJJTvrUDpvWIhkawWSMumPNya657GU5EfmgDEl4x/4uW5ewiraTJ/BEQpATDaFH wLPqxjtx5AFsgSZu+htTjLz1XY55HQewU7pfS5xhZopWoBkc3peiCfQDcMVQhIe2v2Kv rCS/QzFkXh8FEnlyDpnEbeW2RZbzOP5nICSeWn3SVREoy+scblO6NgTBRNZCkN5Wo+wD 1mw1zXTi5yPxKMxD8M1r9IYUdnt0PYdgksgY1O03I28xWN4c788vja+ug8mAFIMhokq2 3f2ZXDYldWjcFyATiWw/UZk40/Qu2TPE5Z7+dR8Wrs6zEUwo7fpqHZPX2RajK06yjxKD 6jSA==
X-Gm-Message-State: ALoCoQkL0Wwdba0K2giBBZZtLPEE1JquN4l1noKdD2+qahjCV/yOrhe9TprpCY/wOQOFF4Ky796v
X-Received: by 10.224.94.9 with SMTP id x9mr12913018qam.45.1416830333005; Mon, 24 Nov 2014 03:58:53 -0800 (PST)
Received: from zbox.pahtak.org ([68.48.196.126]) by mx.google.com with ESMTPSA id b17sm9898069qah.35.2014.11.24.03.58.51 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Nov 2014 03:58:51 -0800 (PST)
Received: from [10.0.1.8] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id ABE32AC2842; Mon, 24 Nov 2014 06:58:49 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Stephen Checkoway <s@pahtak.org>
In-Reply-To: <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>
Date: Mon, 24 Nov 2014 06:58:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B773EC7F-9CE8-4A23-AE53-9F2D4264B4F2@pahtak.org>
References: <E3E12F78-101D-4BA8-9EFB-53C24362066E@ieca.com> <62165FC2-540D-48A5-A7AC-3D6D9087FDD2@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QrU7kbo7P-5vzpIlg1XNx5W7q9c
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] WGLC: draft-ietf-tls-session-hash
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: Mon, 24 Nov 2014 11:58:55 -0000

On Nov 24, 2014, at 3:44 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Third issue: Why can’t an attacker disable this protection by simply omitting the extension from both its ClientHello and ServerHello?  At least in the short term it won’t be practical to fail a handshake because the other side doesn’t support this extension. I guess the answer is that the ruse will work, but the other attacks mentioned in TRIPLE-HS will fail, but it’s not clear to me why. A can still proxy unchanged records from C to S if the connections are resumptions. Perhaps servers should be prohibited from resuming a session set up without this extension if the ClientHello does include the extension.

The draft currently says "Clients and servers SHOULD NOT resume sessions that do not use the extended master secret..." Are you saying you want that to be MUST NOT?

-- 
Stephen Checkoway

v2.23.0 | Report a Bug | By Email