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

Achim Kraus <achimkraus@gmx.net> Wed, 16 September 2020 06:31 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0182E3A0D58; Tue, 15 Sep 2020 23:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUbu8UN3vF7A; Tue, 15 Sep 2020 23:31:29 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF443A0D55; Tue, 15 Sep 2020 23:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600237881; bh=o+Bgej0wbUT++xjdBeicYD2hWzxpWEUEBvBX+HxHSpI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=l9K4g70TG2Jqb9CcXd6FqVVl3DvXHQ+c7FzvDAf8YHeE+2SjSDXRMfVj1P5Akwvrd ijdoTTRpse1fY+ZCxLLzfV1MYEuFPKbkIEeC68G5iuXHL3/AK3bUojlj4aV61Nj8cY FYOPeJdjADdCmyJjSXmVIHEjP9d+cD11Ub3kPrTE=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.10.252.75]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbBu-1kbcaM44r0-00sehC; Wed, 16 Sep 2020 08:31:21 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, tls@ietf.org
References: <20200903230228.GQ16914@kduck.mit.edu> <0723ab09-7c47-400b-6e93-1b0ae34242fd@gmx.net> <20200915192644.GV89563@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
Date: Wed, 16 Sep 2020 08:31:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200915192644.GV89563@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:tAqDCDH+lleL0alPFvYIRqdAhGoEkz3k+8oeQHhdG/Is4lwJL6/ mGFenR7v3fcZ+NLciQbXicStQhZvtkxEkksLotmdufAU8RjXQaC2xh9V7v3fUxOwNSfaiir UIFiLrbIkxn/xBgO779/4FuGTDVBfDrL2ttMHHzWctFVVkSrqEghW0w2HD+3zKVg1sahCJL j/l6LWfLi3/wvuAEDh3wA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:oIeqOIVG+T0=:fDJCL9YtS8gUdCWIQ2Q7FJ CH2CgHUlh+x7ydA3wptXatce+UwV8E6TU0nZBwL70T5bbBFkeDEsQ50sgRFej7OTyyk+/yS4t xZSLC43gf8B/N8Xyww2OdFSEACi4SV6161D04aersbrhmr0CS9fTiZxSNqvAx2herGXaXSvL+ fTXX1flNHNXf7Feh/0TxZmnMR7EkaUBqcOSXoFrmWwKI8KwZD62B++V531nFkDHUbw6tOH3ik MKi1k7Hh3M27KRmvht41ixbH4hko0ODe1ZdI2ClaW/ylEudKQSfDv6MLVYNelf8nFIx5IIiPL UB32x6eV1yq0OsyIYph87qS7C1zuZNoifZC0DJvYCVE6HCpBbDZMKQooCKJwycaU53kmq9ddT q4wlyFNgjDg6ycCelMz9AfmXqua+lCqY7ZlItLPt+hIFrsS5r6YoQs6n0BacGF0WXO9Zfcb4w 8cajFlUzOzaEOBhtgq8dkKwXdPCxpYLKFLTgJe8pi/kQU8ypXcvnTrlgxdRlVenEZutAHVDZd S8ILbkUp5D+uolC2L0XkQst2kkXRvmTso5RO1/uTGkGXqvOxwi4vcDD5orpwd7fEmERWhII+0 3NwdmKSf+Q8m06eoyH8rTIrKB8awiJX2q9rO9jWIIe3fTwdKcnKcYoxnWhM7Jl4pNwj+JlSS1 MvirgS9YnPX0jrbCbus210eHHsAD7ni717OWHXLQ83399cVip8h6qsgcApgVATmdjZeoi7vQh SFL9jieLs5jkf4Tafye29hvZLiv9uz2YdIAWasBWxtiFHNdUauyszukZrg0Pqv20c6A70M+To bdB/pb8JRPT+fSFfMgrxptUTgo2LYzinVLFCWG7U+KNog0Ngl3k3i6XoN8cEtQmsKjI884jz6 5r2sIgr72yak/s+wEz5ptdR3YS+sYAq92T6+JadcgOVtRO5fLzTPn2i1GpP7Jo0qbZIqVoTVJ FeOqoM2iPkkgaROpR0kw3+PqOdkWALTVaKuzqFT8LX6bv5iD1CN+70BzRz8+yRdW6dBQ0UvaI +v9MFtNuHJ/NrrYp3d2G0ERd8rDGqUf54GVNfYUBgrZUYlxnyQSzuPz52dxKzXOHa3paShHUn ZALrytkPPYw2yoEzzBeBMaFWR3jQ0hOLxJ//8YaZ2glwTjKwdBDeCW+74OPe55FBgzCFbtTN2 eSGtR3QC5yJf6DQbe/wNMaE4AvWfqwQNOBXIUHfKUulKr/1jjl4wVHfNc5XH4M8hXOi1JsVUD sR1bSPcTgeFo0D3kepSfms72EYgzqi87Qg1XvCg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Vbu-lDwlIgJxAk1ciyqf0F4K1PU>
Subject: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2020 06:31:31 -0000

Hi Ben,

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

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

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

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