Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc
8a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SvzuTSLXUepdgCRou2%2FSpKIEEseKkgeW2FtxK2USDmU%3D&reserved=0 The WG Last Call will end 3 October 2023 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Fdtls-rrc&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0debb4c78dbe430d7e1c08dbb88ad9d4%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3oMiSlJbKPepw82mGmzWcCzevuMJcjmOotSu4c6k92c%3D&reserved=0 Alternatively, you can also send your comments to...@ietf.org. Thanks, Chris, Joe, & Sean ___ TLS mailing list TLS@ietf.org https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0debb4c78dbe430d7e1c08dbb88ad9d4%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OIpfBDR8I10rXFa6xzI3X%2FhqfTw10S1EDQGs%2BzuCJeY%3D&reserved=0 -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se OpenPGP_0xEE2664B40E58DA43.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc
Hi Thomas, On 2023-10-09 11:42, Thomas Fossati wrote: Hi Marco, We think we have addressed all your comments (but one, see below). Could you please check that the PR at [1] is good to go? ==>MT Thank you, the PR looks good me! (please see below about the two other points) <== [1]https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Fdtls-rrc%2Fpull%2F63%2Ffiles&data=05%7C01%7Cmarco.tiloca%40ri.se%7C52b4e41e5459444c222508dbc8ac2441%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638324413891462331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8WOJtf7yh71vA08CvogTi0Qrlqu8W%2FcTnAfoa33RE%2Bw%3D&reserved=0 The one comment we wanted to have a bit more discussion before deciding how to proceed is this: On Tue, 3 Oct 2023 at 15:50, Marco Tiloca wrote: [Section 7.4] * I think that another requirement should be that the initiator MUST NOT act on more than one valid path_response or path_drop message for each path_challenge message that it has sent. §7.4 currently says: "The responder MUST send exactly one path_response or path_drop message for each received path_challenge." So it's not clear how a situation with multiple occurrences of path_drop/path_challenge could come off, if the responder obeys the specified MUST? Could you clarify your concern a bit more? ==>MT Right, I was thinking of spelling out how the initiator should behave if the responder does not comply with the specification. If that can be excluded altogether or a safe behavior at the responder is obvious/implied, then the current text is just fine. <== [Section 10] * You will need to add a new subsection that provides expert review instructions, for the Designated Experts assigned to the new subregistry defined in Section 10.3. Thanks: this made us realise that expert review was a bit too lightweight, therefore we moved to STD required. ==>MT That makes sense. Best, /Marco <== cheers, thanks! -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se OpenPGP_0xEE2664B40E58DA43.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-02.txt
Hi all, We have recently submitted an updated version of the draft based on comments at IETF100. Also, a proof-of-concept implementation for DTLS 1.2 in Californium/Scandium is available at [1]. Best, /Marco [1] https://bitbucket.org/sicssec/dos_dtls Forwarded Message Subject:New Version Notification for draft-tiloca-tls-dos-handshake-02.txt Date: Mon, 5 Mar 2018 10:36:49 -0800 From: internet-dra...@ietf.org To: Maarten Hoeve , Ludwig Seitz , Olaf Bergmann , Marco Tiloca A new version of I-D, draft-tiloca-tls-dos-handshake-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-tls-dos-handshake Revision: 02 Title: Extension for protecting (D)TLS handshakes against Denial of Service Document date: 2018-03-05 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-02.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/ Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-tiloca-tls-dos-handshake-02 Abstract: This document describes an extension for TLS and DTLS to protect the server from Denial of Service attacks against the handshake protocol, carried out by an on-path adversary. The extension includes a nonce and a Message Authentication Code (MAC) over that nonce, encoded as a Handshake Token that a Trust Anchor entity computes and provides to the client. The server registered at the Trust Anchor verifies 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 signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
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 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: 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 signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
osed 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 <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 > <mailto:marco.til...@ri.se>, Ludwig Seitz > <mailto:ludwig.se...@ri.se>, Maarten Hoeve > <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/ 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
Re: [TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-00.txt
On 2017-07-09 15:33, Eric Rescorla wrote: > > > On Sun, Jul 9, 2017 at 2:44 AM, Marco Tiloca <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).
[TLS] Fwd: New Version Notification for draft-tiloca-tls-dos-handshake-01.txt
Hi all, We have just submitted an updated version of draft-tiloca-tls-dos-handshake This revised version especially considers the comments from Eric Rescorla and following discussion [1]. Thanks again, Eric! Comments are very welcome. Best, /Marco [1] https://www.ietf.org/mail-archive/web/tls/current/msg23824.html Forwarded Message Subject:New Version Notification for draft-tiloca-tls-dos-handshake-01.txt Date: Sat, 28 Oct 2017 04:54:51 -0700 From: internet-dra...@ietf.org To: Maarten Hoeve , Ludwig Seitz , Olaf Bergmann , Marco Tiloca A new version of I-D, draft-tiloca-tls-dos-handshake-01.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-tls-dos-handshake Revision: 01 Title: Extension for protecting (D)TLS handshakes against Denial of Service Document date: 2017-10-28 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-tiloca-tls-dos-handshake-01.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-tls-dos-handshake/ Htmlized: https://tools.ietf.org/html/draft-tiloca-tls-dos-handshake-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-tls-dos-handshake-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-tiloca-tls-dos-handshake-01 Abstract: This document describes an extension for TLS and DTLS to protect the server from Denial of Service attacks against the handshake protocol, carried out by an on-path adversary. The extension includes a nonce and a Message Authentication Code (MAC) over that nonce, encoded as a Handshake Token that a Trust Anchor entity computes and provides to the client. The server registered at the Trust Anchor verifies 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 signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS
Hi, I support the adoption of this document. Best, /Marco On 2024-10-25 04:46, Sean Turner wrote: At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] and [3]. The I-D has been revised a few times since IETF 119 to incorporate list feedback. This message is to judge consensus on whether there is support to adopt this I-D. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close on November 7, 2024. Thanks, Deirdre, Joe, and Sean [0]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ [1]https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00 [2]https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/ [3]https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/ ___ TLS mailing list --tls@ietf.org To unsubscribe send an email totls-le...@ietf.org -- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
