Hello Ben,
thanks for your answer and actions.
best regards
Achim
Am 27.07.20 um 21:03 schrieb Benjamin Kaduk:
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
