Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

[Achim Kraus <[e-mail]>]

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
>> [e-mail]
>> 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=