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
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:
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?
#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".
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
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.
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 "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?
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.
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.
https://github.com/tlswg/dtls-conn-id/pull/29
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
