Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

Dave Garrett <davemgarrett@gmail.com> Sun, 27 December 2015 07:08 UTC

Return-Path: <davemgarrett@gmail.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 E0C971B2AF2 for <tls@ietfa.amsl.com>; Sat, 26 Dec 2015 23:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DLrA8J5QRn83 for <tls@ietfa.amsl.com>; Sat, 26 Dec 2015 23:08:14 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6909E1B2AF1 for <tls@ietf.org>; Sat, 26 Dec 2015 23:08:14 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id e32so38952035qgf.3 for <tls@ietf.org>; Sat, 26 Dec 2015 23:08:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=UTZzVvf5A+P9zWg959O1egKGX+xDiiu4YDyb7o8aMyE=; b=hsiyuoGBx1fVWSz/S5W+G14wqnOczf9V8V+Em59FOehwn5DFtPkdcV10UkBdVOabRC su2SZgiHkYUZZwO9zYR8wRCIIS/SpOdTexwCGJ9b9caMDl8nKx31K37S1rtabqD5Fg8e bqCty6qA4kPTClr6DHn6riyuyEHRb38lQQFdiDolTV+vFWVwFykg5FbVDPjmxBWQ9xTz Sx41o2yA/5dOmY2iFPj7ZNFOYTfrqCqtaJ6OiUMt8Yrh7+chZvpt+a/8F6JYG9woyJhl 0nhZKxncnlaU5G5XjlnwkRwNhQGSoc7nZCVb2KtTCpGBRybDoTPslx5BGRoI+zLh6jsr CxLQ==
X-Received: by 10.140.224.207 with SMTP id u198mr63957006qhb.67.1451200093593; Sat, 26 Dec 2015 23:08:13 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 93sm20503913qgx.16.2015.12.26.23.08.12 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 26 Dec 2015 23:08:12 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 27 Dec 2015 02:08:10 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <DM2PR0301MB06555FC15830293E0C4E381AA8E50@DM2PR0301MB0655.namprd03.prod.outlook.com> <201512241748.25385.davemgarrett@gmail.com> <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com>
In-Reply-To: <CABcZeBMDXrCxjp+RtHGsxsZRGjEUJOy8BCxRLu4pMbFXkNcnEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201512270208.11253.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YedQbJmfBqVbZeClFUza7qCDorw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake 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: <https://mailarchive.ietf.org/arch/browse/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, 27 Dec 2015 07:08:16 -0000

On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote:
> Well, this is a general requirement any time the record MAC is bad:
> See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2
> "If the decryption fails, a fatal “bad_record_mac” alert MUST be generated."
> 
> On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > The current text doesn't explicitly say how to handle 0-RTT data that it
> > thinks it should be able to decrypt but can't. After rereading things a bit
> > I think you're correct in that the correct course of action the spec
> > currently expects is to abort, however implementers frequently err on the
> > side of working partially vs not at all when given any wiggle room. A clear
> > hard "MUST abort" on failed decrypt of 0RTT data would deal with this and
> > avoid any other possible misunderstanding. Either do or do not; no try.
> 
> If you have suggested text, I'd be happy to see a PR.

Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT records aren't allowed special treatment and errors on handling MUST NOT result in a 1-RTT fall back.


Dave