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

[Benjamin Kaduk <[e-mail]>]

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