Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
Eric Rescorla <ekr@rtfm.com> Sat, 08 July 2017 14:46 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD78129B2A for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 07:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 so6u52jMwcmy for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 07:46:26 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 22688129B01 for <tls@ietf.org>; Sat, 8 Jul 2017 07:46:26 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id f194so17961005yba.3 for <tls@ietf.org>; Sat, 08 Jul 2017 07:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wHjMcCY5LI7nv43R60cKfDKgzW3eQ+gkpBjGXKj82jo=; b=LyDXq2Mkqbo5CTNt42gqvQr8hYPACs8PTOzP0qxtDzlnOoYOxa164QCI2Lr02lJCys bKc92BaFy60SEC+Ozc7yEEBX46Yf+dquKy+fjSnJkD5mNU73VYWi87SP+4Hjx4cnfHiD gOAjxqnoNIvwEGGEubN9P+gnHvmNnsp1W5L/8grrqWtPq4xB4mICD2LRma7+r7PyjXcU PErHiqM5EPIp2mIRBlHQNwN0HHBI6DJ7N/rSb/sYVA2L4zvk0K3KV3UCFEIJZHc7zCj0 OydrYJU+m0R3yr2HdM9wYywIkRi7Exsf67VzsWMflE2pTB+3HjBPTmGzXo0GCNTBKbMF m3gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wHjMcCY5LI7nv43R60cKfDKgzW3eQ+gkpBjGXKj82jo=; b=TLhpwe7m7Ao7LXytpNMVPjAXmOU06A4LjNSSZB8vOnX8P4Y8j3d8BMmTUoUsDV9Mw6 xZqYDClM2qMhi1hmya75/UMok/KGuv36iqf7cgx2RyQsNOM6h3wbeaUvRUeKNizXyVFZ Vc5Stfa1xUDkTThKLh3TFclUwU/M75w8RB+LW++led8jTjIm+7FQH1D3WaPz+4i/b0RI tmp/VSonfO1Om3De7br8IzZafKNqsEQJh+r8MbCcVkQi+VK6+9vSh9M9RAM2kvPUDNOb u9+buidyoC4JF+2fZTHEuCrOuYB8q8S9ggw2/gPRunUnvpCGwe6y09w0o47FkwWg14tA 9Z+w==
X-Gm-Message-State: AIVw112lq1jbm3c7N4WvbX4rmYAZFsc2ul6vvRxNsqfyan8/sAjQIuo3 ENvksoVpIFJM4WmOdCaVgMeZIOzkHIsv/puKMw==
X-Received: by 10.37.68.87 with SMTP id r84mr8532508yba.229.1499525185172; Sat, 08 Jul 2017 07:46:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.215.9 with HTTP; Sat, 8 Jul 2017 07:45:44 -0700 (PDT)
In-Reply-To: <ff1ba8ba-af2c-e079-6c07-4d97f4d80737@ri.se>
References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <ff1ba8ba-af2c-e079-6c07-4d97f4d80737@ri.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 08 Jul 2017 07:45:44 -0700
Message-ID: <CABcZeBM72_axpp9dUkud9GZ5Nyo_XvWMDsQtZbqVCyfmGSdbOQ@mail.gmail.com>
To: Marco Tiloca <marco.tiloca@ri.se>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f5f3efe91630553cf69ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bI1oBj_HR_Qbwgl6YVUrPysChjo>
Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 08 Jul 2017 14:46:28 -0000
Document: draft-tiloca-tls-dos-handshake-00.txt I'm trying to understand the threat model and operating model this is designed for. Let's start with the threat model. The anti-DoS mechanisms in DTLS are specifically oriented towards attackers who are not on-path, because on-path attackers can, as you say, obtain the HRR/HVR. You say: DTLS 1.2 as well as both TLS 1.3 and DTLS 1.3 provide the optional Cookie exchange as possible solution to mitigate this Denial of Service attack. While this makes the attack more complicated to mount, a well determined and resourceful adversary able to spoof valid IP addresses can still successfully perform it, by intercepting the possible server response including the Cookie and then echoing it in the second ClientHello. This is particularly doable in case the handshake is not based on Pre-Shared Key exchange modes. I take from this that your assumed threat model is an attacker who is minimally a man-on-the-side (i.e., able to read traffic and inject his own but not block) and maximally a full active attacker able to block data. Is that correct? Depending on the specific protocol version and the key establishment mode used in the handshake, the attack impact can range from single replies triggered by invalid ClientHello messages, to the server performing advanced handshake steps with consequent setup of invalid half-open sessions. Especially if performed in a large-scale and distributed manner, this attack can thwart performance and service availability of (D)TLS servers. Moreover, it can be particularly effective in application scenarios where servers are resource- constrained devices running DTLS over low-power, low bandwidth and lossy networks. It seems like the attack you are considering is one in which the attacker generates DTLS handshakes and then forces the DTLS server to either perform computations or hold state open (e.g., by doing a handshake or a partial handshake and then stopping) Is that correct? Assuming I am correct, the design you describe here seems much more complicated than necessary [0]. Consider the simpler design: - The client contacts the TA - TA generates a new value C = HMAC(k_M, N) and sends that to the client - the client inserts C in the ClientHello. The major downside is that this allows an on-path attacker to steal C and put it in their own CH, but so what? The attacker is still rate limited by the number of valid clients, and (at least) a fully active attacker doesn't need to substitute their own handshake messages for the valid clients because they can force the server to perform computations by playing the client messages and leave the server in a half-open state by blocking some client messages. I suppose you could argue that they could negotiate cipher suites that are more expensive to the server, but that seems like a fairly weak attack. Just to touch briefly on resumption: why do you need this mechanism at all for that? The client and server already have an assocation so the server knows that it has a valid client without any new assertion from the TA. -Ekr [0] It also, won't work. In particular, having the client send a MAC over the CH leads to having to zero out portions of the CH, which is going to create implementation problems in two ways. First, it creates a circular dependency with the TLS 1.3 PSK binder, so you'll need to have an exception there. Second, the zero-ing out trick you use is actually quite annoying to implement in many TLS stacks (it would be so in NSS). On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca <marco.tiloca@ri.se> wrote: > Dear all, > > FYI, we have recently submitted a new draft proposing an extension for > (D)TLS 1.2/1.3. > > The solution described in the draft addresses Denial of Service attacks > against the handshake protocol, allowing servers to promptly abort invalid > session set ups. > > Feedback and comments are of course very welcome. Thanks a lot! > > Best regards, > /Marco > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-tiloca-tls-dos- > handshake-00.txt > Date: Wed, 28 Jun 2017 07:40:45 -0700 > From: internet-drafts@ietf.org > To: Marco Tiloca <marco.tiloca@ri.se> <marco.tiloca@ri.se>, Ludwig Seitz > <ludwig.seitz@ri.se> <ludwig.seitz@ri.se>, Maarten Hoeve > <maarten.hoeve@encs.eu> <maarten.hoeve@encs.eu> > > A new version of I-D, draft-tiloca-tls-dos-handshake-00.txt > has been successfully submitted by Marco Tiloca and posted to the > IETF repository. > > Name: draft-tiloca-tls-dos-handshake > Revision: 00 > Title: Extension for protecting (D)TLS handshakes against Denial of Service > Document date: 2017-06-28 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt > Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/ > Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00 > > > Abstract: > This document describes an extension for TLS and DTLS to protect the > server from Denial of Service attacks against the handshake protocol. > The extension includes a Message Authentication Code (MAC) over the > ClientHello message, computed by the Client through key material > obtained from a Trust Anchor entity. The server registered at the > Trust Anchor derives the same key material and checks the MAC to > determine whether continuing or aborting the handshake. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
- [TLS] Fwd: New Version Notification for draft-til… Marco Tiloca
- Re: [TLS] Fwd: New Version Notification for draft… Eric Rescorla
- Re: [TLS] Fwd: New Version Notification for draft… Marco Tiloca
- Re: [TLS] Fwd: New Version Notification for draft… Eric Rescorla
- Re: [TLS] Fwd: New Version Notification for draft… Benjamin Kaduk
- Re: [TLS] Fwd: New Version Notification for draft… Eric Rescorla
- Re: [TLS] Fwd: New Version Notification for draft… Marco Tiloca