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

Marco Tiloca <marco.tiloca@ri.se> Mon, 10 July 2017 18:19 UTC

Return-Path: <marco.tiloca@ri.se>
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 7D63D12EC29 for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 11:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Level:
X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oSo16d9aBmHM for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 11:19:36 -0700 (PDT)
Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49E8129B34 for <tls@ietf.org>; Mon, 10 Jul 2017 11:19:35 -0700 (PDT)
Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 0B691222137 for <tls@ietf.org>; Mon, 10 Jul 2017 18:19:31 +0000 (UTC)
Received: from [193.10.66.141] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 10 Jul 2017 20:19:33 +0200
Message-ID: <5963C530.8050006@ri.se>
Date: Mon, 10 Jul 2017 20:19:28 +0200
From: Marco Tiloca <marco.tiloca@ri.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: <tls@ietf.org>
References: <149866084527.7677.16172483068993302160.idtracker@ietfa.amsl.com> <ff1ba8ba-af2c-e079-6c07-4d97f4d80737@ri.se> <CABcZeBM72_axpp9dUkud9GZ5Nyo_XvWMDsQtZbqVCyfmGSdbOQ@mail.gmail.com> <0ae67cbc-e96c-0a22-b97d-f9c3fdea8eda@ri.se> <CABcZeBMFwYqH2xZLGFhb+yKggXi48cH60WXDcC-bLWFSPj0Mxw@mail.gmail.com>
In-Reply-To: <CABcZeBMFwYqH2xZLGFhb+yKggXi48cH60WXDcC-bLWFSPj0Mxw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v0xvWCOLBJM5CjthKVJfWEL4xawsaFx6t"
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.2 cv=Nc2W7yL4 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=uxq6SuWmm3nDubggvMEA:9 a=RSeV_S3H1Wjpn9iR:21 a=J40vvy4IRSSs2e0y:21 a=pILNOxqGKmIA:10 a=pGLkceISAAAA:8 a=0l6pUpVs_o8m5caASMUA:9 a=vs8Zy0KiOzwXt3uz:21 a=mFkR6ZQEfWJRebT5:21 a=vyadcpN6l_XeroTa:21 a=_W_S_7VecoQA:10 a=in1WbxyIa6XI09KtdZ0A: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: <https://mailarchive.ietf.org/arch/msg/tls/wMbpI4pOyMdFZCkNeR9-YxhXilE>
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: Mon, 10 Jul 2017 18:19:39 -0000

On 2017-07-09 15:33, Eric Rescorla wrote:
>
>
> On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <marco.tiloca@ri.se
> <mailto:marco.tiloca@ri.se>> wrote:
>
>     Hello Eric,
>
>     Thanks for your good comments!
>
>     Please, see my answers inline.
>
>     Best,
>     /Marco
>
>     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.
>
>
> Well, sort of. It needs to supply the client some opaque token. The only
> semantics of this token are between the TA and the server. 
>

I agree.

>
>
>     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 description):
>
>     - 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.
>
>
> Sure, but you already have to keep a per-client database of resumption
> requests
> (because the resumption counter is independent) and you might as well
> key this
> by the ticket and then just record clienthellos as in the guidance for
> TLS 1.3
> 0-RTT anti-replay.
>

Ok, we can rather refer to the 0-RTT anti-replay guidance and then have
the main design simpler.

>
>
>     Also, it considers Section 7.4.1.4 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 resumption.
>
>
> It seems like if this is really important, the TA could just give the
> client some small
> number of tokens on initial contact.

Sounds good to me.

Best,
/Marco

>
> -Ekr
>
>  
>
>     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 <marco.tiloca@ri.se
>>     <mailto: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
>>         <mailto:internet-drafts@ietf.org>
>>         To: 	Marco Tiloca <marco.tiloca@ri.se>;
>>         <mailto:marco.tiloca@ri.se>, Ludwig Seitz
>>         <ludwig.seitz@ri.se>; <mailto:ludwig.seitz@ri.se>, Maarten
>>         Hoeve <maarten.hoeve@encs.eu>; <mailto: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 <https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt>
>>         Status:         https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/ <https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/>
>>         Htmlized:       https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-00 <https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-00>
>>         Htmlized:       https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00 <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 <http://tools.ietf.org>;.
>>
>>         The IETF Secretariat
>>
>>
>>         _______________________________________________
>>         TLS mailing list
>>         TLS@ietf.org <mailto:TLS@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/tls
>>         <https://www.ietf.org/mailman/listinfo/tls>
>>
>>
>
>     -- 
>     Marco Tiloca, PhD
>     Research Institutes of Sweden
>     RISE ICT/SICS
>     Isafjordsgatan 22 / Kistagången 16
>     SE-164 40 Kista (Sweden)
>     Phone: +46 (0)70 60 46 501
>     https://www.sics.se
>     https://www.sics.se/~marco/ <https://www.sics.se/%7Emarco/>
>
>     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.
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.se
https://www.sics.se/~marco/

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.