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

[Marco Tiloca <[e-mail]>]

On 2017-07-09 15:33, Eric Rescorla wrote:
>
>
> On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>> 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: 	[e-mail]
>>         <mailto:[e-mail]>
>>         To: 	Marco Tiloca <[e-mail]>
>>         <mailto:[e-mail]>, Ludwig Seitz
>>         <[e-mail]> <mailto:[e-mail]>, Maarten
>>         Hoeve <[e-mail]> <mailto:[e-mail]>
>>
>>
>>
>>         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
>>         [e-mail] <mailto:[e-mail]>
>>         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: [phone]
>     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
> [e-mail]
> 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: [phone]
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.