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

From: Marco Tiloca <[email-masked]>
Date: Sat, 8 Jul 2017 13:10:56 +0200

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: 	[email-masked]
To: 	Marco Tiloca <[email-masked]>, Ludwig Seitz
<[email-masked]>, Maarten Hoeve <[email-masked]>

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 8 Jul 2017 07:45:44 -0700

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 <[email-masked]> wrote:

> against the handshake protocol, allowing servers to promptly abort invalid
> session set ups.
>
> Subject: New Version Notification for draft-tiloca-tls-dos-
> handshake-00.txt
> To: Marco Tiloca <[email-masked]> <[email-masked]>, Ludwig Seitz
> <[email-masked]> <[email-masked]>, Maarten Hoeve
> <[email-masked]> <[email-masked]>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Marco Tiloca <[email-masked]>
Date: Sun, 9 Jul 2017 11:44:31 +0200

Hello Eric,

Thanks for your good comments!

Please, see my answers inline.

Best,
/Marco

> own but not block) and maximally a full active attacker able to block

Yes, correct.

> handshake or a partial handshake and then stopping) Is that correct?

Yes, correct.

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

> so the server knows that it has a valid client without any new

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

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.

> use is actually quite annoying to implement in many TLS stacks (it

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 <[email-masked]
> <mailto:[email-masked]>> 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.
>
>     From: 	[email-masked] <mailto:[email-masked]>
>     To: 	Marco Tiloca <[email-masked]>
>     <mailto:[email-masked]>, Ludwig Seitz <[email-masked]>
>     <mailto:[email-masked]>, Maarten Hoeve <[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>     <https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-00.txt>
>     <https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/>
>     <https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-00>
>     <https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-00>
>
>
>     Abstract:
>     until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>     [email-masked] <mailto:[email-masked]>
>     <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.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 06:33:03 -0700

On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <[email-masked]> wrote:

> This alternative is surely simpler and good to consider, and I agree with
> your related considerations.
>
> 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.

> (see also the related comment below). To this end, the design above would
> then additionally consider (consistently with the draft's description):
>
> 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.

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

-Ekr

> 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
>
> I understand your concerns as to implementation complications. We can then
> build on the alternative design above to avoid them by construction.
>
>
>
>
>
>> Subject: New Version Notification for draft-tiloca-tls-dos-handshake
>> -00.txt
> Phone: +46 (0)70 60 46 501https://www.sics.sehttps://www.sics.se/~marco/
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 9 Jul 2017 11:34:22 -0500

On 07/09/2017 08:33 AM, Eric Rescorla wrote:
>
>
>
>     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.
>
>

I wonder if the desired properties could be obtained by having the TA be
a Kerberos KDC that only issues [Kerberos tickets targetting the TLS
server's Kerberos principal] to [Kerberos clients that are authorized to
speak TLS to the TLS server].  Then the TLS extension could just hold a
Kerberos authenticator that binds to the client random and the client
can reuse the kerberos ticket until it expires.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 13:11:45 -0700

On Sun, Jul 9, 2017 at 9:34 AM, Benjamin Kaduk <[email-masked]> wrote:

> I wonder if the desired properties could be obtained by having the TA be a
> Kerberos KDC that only issues [Kerberos tickets targetting the TLS server's
> Kerberos principal] to [Kerberos clients that are authorized to speak TLS
> to the TLS server].  Then the TLS extension could just hold a Kerberos
> authenticator that binds to the client random and the client can reuse the
> kerberos ticket until it expires.
>

It's actually not clear to me why this needs to be bound to the CH at all,
for the reasons I indicated in my review....

-Ekr

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 10 Jul 2017 20:19:28 +0200

On 2017-07-09 15:33, Eric Rescorla wrote:
>
>
> On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <[email-masked]
>     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.
>
>

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

> 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
>>
>     I understand your concerns as to implementation complications. We
>     can then build on the alternative design above to avoid them by
>     construction.
>
>
>>
>>
>>
>>         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.
>>
>>         <mailto:[email-masked]>
>>         <mailto:[email-masked]>, Ludwig Seitz
>>         <[email-masked]> <mailto:[email-masked]>, Maarten
>>         Hoeve <[email-masked]> <mailto:[email-masked]>
>>
>>
>>
>>         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:
>     https://www.sics.se/~marco/ <https://www.sics.se/%7Emarco/>
>