Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt

Marco Tiloca <> Sun, 09 July 2017 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F5DC126C23 for <>; Sun, 9 Jul 2017 02:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OoMoHiR9lxQQ for <>; Sun, 9 Jul 2017 02:44:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C615124D68 for <>; Sun, 9 Jul 2017 02:44:44 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 6C09020368B; Sun, 9 Jul 2017 09:44:41 +0000 (UTC)
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sun, 9 Jul 2017 11:44:41 +0200
To: Eric Rescorla <>
CC: "" <>
References: <> <> <>
From: Marco Tiloca <>
Message-ID: <>
Date: Sun, 9 Jul 2017 11:44:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g843illcPN8r5XQhxM5CX1oLuVSxAio4t"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.2 cv=aq3CMWRV c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=G3gG6ho9WtcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uTM5gQLEAAAA:8 a=xPT6tdSuAAAA:8 a=VbdBpaqbNeYOeNDVaQMA:9 a=gtaOcv92oST3vib0:21 a=wZBQY-2j8Y65M_5g:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=JbOb8jl0-zDOI8HELKoA:9 a=eB6ed6oelfFSIF0D:21 a=iV9moG4F5fHItXsR:21 a=o4LvZs65HfMrZQxm:21 a=_W_S_7VecoQA:10 a=DIOMxfJ4J7wpsvcsKDIA:9 a=ONNS8QRKHyMA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=X0a8wEfk66sNBbu13Lvv:22 a=80PJfYVSYmV_jLpvUEnt:22 a=6kGIvZw6iX1k4Y-7sg4_:22
X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity
X-Virus-Status: Clean
X-MailSecurity-Status: 0
X-Scanned-By: WeCloud MailSecurity
X-MailSecurity-Score: 0
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Jul 2017 09:44:48 -0000

Hello Eric,

Thanks for your good comments!

Please, see my answers inline.


On 2017-07-08 16:45, Eric Rescorla wrote:
> 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?

Yes, 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?

Yes, 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.

This alternative is surely simpler and good to consider, and I agree
with your related considerations.

I would add that the TA has still to provide also N to the client, for
inclusion in the extension. N is in fact required by the server for
recomputing the HMAC and perform anti-replay checks on the ClientHello
as suggested in the draft.

The model currently described in the draft considers additional key
material and related derivation, thinking also about session resumption
(see also the related comment below). To this end, the design above
would then additionally consider (consistently with the draft's

- The TA deriving K_S from K_M and N; and K_MAC from K_S
- The TA computing the HMAC using K_MAC
- The TA sending also K_S to the client

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

True, although in case of resumption it is not anymore a full assertion
of client's validity, but it's rather about protecting from replays of
valid resumption requests.

Also, it considers Section of RFC 5246, i.e. the same extensions
SHOULD be included in case of request for session resumption.

This also led to the design in the draft (i.e., the HMAC computed by the
client and the provisioning of a session key K_S), so that the client
does not require to contact the TA again in case of intended session

Consistently with the alternative design proposed above, in case of
resumption request, the client can compute the HMAC itself, again only
over the extension-related content, like considered by the TA in the
main case for new session establishment. This would also avoid the
implementation issues you mentioned below [0] for the current approach
in (D)TLS 1.3.

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

I understand your concerns as to implementation complications. We can
then build on the alternative design above to avoid them by construction.

> On Sat, Jul 8, 2017 at 4:10 AM, Marco Tiloca <
> <>> 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: <>
>     To: 	Marco Tiloca <>;
>     <>, Ludwig Seitz <>;
>     <>, Maarten Hoeve <>;
>     <>
>     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:  
>     <>
>     Status:
>     <>
>     Htmlized:
>     <>
>     Htmlized:
>     <>
>     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 <>;.
>     The IETF Secretariat
>     _______________________________________________
>     TLS mailing list
> <>
>     <>

Marco Tiloca, PhD
Research Institutes of Sweden
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.