Hi Achim, My apologies for the URL mangling by my corporate spam filter.
On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote: > Dear list, > > are there any news about the draft-ietf-tls-dtls-connection-id and the > IANA registration of the connection_id? > > According > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Ddtls-2Dconnection-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=kAlzAEjg0E4P_Cw7G3afL6NHvcFJpJLl72gJVzBvrJ8&e= > the > draft expired on April 23, 2020 and according > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_tls-2Dextensiontype-2Dvalues_tls-2Dextensiontype-2Dvalues.xhtml&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=poEk1-YL4mzxACY3b-Ldn9NtcPOSd-ZvDKXJcbQ3Ep0&e= > the assigned value expired on 2020-07-02. There seems to have been some oversight, as this assignment was not included in a report of "early allocations assigning in the next 60 days" that was produced on 2020-06-15. I have asked IANA to investigate (and indicated that this extension's allocation should be renewed). The draft itself is essentially done from the WG's point of view, with just the two PRs you note left to merge. It has been waiting for quite some time for me to perform an AD evaluation and start an IETF Last Call on it; I expect to do so in the next couple weeks. Thanks, Ben > I still very interested in this extension, it makes coap over dtls 1.2 a > very powerful technology for the cloud and NB IoT. > > Currently two pending threats are discussed, see the PRs in > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls-2Dconn-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=6LWHz8pLHziy_jeL2sXwJnw4Y7gz84VzFUe0ur4RsDg&e= > . > > One of both is in my opinion a general one using UDP, several > countermeasures are discussed, including RRC. Let me add, that in my > opinion, it's also about to chose cid for the right use-case, and not > generally. That would mostly eliminated the DDoS threat, if the use-case > doesn't offer an amplification. > The other one requires in my opinion a remark about not using the option > of RFC 6347 to generate an alert on invalid MACs, if the cid is used. > Potentially, if of any interest at all, an additional remark about > AES-CBC, the CID length and "lucky 13" maybe added, though the cid > changes the 13. > > For me this looks much more, that the authors are too busy with other > work and not that this draft doesn't make sense anymore. Therefore I > would appreciate, if the temporary IANA registration for the > connection_id could be extended by an additional year. > > Best regards > Achim Kraus > > _______________________________________________ > TLS mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=FbOzAxOPoG1SVAsJCPteFfbyv3RYaOwBj5OuZTxcerk&e= _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
