Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

Achim Kraus <> Fri, 04 September 2020 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE6063A0EC1; Thu, 3 Sep 2020 23:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZA_cRXD8_lNn; Thu, 3 Sep 2020 23:59:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1735E3A0EE0; Thu, 3 Sep 2020 23:59:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1599202733; bh=+ildEKOJmrpD4FehT4Vu3cKAvykzaYdIpWNNUNBoHbs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=UAa4qEFMlpoIGIrmmZlF5DZ9u149XBkXP/FZReiPKuzrKl60uW3uPQr/JgNgJmLEX BtOT2Pgs3bbDpMVg4UvaniQx/3lJkN4jyIzVQCb7XXS/IOSK7gWvty/v2kiDGR0uKI 5Y4ttZjvXWA19JTY6ihPikx3stCx3mYD9d7LeJX4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1N7iCg-1kaPxG3cpO-014mIr; Fri, 04 Sep 2020 08:58:53 +0200
To: Benjamin Kaduk <>,
References: <>
From: Achim Kraus <>
Message-ID: <>
Date: Fri, 4 Sep 2020 08:58:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:5n8JqIJ1TpU3wLd03ynj3SxSmJZJaJdBbuE2PtXrHzK76uoRvI9 Xf9PFVEEl6/Xo9IZBmubCJuG8kg0+QUFO+nhft1N2mKVR8g5RK168uwoGlw5LFcp3uV7Z1d 7letxn5/MdZWeBM142K11B9DBNEXoXxurbV+9YwoRnx9rFVhMDQg6zbnEGyljcClgFBerEp 9VglMN1fnatXBUN6+YRXw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:nFBgI6rJZxU=:CJ9JmqZoCXPSDTMlIReSWb L1r+9Hn8kVOww9S5jnc7bOlGYnSc5iSfzY5FOvQcoND8wf8e3d4tLmqaJVDF4cS1bmPVgIWuT 2cJEJcg0sMAgCCtD83mic1OHI9cSj8jZ8UOITpbi5PfRpvl346FrKIUN5ioPwTrtuejFQDf8v WWAwI1LPYb52c7b1X/6xxJ2aIS7tA2xFxEOn1HyWqpeHCL27nrFT1TsqnnRFnrr3mVQK5Cgc+ kZlp/IvtOc2t4XWmhgF9pqi8y1IHI1EtHpXGHn7dlqEQu/f1LUJj3yV1erhuviomRGpS7tJwJ M+AfpKeRCke50wQgTryVH8l5wEQhFAXPGR9QG3SR/iL+k8dIUm48zggxNpT/QPhVJlWHHy7+/ qX7biClXXwz0pn88zPYg3l41u3ueT+iAbuXwesmAAneWKFgFiT+YCzN/NcWqEJpa/lQybnbAA TJwe0uoxfbutwZbDj8tnnk4Cdhx3M77/+iCkb4uphAghPf0sFhb6utEWK8XB5Oywcf+KAt/Po 0Tem0A88OhzPtDu4U0mExuvS598VUlqjiTWd9HeF4rDJEcY8PnF+xmLxuZKoNOZv2NlPP/0rt aS/e5AU75hALhXgRe472GMUg1i8L8gzh0y9M18IpQFvWEZu2uQXkZpiol7kmmC1rU4AKsWEyN 0o6wOcgnDCWuqdbU1SIaULg5UCqKbUuVA0gDnTWbCARNNUvy2CY1nZYGYzHSdqmVYq0lM4UFm 01Nr5e/9TBT5zZSaa7ue7/TROEXEBzGyNy5xDWHpFUchFaip/W0wJLgnfmY+1wjBegqXoV8Ks 4d4jC8FYSnqMM30hL0Z1WcMrEUaH7/ZTG+7ayT4y6g97xBngGMiMRdvrRq961vHjQRiTvaTwJ xdI4bafL6xX0BFi+uj/JJQgGI9vQvGcONKYGFmALKDul9ZOKtM1ASQusFlzBjzTgNG6VN3UM3 tnHNigYpZAOBWEZImVk8Wzu+LrlS78vU9+QCynXyaz+KvzMOGeMpQVy+tswXu16+fP+sTLrjB 2UYsRe3hsrpThfhowZOH186HiATr2mfRNBzSVynK/7jPsxPCGqPNh7510y67VakkLqBrec757 zPqqNOvK175ohCLWAgUjJpaF9GDYSXHEHQacsmYkvM8PNZ3+g9nXLMJearq0vP3HR/5iLy1mY qC7uAFI4kDMlKDWyq3CEJlDta1NdIckvBKJZYT5kg/CbjZm38sOz5EF+s+wGjwdBlmu6DI+Ut EDq2XirA+aM/RXbEHNAJGCP4qDb/XM42/1h7fFg==
Archived-At: <>
Subject: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Sep 2020 06:59:04 -0000

Hi Ben,

see my comments inline.

Generally you may read the closed issues or PRs with the proper keywords

FMPOV most stuff has been discussed over and over. For me, in many cases
there are not that strong arguments for the choosen option over the
others. But these discussion have been at that time. For now, I'm not
sure, if changing details will bring that benefit.
So, please, only address and change things, which are really important.

best regards
Achim Kraus

Am 04.09.20 um 01:02 schrieb Benjamin Kaduk:
> Hi all,
> Sorry for the slow processing time -- my queue is still longer than I am
> happy with.
> There's a few apparent inconsistencies that we'll need to tighten up,
> but I don't think there's anything particularly problematic.
> I made a PR for most of the editorial stuff:
> And having pulled the github repo up, it looks like there's a few open
> issues and PRs still, there -- what's the status of those?

#73 FMPOV it's worth to address the issue Thomas found.
I would prefer a wording, which point to RFC6347, and explain
not to use the option "If a DTLS implementation chooses to generate an

> I wonder whether, as a rhetorical device, it would be helpful to give
> the new record payload structure a new name (DTLSCIDCiphertext?) to
> distinguish it from the RFC 6347 DTLSCiphertext.  Then we could write
> things like "in order to distinguish between DTLSCiphertext and
> DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used
> once encryption is enabled", etc.
> Section 3
>     For sending, if a zero-length CID has been negotiated then the RFC
>     6347-defined record format and content type MUST be used (see
>     Section 4.1 of [RFC6347]) else the new record layer format with the
>     tls12_cid content type defined in Figure 3 MUST be used.
> I'm glad that we take a clear stance on what content-type to use for
> zero-length CIDs, though I forget what the reasoning was to fall this
> way vs requiring that the tls12_cid ContentType is used whenever CIDs
> are negotiated.  I see how this approach makes some processing easier
> (there is always a CID present when the ContentType is used), but it
> does have the drawback of requiring use of actual CIDs in order to
> get encrypted content-type.  If you could remind me why this approach
> was chosen, that will be helpful for subsequent discussions/IESG
> review/etc.

There have benn some discussion about that, see

So, I'm also glad that in the end of the discussion there was a
consense. I'm not sure, but I think that comment

made mainly the decission.

>     For receiving, if the tls12_cid content type is set, then the CID is
>     used to look up the connection and the security association.  If the
>     tls12_cid content type is not set, then the connection and security
>     association is looked up by the 5-tuple and a check MUST be made to
>     determine whether the expected CID value is indeed zero length.  If
>     the check fails, then the datagram MUST be dropped.
> I guess there's maybe a risk that an attacker sets up a CID-ful
> connection on a given 5-tuple and then disappears, thereby denying
> the target of the attack the ability to use a CID-less DTLS association
> on that 5-tuple.  But it would be hard to swamp all the ports, so it's
> only likely to be an issue when fixed ports are used on both sides ...
> which is known to happen sometimes.  Perhaps we should document this in
> the security considerations.

I'm not sure, if I understand that well.
Do you assume, that in a network envirnoment, where the 5-tuple is not
stable, someone may use a CID and so block the (instable) 5-tuple? Yes,
but in that network your peer MUST anyway use new handshakes and so the
CID usage will be overwriten by the new handshake.
If the 5-tuples are stable, then the attack must spoof the 5-tuple, but
the hello verify mechanism will block that.

If I did't get it, it may be easier to discus this as issue in the
github repo.

>     When receiving a datagram with the tls12_cid content type, the new
>     MAC computation defined in Section 5 MUST be used.  When receiving a
>     datagram with the RFC 6347-defined record format the MAC calculation
>     defined in Section 4.1.2 of [RFC6347] MUST be used.
> I guess that "4.1.2" includes " New Cipher Suites", so this is
> not inadvertently closing off extensibility (not that we expect much in
> the way of new 1.2 ciphersuites)...right?

The MAC calculation have also been discussed:

If the CID is to be included into the MAC, then in my opinion, that must
be defined for each supported cipher suite.

> Section 4
>     When CIDs are being used, the content to be sent is first wrapped
>     along with its content type and optional padding into a
>     DTLSInnerPlaintext structure.  This newly introduced structure is
> Is it worth mentioning that this is anlogous to the TLS 1.3
> TLSInnerPlaintext?  (I do see that we have such a reference a couple
> paragraphs later in the context of the record padding functionality.)
>     enc_content  The encrypted form of the serialized DTLSInnerPlaintext
>        structure.
> In Section 5.2 we refer to the DTLSCiphertext.enc_content as
> the intermediate encrypted stuff used as input to the MAC for
> Encrypt-then-MAC processing, which maps up well to this description, but
> is in conflict with DTLSCiphertext being the bits that actually go on
> the wire.  So we seem to be internally inconsistent about whether
> enc_content includes the EtM MAC.  Most likely it will be easiest to
> address this in Section 5.2, though.
> Section 5.x
>         MAC(MAC_write_key, seq_num +
> The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
> DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
> and the DTLS (explicit) sequence number.  I do not see this
> concatenation given the name "seq_num" anywhere, so I think we need to
> reformulate this expression.
>             cid +
>             cid_length +
> Does this construction preserve injectivity?  It seems easier to reason
> about when the length of an element is always before or always after the
> element itself, but we put the length first for some of the other
> fields (that appear after these) so there seems to be some malleability.

That order was also discussed a lot.
I would prefer, if this is not changed again without strong arguments!

> Section 6
>     -  There is a strategy for ensuring that the new peer address is able
>        to receive and process DTLS records.  No such test is defined in
>        this specification.
>     [...]
>     Application protocols that implement protection against these attacks
>     depend on being aware of changes in peer addresses so that they can
>     engage the necessary mechanisms.  When delivered such an event, an
>     application layer-specific address validation mechanism can be
>     triggered, for example one that is based on successful exchange of
>     minimal amount of ping-pong traffic with the peer.  Alternatively, an
>     DTLS-specific mechanism may be used, as described in
>     [I-D.tschofenig-tls-dtls-rrc].
> I feel like these are supposed to be talking about the same thing, but
> the first sentence of the latter paragraph leaves me confused.  Is the
> idea that "application protocols that implement the functionality for
> ensuring that the peer can receive and process DTLS records" are what
> depend on being aware of the changes of address?

That should be at least one option. Using CoAP on the top of DTLS 1.2
with CID may used CoAP-feature to ensure, that the changed address is
valid, if a larger message is to be sent back at all.

> Section 8
>     With multi-homing, a passive attacker is able to correlate the
>     communication interaction over the two paths and the sequence number
>     makes it possible to correlate packets across CID changes.  The lack
> DTLS 1.2 CIDs don't have CID changes (other than by rehandshaking, which
> resets the sequence number space); the last clause seems stale from DTLS
> 1.3?
> Section 9
> We may want to reference draft-gont-numeric-ids-sec-considerations as it
> relates to CID generation.
>     An on-path adversary can create reflection attacks against third
>     parties because a DTLS peer has no means to distinguish a genuine
>     address update event (for example, due to a NAT rebinding) from one
>     that is malicious.  This attack is of concern when there is a large
> This is why we have the "[t]here is a strategy for ensuring that the new
> peer address is able to receive and process DTLS records" requirement,
> right?  We should probably mention that (and that it's not perfect,
> since you have to send some records to the not-yet-verified peer address
> as part of the verification process).
>     asymmetry of request/response message sizes.
> Is this just when the request is small and the response large, or is the
> reverse scenario also of concern?
> Section 10
>     connection_id(TBD1) as described in the table below.  IANA is
>     requested to add an extra column to the TLS ExtensionType Values
>     registry to indicate whether an extension is only applicable to DTLS.
> Do we want a "DTLS-Only" column or a "DTLS/TLS" column that takes values
> "DTLS", "TLS", and "both"?
>     IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType
>     Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2.
> We need a value for the "description" column, and should probably
> explicitly say that it has DTLS-OK "Y".
> Section 11.1
> The way we refer to draft-tschofenig-tls-dtls-rrc does not actually seem
> to require it to be a normative reference.
> I'm sure we will catch some grief for normatively referring to both 5246
> and 8446, but there's not really a way around it.
> Thanks,
> Ben
> _______________________________________________
> TLS mailing list