Re: [TLS] Choice of Additional Data Computation

Felix Günther <> Mon, 18 May 2020 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 919823A088C for <>; Sun, 17 May 2020 23:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mqsu7X6ChMss for <>; Sun, 17 May 2020 23:37:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A37B63A0889 for <>; Sun, 17 May 2020 23:37:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 125694F206A5 for <>; Mon, 18 May 2020 08:37:03 +0200 (CEST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id CCCF54F20081 for <>; Mon, 18 May 2020 08:37:01 +0200 (CEST)
From: Felix Günther <>
References: <> <> <> <> <> <> <>
Autocrypt:; keydata= xsDiBE04qkIRBADtFenVz1DuqethtPkoKAazBeKjyrr5Znbi8mQT1gOrkuli6i0/umf2uJ9V uI6NgjR0uM68UFGIHZlAoWk5Nfo8BTkYsdXl4R08pePmwRwwtq9LALZrGkeLeQtOFdLJt7G2 iQgqq2XpZc9AXW3/+j0I6MmsWMQKCkCA1s6IRLtH+wCgk85oP1adRYaEpi82Z3oG7vztEOkE AMccj8RgnjWcbB13HxxRk2C/4mgLEmCBWO3nmcCPZP5t/5GZSe7Kt5HQoygjxxcro/2e+9wF YsYwLUpHKMOjyvtcU0jLtIv0m6I+GQ3HOz89erVpa7G7EUoEsbQ7FEuyW4mVEaQZ3XE1Mxvp /3Ca1rBJjoxXhxKaDJYWsc5fdO6RA/44xXLdiE2f6NDoTJY7Z97VXUnJskpDNnwePOJyX4GT DwII2kl6JSYOAmkcOpINOSVsS0XDLZpBuKqsibUF/t53BkNfR/aF/BzIUJ5dykqrHvi75aQb ltSum1+kIo8Q6ZI+MzAAwmbqLfuRHZP5y0fjxdHLhfMrvacrNHnaoUWrVc0oRmVsaXggR8O8 bnRoZXIgPG1haWxAZmVsaXhndWVudGhlci5pbmZvPsKTBBMRAgA8AhsjBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgBYhBCuuSm95RkYbcAFhs1KvAgDT8XAOBQJdE93OAhkBACEJEFKvAgDT 8XAOFiEEK65Kb3lGRhtwAWGzUq8CANPxcA5VLACfRCZFjMy2oVl6MKcxqSLOqxpYcmUAniNH ecOrDmHcK3hfLPUIRCtR0mDPzsNNBE04qkIQEAD1M2gM5rQ9UIBa+323DToxTD4PQ+gCGSXW OU0TN41q0sNCp/ph6Ec6C2OmADy2m6UMlSr+jc03XkmxQHV6XqhCN7rjijCqEQUPxXTY2zdk rqEaAFEa6mnpErCDvQXjPi6QrAJLvz2tl3Bqry35ffs1FQ/jVjnfuSB83ZHUEUsHQDX1Bvna exqd4FRKAYte7f1vEOsei6eguMyK0lrXQBNFy5GfLx4nMC5cjyUJRE2MI9YlWNc3eCz7PqwD 95uvaKctBPrpYhBmLlDfUE3I8Z5pqL7u3shul+SGqdscBMOrq+0zyUJ6b6uxhzcy03VbiNBn n0AIjeJ67cyi4yg3hbmanRuMHqg2I7VNNgPdlRgF5XshNfjuVqDsD0w/MHBtEZ160A3XJTkc O/uaBp16L+gWXALj+EPXyRiO4cRTEqIKiiRllo9AQxMqMGkeGumFKyVNeX+1aYwkGhWyB52C FbJ/f2jxk5MGxBDXAfCE70Nz5/BP9DYHDqN1lLPBBUkbXeGD+4LoerGFh+Ioe2yIy6qdvk4g zSqRZrdD9e1FyWiSTx6VOMdgggz4cF2LbGPKzwP7WBU8jyzg3A9ECNzmb+QBfLNutuD6n5lV 7cglMTgz+F5KEvOygWtmiugTZPfyu9NayJ2j/zMlkLEn4ksBHynwFgpgEl6X+key9EXBJhs4 QwADBg/+P3Tm8Bn8wmUusSVDp5XBTZcgGEWaw61BxWaHcJnDRC5cwDUBCxB7cosslJ8EQ/wu PPz9j2Y827zCa+HDTg/HSjs2zrI4S6+/gLJDNpnAka+fSUjhRqNLvLiaAYWR3UCY+LX/h6X1 inibLzxWU5xJ7+Zpybj4wIgAwN6A0vEnMStmA4xAlV1LPitVhpZOhMT8NW9EWS4RmBk2e8i/ wbjo4Jm2edEW/VdAOi7Fqna07zIYFD4HEFleqte3J5XPXB44EhUfJxTGL2QZFDkz301+tm4i dHXfzZb1hiGqJWC+a9YSwtkVGgauHzDXJWTLHDogaKRaWTCrxMsZWUCKoDwAQ1ln1sklU6fn uV3oO/PxzxS8em9KlRu3djeN/QYlsOeWPi/dmsjFwjdGZQgZ/QJANKmqtQemmArCIE9IstFF Cu4bDuPMukyq7tqv7Z+E1AHcYtKbKCKR1hdE5+YgirQnmD+tktIVDUZmYvdLympL2wlCHQpk RQT7U+3MChhRin1u1HkmjelvICfoz+BI2VI0NTBrYRqLp/Ld8G7UpPUBiCe0vNXImvZD9Z3z kyMX9r0YjlfyWae89IAn+h9Ij9tGMurI2Pp+souvO0VX25xaEpChB3iIT2p7bzgpip1CrgFl SE7gnaeXatZsSq6gV70AJ0hUEi5GgIcRSut4wbS13KbCSQQYEQIACQUCTTiqQgIbDAAKCRBS rwIA0/FwDqNgAJ9h3wSRXwbvSK4+TIAcxlnxbyVZSgCgkSUHgTNTyiliLBDDTYdG9b+pi4k=
Message-ID: <>
Date: Mon, 18 May 2020 08:37:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <>
Subject: Re: [TLS] Choice of Additional Data Computation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 May 2020 06:57:27 -0000


On 2020-05-06 08:00 +0200, Hanno Becker <> wrote:
>> The latter, to me, suggests that authenticating the pseudo-header alone
>> may not be sufficient. It would at least allow on-path modifications to
>> the on-the-wire header, which I don't expect is intended.
> Can we go a bit into this? As mentioned in the original thread
> there are some (arguable) considerations of why it has practical benefits 
> to not cryptographically bind the header _format_ to the record.
> Those considerations, however, are secondary to security considerations,
> so they didn't surface here so far.
> Could we therefore clarify:
> Are there any _security_ concerns arising from the modifiability of the
> header format assuming the underlying pseudo-header is bound via AEAD?

This will depend on what security you want to aim at. Clearly, if
non-malleability of headers is a goal, then yes.

More generally, cryptographic models of secure communication channels
would carve out "a ciphertext" (in quotes, as its not only the AEAD
ciphertext) from the spec. Now, it's always a modeling choice what this
ciphertext should include. A reasonable and natural choice for DTLS
would be to include the full on-the-wire header. Integrity would then
require that any modification of that header leads to the ciphertext
being rejected.
At the minimum, one would need to include all cryptographically relevant
information (esp. epoch, sequence number) enabling decryption, but then
singling those out from the wire format feels a little odd.

Hence, I would say that a natural cryptographic security notion most
likely suggests full on-the-wire header authentication. But again, it
all comes down to what's the goal.

> I don't see one so far, but might miss something. In my head, once the
> logical 
> data is authenticated, the entire on-the-wire header merely degrades to
> a 'hint' 
> to the receiver as to what the logical header data is, the precise form
> of which
> is entirely irrelevant.

This depends on the perspective. For analyzing channel security, it is
often conceptually easier to follow a modular approach that combines
confidentiality under passive attacks (usually straightforward) and
integrity of ciphertexts under active attacks. The latter means: no
modification of the ciphertext on the wire is permitted (in contrast to
plaintext integrity, demanding only that no modifications to the payload
can be made). This argument hence indeed relies on headers not being

Our security analysis [1] for example models that the decision logic of
whether receiver should be accepting a certain next packet must be
decidable from the transcript of sent and received packets so far
(publicly, without internal keys or state).
Whether this would still work with a malleable 'hint' to the logical
header I don't know. Not saying this can't work, but our analysis
doesn't speak to that.

> Would you expect a change in proof complexity when switching
> to explicit length and sequence number authentication in the AEAD?

Length: no.
Sequence number (and epoch): only minor, as it merely obviates one level
of indirection (authentication via the nonce input).


[1] Marc Fischlin, Felix Günther, Christian Janson. Robust Channels:
Handling Unreliable Networks in the Record Layers of QUIC and DTLS.
Preprint for QUIPS 2020 Workshop at