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

[Benjamin Kaduk <[e-mail]>]

On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >
> > To be frank, I'm actually surprised that this is even seen as a matter for
> > discussion.
> 
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
> 
> https://github.com/tlswg/dtls-conn-id/issues/8

Well, we are not always happy about it (in fact, usually are unhappy), but
writing protocol specifications does have a reputation for taking a long
time due to repeated experiences.  It's also the case that the spec isn't
done until it's done, and that breaking changes to the spec are possible at
any time before it's done.

> There are many (proposed) changes since then. I already tried to point
> to that with my e-mail answer from 4. September
> 
>  >> 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!
> 
> For me, "cryptographic hygiene", which breaks the API, are not strong
> arguments. Sure, that's only my personal opinion. I'm not sure, if a new
> code-point helps, nor that a new one is emitted for changing a draft (I
> would not recommend to do so, draft is a draft).

A codepoint should have a specific well-defined behavior.  The current
allocation of extension type 53 is explicitly marked as TEMPORARY and
can+will age out if we get a new one for the new semantics; this is normal.

> So let me try to find a end:
> As developer, I see it's very important to come to a stable definition
> of the MAC. If now the order of the cid/cid-length is changing the MAC
> (again), and in half a year the next "cryptographic hygiene" campaign
> removes the cid-length (because it's not on the header and some
> (including me) don't see the benefit), then FMPOV this "process" just
> demonstrates more weakness, than I appreciate.
> 
> So:
> If there is a guideline for constructing MACs, is that guideline
> documented somewhere?
> If the guideline is changing over the time, are these changes documented?

Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:

- include in the MAC as much application/protocol context and protocol
  fields as you can without breaking operation of the procotol
- ensure that the mapping from (set of protocol fields and values derived
  from application context) to (bytes given as input to the MAC function) is
  an injective mapping

In some (many?) cases, there is not any additional contextual information
available, and the protocol header itself has a deterministic/fixed-length
encoding, so both points can be achieved by just using the protocol
header/payload as it appears on the wire as MAC input.  For better or for
worse, the current construction in the -07 diverges significantly from the
actual protocol header, so we have to do a bit of thinking to ensure that
we are compliant to the guidelines (that I just described, so I assume you
did not previously think about them in that formulation).


For what it's worth, I am in a similar position as you in that I don't see
a specific reason that including the CID length explicitly is *required*,
since the CID itself would need to be using a self-delineating encoding in
order for the packet to be parseable (if variable-length CIDs are used at
all; a fixed-length CID is trivially delineated).  I would be pretty okay
with not having the separate length field if our MAC inputs more closely
followed the record header (and, to be honest, I could accept not having it
at all even with the current order of (other) fields in the MAC input, in
the absence of specific reasoning why it's needed), though I prefer to keep
an explicit length if we stay with something resembling the current
formulation (that diverging from the record header as it appears on the
wire), just to make it easier to reason about.  I still, however, object to
the construction in the -07 that puts the CID length after the CID -- there
is no point in having the CID length if you need a self-delineating CID
anyway [1], and its current location gives an aveue of malleability to an
attacker.  Leaving this kind of local malleability of MAC input in place
seems irresponsible and is not in keeping with the quality expectations for
the output of the TLS working group.

(We should also check to make sure that we properly document the
requirements on CID generation and parsing schemes, as you noted
elsewhere.)

> And I would really welcome, also based on the experience with the long
> history of this discussion, if more can give their feedback about
> changing the MAC again. Please, this year, not next :-).

I believe that Joe's response supports my "don't leave areas of local
malleability in place" stance.  I guess maybe the discussion is migrating
to the github issue, though, so I will try to watch there as well.

Thanks,

Ben

[1] "need [...] anyway" here is perhaps most usefully thought of in the
sense of inverting the (injective) map from (protocol parameters and context)
to (input to the MAC function), since this needs to be possible for any
valid MAC input in order for the injective property to hold.