On 2017-07-09 15:33, Eric Rescorla wrote: > > > On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <marco.til...@ri.se > <mailto:marco.til...@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.til...@ri.se >> <mailto:marco.til...@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-dra...@ietf.org >> <mailto:internet-dra...@ietf.org> >> To: Marco Tiloca <marco.til...@ri.se> >> <mailto:marco.til...@ri.se>, Ludwig Seitz >> <ludwig.se...@ri.se> <mailto:ludwig.se...@ri.se>, Maarten >> Hoeve <maarten.ho...@encs.eu> <mailto:maarten.ho...@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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
