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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Sep 2020 16:02:28 -0700

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:
https://github.com/tlswg/dtls-conn-id/pull/75
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?

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.

   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.

   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 "4.1.2.5 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?

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.

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?

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

---

From: Achim Kraus <[email-masked]>
Date: Fri, 4 Sep 2020 08:58:51 +0200

Hi Ben,

see my comments inline.

Generally you may read the closed issues or PRs with the proper keywords
in https://github.com/tlswg/dtls-conn-id.

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

> 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, 4.1.2.1 and explain
not to use the option "If a DTLS implementation chooses to generate an
alert".

> was chosen, that will be helpful for subsequent discussions/IESG

There have benn some discussion about that, see

https://github.com/tlswg/dtls-conn-id/issues/22
https://github.com/tlswg/dtls-conn-id/issues/28

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

https://github.com/tlswg/dtls-conn-id/issues/28#issuecomment-458032109

made mainly the decission.

> 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.

> the way of new 1.2 ciphersuites)...right?

The MAC calculation have also been discussed:
https://github.com/tlswg/dtls-conn-id/issues/25

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

> fields (that appear after these) so there seems to be some malleability.

That order was also discussed a lot.
https://github.com/tlswg/dtls-conn-id/pull/29
I would prefer, if this is not changed again without strong arguments!

> 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.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 Sep 2020 12:26:44 -0700

Hi Achim,

> So, please, only address and change things, which are really important.

Sure.  If there are particular PRs/issues or search queries that are
relevant, that can help me revisit the previous discussions.

> not to use the option "If a DTLS implementation chooses to generate an

Seems reasonable to me, thanks.

> made mainly the decission.

Excellent; thank you for these references.
 
> If I did't get it, it may be easier to discus this as issue in the

I think you got it; I am just failing to remember where the "MUST anyway
use new handshakes" requirement comes in from.  And I guess that also
raises the question of what the expected behavior is when a server expects
CID-ful traffic on a given 5-tuple and receives an (unencrypted)
ClientHello on that 5-tuple.

> I would prefer, if this is not changed again without strong arguments!

Thanks for the pointer!
I am not sure that the specific question about injectivity was raised
there, though.  (The topic of whether "seq_num" includes epoch was raised
but I did not see a clear resolution on my first reading, just
https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)

Specifically, the question of "injectivity" is referring to a scenario
where I can use different actual values for (cid, cid_length,
length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed

cid + cid_length + length_of_DTLSInnerPlaintext + ...

(Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
field...)

Attempting to construct a trivial example on the fly, (hex)

01 01 02 02 01 <513 bytes of plaintext content>

could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
DTLSInnerPlaintext.content = <513 bytes>.  The possibility of such a
collision weakens the cryptographic protection and should be avoided.

> valid, if a larger message is to be sent back at all.

Okay.  I was mostly asking if there was a way to condense the text and
avoid covering the same topic twice, but it is not of critical importance.

Thanks,

Ben

---

From: Achim Kraus <[email-masked]>
Date: Wed, 16 Sep 2020 08:31:19 +0200

Hi Ben,

> ClientHello on that 5-tuple.

"when a server expects CID-ful traffic on a given 5-tuple"

I'm not sure, why that should happen. If CID is used, the server should
not expect a given 5-tuple (at least not longer than a few seconds).
If a new CLIENT_HELLO arrives, it's first challenge it with a
HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
of a previous CID message" is hit, then just mark/remove the 5-tuple of
that CID association. That mainly means, you will not be able to reach
the CID peer with that 5-tuple. That's anyway extremely common to lose
the ip-route to such CID peers, otherwise CID would not be required.

Just if you're interested:
I have already implemented that CID/5-tuple management in the open
source project Eclipse/Californium. (That project also contains a very
simple test-NAT, where you may simulate some address changes. But that
requires some more docu :-) ).
You may check, if that works as you would expect. Any feedback will be
very welcome. If you want ot use it with other implementations (e.g.
mbedTLS), ensure that the hello extension uses the right assigned IANA
value 53.

> collision weakens the cryptographic protection and should be avoided.

If that is going to be changed, the early adopters run into trouble with
their deployments!

The cid length is not on the wire, so on the wire is (cid 01 01)

 > 01 01 02 01 <513 bytes of plaintext content>

Therefore I don't understand, WHO will inject something, which is not on
the wire. For me that would only be the peer's implementation, which
extracts it's "own" CID wrong, or a "spoofed CID" (maybe that's the time
to read my proposal about a CID Authentication Code, issue #74.). But
with the wrong CID, the wrong keys would be selected and the MAC will
fail anyway. So, I can't see that collision.

best regards
Achim

---

From: Achim Kraus <[email-masked]>
Date: Fri, 18 Sep 2020 09:59:55 +0200

Hi Ben,

> the ip-route to such CID peers, otherwise CID would not be required.

Let me add:

- If the scenario uses "dynamic 5-tuples, with CID or without" and
"static 5-tuples without CID",
- then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
pool) and CID (described in
https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
communication to such a static-5-tuple without CID.

Even then, that "static-5-tuple" peers must be anyway aware, that
sometimes new handshakes are required. So that scenario may also depend
more on the volume of such attacks, than just on the pure possibility.
In my experience, such "static-5-tuples" are rare and I would guess,
they will benefit from different handling also for other reasons.
Therefore I would just spend them an separate endpoint to separate their
traffic.

best regards
Achim