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

[Eric Rescorla <[e-mail]>]

I would like to make several points here:

- In terms of operational practice, in order for a server to
function correctly, the CID must either be fixed-length for all
clients that might need to be demuxed *or*
self-describing. Otherwise, the server will not be able to determine
the correct CID. I believe this is clear in the specification:

   Because each party sends the value in the "connection_id" extension
   it wants to receive as a CID in encrypted records, it is possible for
   an endpoint to use a globally constant length for such connection
   identifiers.  This can in turn ease parsing and connection lookup,
   for example by having the length in question be a compile-time
   constant.  Implementations, which want to use variable-length CIDs,
   are responsible for constructing the CID in such a way that its
   length can be determined on reception.  Such implementations must
   still be able to send CIDs of different length to other parties.
   Note that there is no CID length information included in the record
   itself.

This is an important space optimization and in fact was one of the
key points in getting us to variable CIDs in QUIC, so I would not
want to take a regression here.

- I agree with Ben that the current construction has some awkward
properties and that prefixing the length field would remedy that. It's
been quite some time since we had this discussion but as I recall the
rationale was to protect the bits on the wire as-is rather than some
reconstructed version of them (see a number of long discussions on
this topic), so just prefixing the CID length is also not ideal.

- To the best of my knowledge, the ability to just disclose the
encryption key but not the MAC key has never been part of the
official interface of TLS -- and of course it doesn't really
work with many AEADs. So, anyone who is doing that is off the
fairway and I don't think has any security guarantees (TLS aside,
many application protocols have surprising security properties
in this situation) With that said, we shouldn't break such uses
unnecessarily, and it seems like there might be other negative
side effects of the current construction.


So on balance, I think we should try to fix this. I'm slightly less
enthusiastic about just swapping the length field, because I'd
prefer to MAC the literal bytes (though perhaps we'll just have
to live with that). However, it might be worth bikeshedding that
some. Here's one potential alternative, though I haven't studied

struct {
  uint8 marker = tls12_cid;
  uint8 cid_len;
  uint64 seq_num;
  uint8 cid = tls12_cid;               \
  uint16 DTLSCiphertext.version +      |  appears on wire   | non-CID MAC
input
  opaque cid[cid_len];                 /                    |
  uint16 length_of_DTLSInnerPlaintext;                      /
}

This is a little goofy but it has (I think) the properties that (1) the
bytes appear
in the MAC in the order they appear on the wire (2) fixed-length metadata
appears in
the front (the seq_num already does) (3) the duplicated tls12_cid in the
front avoids confusion with MAC input for other records.

-Ekr








On Wed, Oct 14, 2020 at 11:12 PM Achim Kraus <[e-mail]> wrote:

> Hi Ben,
>
> > The attack does not require that both are valid for the same peer at the
> > same time -- the attack can still occur when the party producing the MAC
> is
> > induced to use the "wrong" (invalid CID) interpretation of the byte
> stream
> > but then the version with valid CID is presented to the party verifying
> the
> > MAC.
>
> Though I consider the CID mainly as lookup-key for the security context,
> including the MAC_write_key for Block Ciphers or the write_key /
> write_IV for AEAD Ciphers provides in almost all casses the protection,
> not the cid in the MAC. The only exclusion would be, if two different
> cids point to the same security context. With a injective cid encoding,
> that is mitigated.
>
> As far as I understand your description:
>
> 1. The (server) peer 1 used cid "abcd" for it's encryption context.
>
> 2. An attacker modifies that cid "abcd" into a different cid (any
> assumptions about that? Should it be "abcd12"? Or "ef3456"? Or no
> special consideration?)
>
> 3. Then the other peer 2 uses the modified cid to place it into the
> FINISH record and to calculate the MAC for that. The used security
> context on peer 2 is NOT defined by that modified CID, it's defined by
> peer 1's 5-tupel (according draft-ietf-tls-dtls-connection-id-07).
>
> 4. Now peer 1 will use the modified cid to
> 4.a. lookup the security context. What is assumed as result here?
> 4.b. calculated the MAC using the security context and modified cid
>
> In my opinion, the MAC verfication generally fails, if at least one
> input is different. So either a different security context or a
> different cid will fail the MAC verification.
>
> Though you say, that not both cids need to be valid for peer 1, the
> consequence for me is, that peer 1 knows only the unmodified cid, but
> not the modified cid. With that, peer 1 doesn't even have a security
> context to calculate the MAC with.
>
> It's totally mystic to me, what you assume as attack.
>
> I guess, you adapt now your example. If so, would it be possible, that
> you try to follow the above steps and show, where you deviate?
>
> > If the internal structure (including length encoding) of the CID is
> > opaque to the party producing the MAC, that party cannot validate the
> data
> > used as input to the MAC.
> >
> > (Sorry for duplicating this previous paragraph here and on the github
> > issue.)
> >
>
>  From the github issue:
>
>  > In short, you asked me to show how having a cid-length (in a different
>  > position than currently) will prevent an attack: the attack in
>  > question occurs when the client is generating a (its first) MAC, not
>  > at the time when the MAC is validated.
>
> I still fail to follow your description, even with that amend.
> Would it be possible, to get more information about an attack applied on
> the generation of a MAC (above in step 3)? Or does the effect occur in
> an other step (maybe 4)? Which effect should be considered?
>
> Maybe, someone else has also an opinion about that attack or the
> description.
>
> best regards
> Achim Kraus
>