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

Dave Garrett <davemgarrett@gmail.com> Mon, 28 December 2015 07:32 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 47CE41A89E0 for <tls@ietfa.amsl.com>; Sun, 27 Dec 2015 23:32:08 -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 1XosqY3Cu_qT for <tls@ietfa.amsl.com>; Sun, 27 Dec 2015 23:32:06 -0800 (PST)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 9AE301A89D3 for <tls@ietf.org>; Sun, 27 Dec 2015 23:32:06 -0800 (PST)
Received: by mail-qg0-x22e.google.com with SMTP id e32so50948441qgf.3 for <tls@ietf.org>; Sun, 27 Dec 2015 23:32:06 -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=WqdeJR+z4Sw5bkzPgDk/pW+K513bPPFubw4IwI+dRXo=; b=FOoWlLNCouMeO3PAkHtPO2z4FPxmgPRE37+coAyj/jaKcByQ5e+X+RrJvUMR25v2YL wPUJuLwtqsuY2StRjVg3SuACGJPec1M9/SpBPxNDj9Bx0ZWiSyZaZQa8Zpsi+LEUugqU fWElS8D0DhJufZVwZxXGf5tWtR5cFzoW+OQWzz+RqWNJziZYbn4qgT+YLFTxLrUs/ami +TsNPaHHGUjdTBKD2Wt1x40q2sajSKUmCEHW1w9+Yj2nRjgfi0e45zF/1V7XvgSzbCOV 4heD+OxzIX974Xw+FVNOKOZ4cXJ9d0zqls50LuBpHPe3s/QRAMhLjjiplmsBPA8bIqUZ akPg==
X-Received: by 10.140.93.51 with SMTP id c48mr67743732qge.29.1451287925817; Sun, 27 Dec 2015 23:32:05 -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 i136sm4675597qhc.42.2015.12.27.23.32.05 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 27 Dec 2015 23:32:05 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Christian Huitema <huitema@microsoft.com>
Date: Mon, 28 Dec 2015 02:32:03 -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> <201512270208.11253.davemgarrett@gmail.com> <DM2PR0301MB06557834035ECF047BC3F88AA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
In-Reply-To: <DM2PR0301MB06557834035ECF047BC3F88AA8FB0@DM2PR0301MB0655.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201512280232.04005.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mFlTbCLhTajqfVHvqydPFs_IzsY>
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: Mon, 28 Dec 2015 07:32:08 -0000

On Sunday, December 27, 2015 11:55:16 pm Christian Huitema wrote:
> On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote:
> > 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
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftlswg.gith
> > ub.io%2ftls13-
> > spec%2f%23rfc.section.5.2.2&data=01%7c01%7chuitema%40microsoft.com%7
> > c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4
> > 7%7c1&sdata=nTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d
> > > "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.
> 
> Isn't that a part where TLS and DTLS will differ a lot?
> 
> For DTLS, we have to consider the packet injection threat. It is fairly easy to send some random bytes with a fake source to a UDP destination. Such attacks should not cause the DTLS association to fail! The normal behavior ought to be to just ignore UDP packets that fail to decrypt. This would cause 0-RTT rejects to just result in dropped packets. Can we ensure that the handshake protocol is robust against that?

One idea might be to include a hash of all early data records' ciphertext in the "early_data" extension. This lets them stay out of the handshake hash yet still have their hash be covered by it. So long as servers verify all successfully decrypted early data records against this hash before processing them further, and abort if something is missing, then this could be done safely. More complex, though.


Dave