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

From: Achim Kraus <[email-masked]>
Date: Sun, 4 Oct 2020 16:35:49 +0200

Hi Ben,

any progress on the cid-length / calculate MAC topic?

As I wrote, though the cid-length itself is not "on the wire" (it's only
the cid), I can't see, that the cid-length could be injected.
Do I oversee soemthing?

best regrads
Achim Kraus

-------- Weitergeleitete Nachricht --------
Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Datum: Wed, 16 Sep 2020 08:31:19 +0200
Von: Achim Kraus <[email-masked]>
An: Benjamin Kaduk <[email-masked]>
Kopie (CC): [email-masked], [email-masked]

Hi Ben,

...

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

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Oct 2020 16:34:54 -0700

Hi Achim,

Sorry for the long silence on this front; my attention had cycled elsewhere
and I was just overall operating slowly for a couple weeks (sick, maybe,
but no clear symptoms).

My primary concern is not actually about a specific situation where
injection occurs, but rather for cryptographic hygiene -- whenever we
assemble an input for a cryptographic operation (especially MAC or signing)
it is important to ensure that the sequence of bits used as input to the
cryptographic operation can only be produced by a single combination of
logical inputs to the protocol-level operation or message that we are
applying cryptographic protection to.  This property is known as
"injectivity", because the map from protocol-level values to bitstrings
(themselves used as input for cryptographic operations) is an injective
mapping in the mathematical sense.  I believe that I have demonstrated that
the current MAC construction does not use an injective mapping and is thus
not consistent with best practices.

However, in particular...

> If that is going to be changed, the early adopters run into trouble with

I'm not sure I follow.  Are you saying that if there is a theoretical
problem with the construction it would have been exposed by implementation
testing?

> fail anyway. So, I can't see that collision.

Consider the MAC-then-Encrypt case.  We *know* that there are devices in
the field that get TLS encryption but not MAC keys for use in monitoring
situations (e.g., enterprises subject to particular compliance regimes).
So it is perfectly reasonable to consider a case where a third party has
encryption keys but not MAC keys, and is not expected to have the
capability to modify the plaintext of the stream.  However, having stripped
the encryption by using the keys that they already possess, it is possible
to move a byte (or in general, multiple bytes) between the cid field in the
outer portion of the record and the inner plaintext, without modifying the
MAC value.  Encryption can be reapplied, again using the already-known
keys, and the stream as received by the other TLS peer is modified,
breaking the principle that the party not knowing the MAC key should not be
able to modify the plaintext.

(I am not entirely convinced that encrypt-then-mac is intrinsically immune,
though a successful attack would seem to require knowledge of the
underlying structure of the plaintext even if the specific content is not
known.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Oct 2020 16:41:10 -0700

Hi Achim,

Sorry again for the delayed response.  (Inline.)

On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> 
> Am 16.09.20 um 08:31 schrieb Achim Kraus:
> > Hi Ben,
> >
> >>>
> >>> 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.
> >
> 
> Let me add:
> 
> - If the scenario uses "dynamic 5-tuples, with CID or without" and
> "static 5-tuples without CID",
> - then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
> pool) and CID (described in
> https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
> communication to such a static-5-tuple without CID.

Yes, I think this is the disruption I was pondering.

> Even then, that "static-5-tuple" peers must be anyway aware, that
> sometimes new handshakes are required. So that scenario may also depend
> more on the volume of such attacks, than just on the pure possibility.

It does seem like a pretty rare/difficult attack, unlikely to be worth the
trouble.  But perhaps it is still worht documenting as a property of the
protocol ...

> In my experience, such "static-5-tuples" are rare and I would guess,
> they will benefit from different handling also for other reasons.
> Therefore I would just spend them an separate endpoint to separate their
> traffic.

... especially when we can give this recommendation as a workaround.
(Actually, is it generally a good idea to try to steer CID-ful and CID-less
traffic to different endpoints?)

Thanks,

Ben

---

From: Achim Kraus <[email-masked]>
Date: Fri, 9 Oct 2020 07:56:00 +0200

Hi Ben,

 > problem with the construction it would have been exposed by
implementation

No, I don't say that.
"Early adopters" means, there people using
draft-ietf-tls-dtls-connection-id-07 in real world systems with that
current definiton of the MAC. If that MAC calculation is changed, then
they need to adapt their deployments in the field, which is not too easy
(and potential dangerous). Sure, draft-ietf-tls-dtls-connection-id-07 is
still only a draft and could be changed. But not without trouble for
those "early adopters".

 > not consistent with best practices.

*** protocol-level operation or message ***

I understood your example in your previous mail.
I tried to explain, that the data of your example, especially the
cid-length, is not in the message. Please, find the time to check that
current record defintion! There the CID is encoded in the protocols
tls-cid-records without the explicit CID length.

With that, I can't see the posssiblity to inject the cid-length.
It's simply not "in" and so can't be "injected".

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Fri, 9 Oct 2020 08:19:11 +0200

Hi Ben,

> trouble.  But perhaps it is still worht documenting as a property of the

The point from my side was, that anyway, with or without that attack,
even clients with static-5-tuples must take care of their "encryption
association". If the client expects responses but didn't get them, then
a new handshake may be required. So, I'm not sure, if explicitly mention
that, really changes the game.

> traffic to different endpoints?)

If it's possible to use different endpoints, I think so.

best regards
Achim Kraus

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Oct 2020 14:22:40 -0700

Hi Achim,

> still only a draft and could be changed. But not without trouble for

Ah, I see what you mean now.

If we are concerned about changing the behavior, we can (and, arguably,
should) allocate a new TLS extension codepoint to indicate the new
behavior.  That would leave existing implementations able to function with
the old semantics until they age out/are upgraded/etc.

> tls-cid-records without the explicit CID length.

I understood your previous message, as well -- yes, the CID length is not
encoded in the message on the wire, and is implicit based on what the
entity allocating it has advertised.  I am asserting that the cryptographic
construction we are using is flawed, which is independent of what is
actually on the wire.

To be frank, I'm actually surprised that this is even seen as a matter for
discussion.  We've been doing quite well recently (e.g., for TLS 1.3) at
using rigorous and veriviable cryptographic constructions that are provably
secure at the smallest modular level.  This scheme is a regression in that
regard -- it relies not only on the cryptography for secure operation, but
also on some specific behavior of the application that is external to the
cryptographic processing (relating to how the application extracts the CID
and looks up the DTLS association/key material).  The behavior we should
demand from our cryptographic constructions is that the cryptography itself
correctly returns "valid" or "invalid" based on the input message, provided
that the application inputs the correct key material.  (It should also
return "invalid" if incorrect key material is supplied, of course.)  The
ability to produce two different messages for which the cryptography
returns "valid" violates this principle; even if we do not see an obvious
path by which a reasonable application might supply those inputs to the
cryptographic code, it is still a flawed construction.

-Ben

---

From: Achim Kraus <[email-masked]>
Date: Sat, 10 Oct 2020 09:13:51 +0200

Hi Ben,

> 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

There are many (proposed) changes since then. I already tried to point
to that with my e-mail answer from 4. September

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

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?

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

best regards
Achim Kraus

---

From: "Michael D'Errico" <[email-masked]>
Date: Sat, 10 Oct 2020 13:29:13 -0400

On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> [...]  The behavior we should demand from our cryptographic
> constructions is that the cryptography itself correctly returns
> "valid" or "invalid" based on the input message, provided that
> the application inputs the correct key material.  (It should also
> return "invalid" if incorrect key material is supplied, of course.)
> The ability to produce two different messages for which the
> cryptography returns "valid" violates this principle; even if we
> do not see an obvious path by which a reasonable application
> might supply those inputs to the cryptographic code, it is still
> a flawed construction.

Hi,

I'd like clarification about this point, where the cryptography
should return values of "valid" or "invalid".  This is a general
question, not specifically about this draft.  (Please read at
least the next 2 paragraphs.)

I remember a long time ago, it may have been the renegotiation
info extension, where there was a lot of calculation being done,
there were two complicated values each side had to compute.
If they were equal, then everything was fine and the handshake
could proceed.  If not, there was an insecure renegotiation
happening.  (Or maybe it was the downgrade protection RFC,
I can't remember now.)  But if the values were not equal, then
something bad was happening and the handshake should not
proceed.

The problem both Martin Rex and I discovered at nearly the
same time (posts to the mailing list within minutes of each
other) was that both sides could go through all the motions
faithfully calculating all of the values, correctly, and then
forget to compare them to see if the values were actually
the same.  I noticed this because I wrote the code, and it
seemed like an easy thing to overlook.

I remember suggesting that we somehow incorporate the
calculated values into the derivation of the record layer keys
so the MAC would fail, or maybe into the Finished message
calculation so (if you remember to check that?) a failure is
noticed later.  This suggestion was shot down by the author
unilaterally for what I perceived at the time to be petty
reasons.

I still believe that (D)TLS security should not rely on the
implementer to check whether two values are equal.  This
is too easy to forget to do.  Or you could do this in C:

    if (complex_value_a = complex_value_b) {
        // we're in trouble....
    }

I have not looked at the TLS 1.3 draft beyond the hour or so
I've put in so far to see whether this reliance on checking is
in there too.  I've also not checked whether the security
proof I was referred to has any games where the implementer
forgot to compare values.  Or a game where everybody made
the same error and nobody noticed (forgetting to put the
HelloRetryRequest into the Tramscript-Hash for example).

Mike

---

From: Achim Kraus <[email-masked]>
Date: Sat, 10 Oct 2020 20:27:20 +0200

Hi Mike,

 > in C:

That's a pitfall of C ('=' is not '=='). You will be almost in trouble,
if the complex value is not 0.

But the discussion here is more about how often somethings should be
adapted again and again. The point from Ben are all very valid, but they
should have been raised at least 1 year ago. Now, the point is, if
"cryptographic hygiene" without "actual threat" (at least, this was not
explained) should modify the MAC again. If so, the question may be, when
this changes will end.

best regards
Achim Kraus

---

From: Joseph Salowey <[email-masked]>
Date: Sat, 10 Oct 2020 15:26:40 -0700

> changing the MAC again. Please, this year, not next :-).
[Joe]  It's unfortunate to find issues that require breaking change at the
end of the review cycle, especially for a draft that has taken a long path
to get here.   If there is an issue that is exploitable, even in a corner
case, someone will develop an attack, clever name, logo and website and we
will all have to scramble to deploy a fix.   It's better to fix now rather
than later.   In this case, I don't have a way to exploit this issue, but
unless someone has a way to demonstrate that this is not going to be an
issue then I believe it is prudent to fix it now.

Would this issue have been caught by formal verification?

---

From: Achim Kraus <[email-masked]>
Date: Sun, 11 Oct 2020 08:26:47 +0200

Hi Joe,

 > [Joe]  It's unfortunate to find issues that require breaking change at
 > the end of the review cycle, especially for a draft that has taken a
 > long path to get here.   If there is an issue that is exploitable, even
 > in a corner case, someone will develop an attack, clever name, logo and
 > website and we will all have to scramble to deploy a fix.   It's better
 > to fix now rather than later.

 > In this case, I don't have a way to
 > exploit this issue, but unless someone has a way to demonstrate that
 > this is not going to be an issue then I believe it is prudent to fix it
 > now.
 >

In my opinion, ONE change may be possible. A server may be configured to
use only the old, only the new, or both by "try on the client's finish".
I'm not happy with such "dirty" work-around. I would prefer to do so for
something more the "cryptographic hygiene".

So, if the MAC is considered to be adpated again, should it not be
discussed, why at all the cid-length should be put in?
I asked this already in January 2019

https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915

The MAC contains already a overall length. Even in that discussion, no
one mentioned the reason for adding it. So if there a doubts about
injection, why not remove it at all?

 > Would this issue have been caught by formal verification?

That may also be something to help, not to change still again and again.

best regards
Achim Kraus

Am 11.10.20 um 00:26 schrieb Joseph Salowey:
>
>
> On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Ben,
>
>      >
>       >> 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!
>
> [Joe]  It's unfortunate to find issues that require breaking change at
> the end of the review cycle, especially for a draft that has taken a
> long path to get here.   If there is an issue that is exploitable, even
> in a corner case, someone will develop an attack, clever name, logo and
> website and we will all have to scramble to deploy a fix.   It's better
> to fix now rather than later.   In this case, I don't have a way to
> exploit this issue, but unless someone has a way to demonstrate that
> this is not going to be an issue then I believe it is prudent to fix it
> now.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 10 Oct 2020 23:49:36 -0700

> injection, why not remove it at all?

The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective. Here though it isn't clear if two different inputs to the
encoding could end up the same. In fact I think in the MAC setting
there almost certainly is a problem as the length of the ciphertext is
right after the cid length, and with some cleverness you can come up
with a cid and ciphertext that could be interpreted multiple ways.
Unfortunately I haven't followed the draft's discussions that closely.

I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.

> That may also be something to help, not to change still again and again.

I don't think the formal models of TLS reach the wire encoding.

-- 
Astra mortemque praestare gradatim

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 11 Oct 2020 10:51:00 +0300

> injection, why not remove it at all?

The problem is the follows:

Take the following input to the MAC (MtE case):

<seqnum> 19 FE FD 63 01 00 05 04 00 02 FF 17

There is no way to tell from that input if it is:

- Application record on CID 63 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.

The overall MAC length will not catch this, because the overall length
is the same in both cases.

And even if it seems that the data lengths after depad should be
different, it is unsafe to rely on depad length.

Stripping the CID length will not solve the issue. Heck, if cid length
is removed, the very above example is still ambiguous, now for:

- Application record on CID 63 01 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.

For EtM construction, it is even worse. There is no way to check for
consistency, because CBC mode leaves end of message intact even if
IV or length are bogus, meaning all the depad and content-type checks
will pass.

The AEAD construction is not affected. Even if the design is pretty
bad, the CID is the only variable-length field in AD, so its length
can be inferred from AD length.

Swapping order of CID and its length will solve it:

<seqnum> 19 FE FD 01 63 00 05 04 00 02 FF 17

- Application record on CID 63 containing 04 00 02 FF.

<seqnum> 19 FE FD 04 63 01 00 05 00 02 FF 17

- Application record on CID 63 01 00 05 containing FF.

Tricks altering CID length are not possible, because those will
alter a byte at fixed position. And one can not alter CID without
changing its length either, as those will alter bytes at fixed
position as well.

-Ilari

---

From: Achim Kraus <[email-masked]>
Date: Sun, 11 Oct 2020 19:43:14 +0200

Hi Wadson,

> injective.

I hope, this is just a "typo" or "mistake".

Prepending the length is the change, Ben want to use to protect against
injection. You now say, this will be "obviously injective".

> Here though it isn't clear if two different inputs to the
> encoding could end up the same.

Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
all examples so far are just incomplete. They must declare, if the
"different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.

"different MAC_write_key" => obviously "end up" different.
"same MAC_write_key" => the decoding of the records gets ambiguous

> In fact I think in the MAC setting

That's just a theroretical numbers game. No one os far made any really
useful example from start to end. FMPOV, "CID with dynamic length" MUST
use a unique/deterministic encoding. If that encoding ambiguous, as
others imply/assume in their "numbers game", the whole record gets
ambiguous.

Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try out the MAC for both "different
MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
the receiver will not know by the failing MAC, which interpretation is
the right. I guess, this will end up in decrypt twice, also obvious time
signal.)

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Sun, 11 Oct 2020 20:12:30 +0200

Hi Ilari,

> - Application record on CID 63 01 00 05 containing FF.

Maybe you check your example?

Does the 1. assume cid-length := 1?
And the 2. cid-length := 4?

The dtls-record will then contain:

(remove cid-length 01, cid-length is NOT encoded in the dtls-record!)

19 FE FD <seqnum> 63 00 05 04 00 02 FF 17

or

(remove cid-length 04)

19 FE FD <seqnum> 63 01 00 05 00 02 FF 17

For me this seems to be different input to the MAC, if the cid-length is
left out. My feeling is, your example proves my opinion, that it's
better to remove the cid-length from the MAC.

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Sun, 11 Oct 2020 20:24:03 +0200

Hi,

> perhaps I'm misreading the intent of the [] notation in the record

I created an issue on github to discus the requirements for encoding
variable length CIDs.

https://github.com/tlswg/dtls-conn-id/issues/76

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Sun, 11 Oct 2020 22:41:31 +0200

Hi Wadson,

my bad, I mislead in understanding "injective".
It's not related to "injection".

best regards
Achim Kraus

---

From: <[email-masked]>
Date: Sun, 11 Oct 2020 22:53:49 +0200

Dear Watson,

I object to your comment about formal models of TLS not capturing wire encoding issues. miTLS does in fact formally specify the format of all messages on the wire to the bit.
In fact this is complex enough that we have a full paper just about the subject that will tell you more or less everything that was said in this thread
http://antoine.delignat-lavaud.fr/doc/usenix19.pdf - https://github.com/project-everest/mitls-fstar/blob/dev/src/parsers/Parsers.rfc is the formal TLS message format specification including the demonstrably unsafe constructions (implicit tags on server key exchange in 1.2 and CertificateEntry in TLS 1.3). 

In the specific context of connection ID, QUIC up to draft 16 did suffer from an attack caused by the lack of encoding of the CID length. The attack is caused by the concatenation of two variable length fields in the network format (the CID and the packet number) that can both be tampered by an active attacker. The boundary of the concatenation is made ambiguous to the crypto authentication (AAD of packet content encryption) by QUIC header protection, which is applied before decryption. See https://eprint.iacr.org/2020/114.pdf (Section III.D) for a description of the attack. See https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fsti and https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fst  for the formal proof that the QUIC varint encoding with minimal length representation satisfies the strong prefix property.

Antoine

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Watson Ladd
Sent: dimanche 11 octobre 2020 08:50
To: Achim Kraus <[email-masked]>
Cc: [email-masked]; [email-masked]; Benjamin Kaduk <[email-masked]>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus <[email-masked]> wrote:
>
> Hi Joe,
>
>  > [Joe]  It's unfortunate to find issues that require breaking change 
> at  > the end of the review cycle, especially for a draft that has taken a
>  >> I would prefer, if this is not changed again without strong  >> 
> arguments!
>
>  > In this case, I don't have a way to  > exploit this issue, but 
> unless someone has a way to demonstrate that  > this is not going to 
> be an issue then I believe it is prudent to fix it  > now.
>  >
>
> In my opinion, ONE change may be possible. A server may be configured 
> to use only the old, only the new, or both by "try on the client's finish".
> I'm not happy with such "dirty" work-around. I would prefer to do so 
> for something more the "cryptographic hygiene".
>

The doubt is because of where it appears not that it appears. If every value was preceded by its length the encoding would obviously be injective. Here though it isn't clear if two different inputs to the encoding could end up the same. In fact I think in the MAC setting there almost certainly is a problem as the length of the ciphertext is right after the cid length, and with some cleverness you can come up with a cid and ciphertext that could be interpreted multiple ways.
Unfortunately I haven't followed the draft's discussions that closely.

I do not understand how a CID is supposed to be parsed by a recipient when the length can change and the length field is not encoded, but perhaps I'm misreading the intent of the [] notation in the record layer of the draft.

---

From: <[email-masked]>
Date: Sun, 11 Oct 2020 23:26:03 +0200

P.S. additional comments for the authors of the cTLS draft:

- it is absolutely not acceptable to tolerate two different finish values for the same handshake depending on which codec was used to carry the handshake messages. This would be an attack against the security definition of TLS in virtually every model that was published, symbolic or computational.
- it is actually very easy to prove the security of cTLS modularly (i.e. without changing anything in the security model of normal TLS). The idea is to express cTLS as an injective type cast, as suggested by others in the thread.
The argument for the security is based on the parser synthetizer combinator, which takes a parser p for type t1 and an injective function f:t1->t2 and returns a parser p' for the type p2. It is possible to generically prove that the combinator preserves the strong prefix property. See https://github.com/project-everest/everparse/blob/master/src/lowparse/LowParse.Spec.Combinators.fsti#L487 (and corresponding fst) for the proof.
Writing and proving the injectivity of the f function is probably quite easy, as it's a function defined a high-level representations (and it's mostly filling missing fields with default values). We don't have time to do it now but if someone wants to get familiar with F* and the EverParse framework it's probably achievable to a beginner with some experience in program verification and functional languages.
- the generic argument only works if both peers know in advance which codec they want to use. If some clients and servers may accept both, something must be done to ensure that the same codec was used by both peers if the security model expects they must use the same codec (unless it is an explicit goal to allow an active adversary/"middleboxes" to re-encode transparently to the peers). 
An easy way to do this is to see the codec as a transport layer negotiated parameter which is authenticated in the handshake with an added extension (similar idea to QUIC TP).
If the CH is shared by both codecs it is possible to negotiate cTLS with a normal extension.

Best,
Antoine

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: dimanche 11 octobre 2020 22:54
To: 'Watson Ladd' <[email-masked]>; 'Achim Kraus' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>
Subject: RE: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

Dear Watson,

I object to your comment about formal models of TLS not capturing wire encoding issues. miTLS does in fact formally specify the format of all messages on the wire to the bit.
In fact this is complex enough that we have a full paper just about the subject that will tell you more or less everything that was said in this thread http://antoine.delignat-lavaud.fr/doc/usenix19.pdf - https://github.com/project-everest/mitls-fstar/blob/dev/src/parsers/Parsers.rfc is the formal TLS message format specification including the demonstrably unsafe constructions (implicit tags on server key exchange in 1.2 and CertificateEntry in TLS 1.3). 

Antoine

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 11 Oct 2020 17:37:54 -0400

> The argument for the security is based on the parser synthetizer combinator, which takes a parser p for type t1 and an injective function f:t1->t2 and returns a parser p' for the type p2.

TLS, I don't even know you anymore....

Mike

---

From: Achim Kraus <[email-masked]>
Date: Mon, 12 Oct 2020 07:41:21 +0200

Dear Antoine,

thanks for adding the references.

I tried to understand https://eprint.iacr.org/2020/114.pdf (Section
III.D). But to be frank, as developer, it's extremley hard not to
misunderstand, what is documented there.

For me, this seems like in QUIC, the length of the CID is encoded in the
sent message (so it's on the wire).

For draft-ietf-tls-dtls-connection-id-07, at least as far as I
understood it, there are two general possiblities:

- a peer chose to emit only CID with the same static length. In that
case, the cid-length will always be the same (cid-length is not on the
wire). It can't be injected, except someone injects the execute programm
code itself.

- a peer chose to emit CIDs with variable length. In the case the other
peer is intended just to add that received CID in the hello extension to
the dtls-records. The emitting peer has to chose a encoding for such CID
with variable length, that the emitting peer is able to decode it. In
this case the cid-length is on the wire, but the encoding is not
specified in draft-ietf-tls-dtls-connection-id-07. In my opinion it's
extremely important, to chose a encoding, which could not be interpreted
in different ways (I guess, that's what Watson ment by "injective").

With these both options, FMPOV, to add explicit someting as the
cid-length to the MAC is not required. It's either the same static
value, or must be already encoded in the CID itself, which is already in
the MAC. But it may be required, to add constraints about such a
encoding for variable length CIDs to the draft.

The confusion may be mainly caused by the idea, to support both, static
length CID and variable length CIDs. That misleads to build examples,
assming that two CID may be used, where one CID is the start of the
other. In my opinion, that's a problem of the encoding of the variable
length CID, but not the MAC.

best regards
Achim Kraus

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2020 12:57:02 -0700

Hi Mike,

> in there too.  I've also not checked whether the security

The TLS 1.3 handshake transcript is an input to the key schedule; manual
comparison of generated values is not necessary for security.

I would encourage you to continue in your efforts reading RFC 8446 -- in my
opinion we put quite a bit of effort in towards making it readable.  (With,
perhaps, the exception of stateless HelloRetryRequest as you have already
noted, since the main expected use case is in DTLS.)

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2020 13:05:48 -0700

Hi Achim,

On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,

Since apparently this was not fully clear, allow me to link the wikipedia
article corresponding to "injective map (in the mathematical sense)" in my
earlier description: https://en.wikipedia.org/wiki/Injective_function

> useful example from start to end. FMPOV, "CID with dynamic length" MUST

In my opinion a useful example from start to end is not a prerequisite for
making a change to the spec in the face of a demonstrated local weakness.
Attacks only ever get better, and we should not leave known building blocks
for them in place.

> others imply/assume in their "numbers game", the whole record gets

Yes, an entity assigning its own CIDs has to be able to distinguish them on
receipt based on the record bitstream (which does not supply its own
framing for the CID length).  The current text may not be as explicit about
this requirement as it could be (it may only list a requirement that the
values given out have to be recognized, not that there has to be a unique
parsing of all potential CID bytestreams in a received record that rejects
invalid ones?  I didn't check).

> the right. I guess, this will end up in decrypt twice, also obvious time

Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Oct 2020 13:45:35 -0700

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

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

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

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

---

From: Achim Kraus <[email-masked]>
Date: Tue, 13 Oct 2020 06:41:50 +0200

Hi Ben,

> implementation knows exactly which procedure to use.

My concerns are based on permit ambiguous CIDs.

 > DTLSInnerPlaintext.content = <513 bytes>.

That results in my opinion in cid 01 and cid 01 01 being valid for the
same peer and same time.

or

 > - Application record on CID 63 01 00 05 containing FF.

being valid for the same peer and same time.

That seems to be the precondition for the threats. Permitting such
ambiguous CIDs may be then the root cause for such a "time side channel".

With the reference from Antoine (https://eprint.iacr.org/2020/114.pdf,
Section III.D), I started to consider the encoding of a "variable length
CID" to be the real spot. That points for me to the same direction, it's
that encoding not the position of the cid-lenght.

best regards
Achim Kraus

---

From: Achim Kraus <[email-masked]>
Date: Tue, 13 Oct 2020 06:50:52 +0200

Hi Ben,

> did not previously think about them in that formulation).

Hope, I'm not again catched by my bad english :-):

If the forumlation refers to draft-ietf-tls-dtls-connection-id-07 (and
not my e-mails), I can't say, what was thought or not by the authors. My
role in that discussion quite a year ago, was just to ask, which of the
many variants should then be chosen in order not to change it every year.

That's also the main thing, which drives me to this endless discussion.
If it changes again, try to change it that last time.

best regards
Achim Kraus

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2020 14:20:09 -0700

> Hope, I'm not again catched by my bad english :-):

Sorry, my writing became less clear when I attempted to edit it :(

> many variants should then be chosen in order not to change it every year.

I was just saying "I only told you the list of two things that are the
standard guidance just now; I don't expect that you used those two things
as part of your thought processes before I told them to you".

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2020 14:24:28 -0700

> My concerns are based on permit ambiguous CIDs.

Ah, I think I understand better now (based on this and the rest of your
note).  I do not think we should allow such ambiguous CIDs, since (as you
note) they would require some "trial decryption" processing and the ensuing
time channels.  That said...

> That results in my opinion in cid 01 and cid 01 01 being valid for the

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

-Ben

---

From: Achim Kraus <[email-masked]>
Date: Thu, 15 Oct 2020 08:12:14 +0200

Hi Ben,

> 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

 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Oct 2020 08:59:43 -0700

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Oct 2020 19:13:16 -0700

Hi Ekr,

Thanks for chiming in.

> the correct CID. I believe this is clear in the specification:

I am pretty sure that we all agree on this, yes...

>    Note that there is no CID length information included in the record

...and thanks for the reminder about how we say so in the text already.

> this topic), so just prefixing the CID length is also not ideal.

I think the current scheme is unfortunately using fields put together in a
rather different order than the actual bits on the wire (more below).

> official interface of TLS -- and of course it doesn't really

I agree.

> side effects of the current construction.

To be clear, I'm more concerned about the "other negative side effects";
bringing up this case was just a convenient rhetorical device to attempt to
illustrate that what seems like a local cryptographic annoyance can be
parlayed into something more significant.

> some. Here's one potential alternative, though I haven't studied

Seeing you write this has served to finally hammer home for me a point that
Achim has been making for some time.  Sorry for being so dense about this,
Achim!  That is to say, if we're making any change at all, we should change
to what is unambiguously the Right Thing, not just make a fiddling change
on the margins -- there's not much difference in implementation impact, and
we can get it actually right and not have to change it again.

>   uint16 DTLSCiphertext.version +      |  appears on wire   | non-CID MAC input
>   opaque cid[cid_len];                 /                    |

I like (1) and (2) and agree with (3), though I'm having a little trouble
lining up your figure with the DTLSCiphertext structure, which I'll repeat
here so I'm not flipping back and forth as much:

        struct {
            ContentType special_type = tls12_cid;
            ProtocolVersion version;
            uint16 epoch;
            uint48 sequence_number;
            opaque cid[cid_length];               // New field
            uint16 length;
            opaque enc_content[DTLSCiphertext.length];
        } DTLSCiphertext;

Ah, your proposal looks more natural if I compare it to the current AEAD
"additional_data" from the -07:

#      additional_data = seq_num +
#                        tls12_cid +
#                        DTLSCipherText.version +
#                        cid +
#                        cid_length +
#                        length_of_DTLSInnerPlaintext;

If I could try to synthesize your key points (as I understand them), hewing
more strictly to the "bits on the wire" philosophy would suggest having us use:

additional_data:
struct {
  uint8 marker = tls12_cid;
  uint8 cid_len;
  uint8 content_type = tls12_cid;      \
  uint16 DTLSCiphertext.version;       |  appears on wire 
  uint64 seq_num; // includes epoch    |
  opaque cid[cid_len];                 /
  uint16 length_of_DTLSInnerPlaintext;
};

Mac-then-Encrypt:
struct {
  uint8 marker = tls12_cid;
  uint8 cid_len;
  uint8 content_type = tls12_cid;      \
  uint16 DTLSCiphertext.version;       |  appears on wire 
  uint64 seq_num; // includes epoch    |
  opaque cid[cid_len];                 /
  uint16 length_of_DTLSInnerPlaintext;
  DTLSInnerPlaintext.content;          \
  DTLSInnerPlaintext.real_type;        |  entirety of DTLSInnerPlaintext
  DTLSInnerPlaintext.zeros;            /
};

Encrypt-then-MAC:
struct {
  uint8 marker = tls12_cid;
  uint8 cid_len;
  uint8 content_type = tls12_cid;      \
  uint16 DTLSCiphertext.version;       |  appears on wire 
  uint64 seq_num; // includes epoch    |
  opaque cid[cid_len];                 /
  uint16 iv_length;
  opaque IV[iv_length];
  uint16 enc_content_length;
  opaque enc_content[enc_content_length];
};

(with apologies to Achim for using the 'struct' formulation that cannot
just be copied into the draft)

They all share a commmon prefix: the content-type marker, cid_len, and the
DTLSCiphertext header, and are self-framing (though, of course, the
Mac-then-Encrypt case is mostly "parse from front" except for the "parse
from back" that it inherits from DTLSInnerPlaintext).

Note that for the Encrypt-then-MAC case there are a few more deviations
from the formulation in the -07 -- I put separate length prefixes for IV
and enc_content whereas the -07 has a single "length of (IV +
DTLSCiphertext.enc_content)".  (Also, using DTLSCiphertext.enc_content like
that seems to be self-referential.)  I don't have a strong reasoning for
that offhand, but of course the IV length depends on the cipher in use,
which is a negotiated quantity, and we start using DTLSCiphertext before
both parties' Finished are confirmed, so I erred on the side of paranoia.

Any further thoughts?

Thanks,

Ben

---

From: Achim Kraus <[email-masked]>
Date: Sat, 24 Oct 2020 08:56:08 +0200

Hi Ben,

> ...and thanks for the reminder about how we say so in the text already.

(your example from a previous e-mail)

 > DTLSInnerPlaintext.content = <513 bytes>.

I would feel much more comfortable, if you state,
that you consider now either

1. that example was not compliant to the draft,

or

2. the draft is not clear enough about that.

If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
closed.

best regards
Achim Kraus

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 09:56:35 -0700

Hi Achim,

> If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be

It is neither of those two.

While the party that will be parsing packets that use a given CID value to
identify the connection needs to be able to determine the length from the
byte stream, the other party does not.  Accordingly, when computing the
MAC, there is still malleability in terms of which "interpretation" of the
byte stream was intended by the party computing the MAC.  The party
receiving the packet (and MAC) will only use one interpretation, but the
party generating the MAC could have been deceived into using the other
interpretation.

As I said previously, the CID values are not authenticated until the
handshake completes, so there is a real window where this attack surface is
exposed.  Note that I do not need to present a complete end-to-end attack
that breaks the TLS guarantees in order for us to change the spec -- it is
enough to have shown that the malleability of the cryptographic input
stream is exposed to potential attack.  To leave such behavior in a
published protocol spec would be irresponsible, in effect, publishing an
algorithm with known weaknesses.

Thanks,

Ben

---

From: Achim Kraus <[email-masked]>
Date: Mon, 26 Oct 2020 20:29:04 +0100

Hi Ben,

at least at your point (from the e-mail before)

 > and not have to change it again.

I agree :-).

That will naturally become true, if the RFC gets released.

best regards
Achim

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Oct 2020 17:38:33 -0700

> rather different order than the actual bits on the wire (more below).

Right. I forgot that we also preserved the TLS order of the seqnum.

>   uint16 length_of_DTLSInnerPlaintext;
Mostly.

I would expect the length here to not be DTLSInnerPlaintext but rather the
length field that appears on the wire, as in TLS 1.3. Do you agree with
that? If not, let's discuss. If so, we can talk about the others.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 18:00:29 -0700

> that? If not, let's discuss. If so, we can talk about the others.

Good catch, the length on the wire makes more sense.  (I presume I just
cribbed from the -07 here and didn't think hard enough.)

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Oct 2020 18:07:07 -0700

On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk <[email-masked]> wrote:

> > > more strictly to the "bits on the wire" philosophy would suggest
> having us
> > > use:
> > >
> > > additional_data:
> > > struct {
> cribbed from the -07 here and didn't think hard enough.
>

So I think that the following is right for MtE.

struct {

As for EtM

Encrypt-then-MAC:
struct {

This seems kind of unfortunate in that the 7366 version is much more
faithful to the wire, so I still have to think about this one some more, I
think...

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 18:12:23 -0700

>   DTLSInnerPlaintext.zeros;            /

Sounds good.

> faithful to the wire, so I still have to think about this one some more, I

Yeah, I was not super happy with that one as I wrote it (hence my comment
about it), but I also wasn't around when 7366 was being written, so I don't
have much else to draw on.

-Ben

---

From: Achim Kraus <[email-masked]>
Date: Fri, 30 Oct 2020 13:28:12 +0100

Hi Ekr,

>    opaque enc_content[enc_content_length];

I failed to understand the reasons behind this proposal.

1. Why should the "marker" be added, if the "content_type" is already in
the MAC, and this special MAC is only applied for tls12_cid records.
What is the intended benefit of that?

2. Why should a "uint16 iv_length" be added?
2.a If it should be added, why as "uint16" instead of "uint8"
2.b If it should be added, why in the middle? It's not on the wire and
so I would assume, if at all, to have that at the begin.

best regards
Achim Kraus

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 30 Oct 2020 12:39:03 +0000

>2. Why should a "uint16 iv_length" be added?

To make it explicit which of the bits being hashed is the IV.  This is one of
the flaws of things like OAEP, there are a large number of implicitly-sized
fields controlled by external, unauthenticated parameters, so you can make the
verifier see fields as other, nearby fields (I'm using OAEP as an example
because it's particularly bad, there are so many optional values controlled by
external unauthenticated data that you can have all sorts of fun with it).

>2.b If it should be added, why in the middle? It's not on the wire and so I
>would assume, if at all, to have that at the begin.

It precedes the IV, i.e. the field that it describes.

Peter.

---

From: Achim Kraus <[email-masked]>
Date: Fri, 30 Oct 2020 13:56:17 +0100

Hi Peter,

thanks!

 > It precedes the IV, i.e. the field that it describes.

In other contributions, it's said, that it is also important to keep the
header bytes as they are. With that, the "iv_length" should be ahead
before the header bytes starts.

And I'm still curious about the "uint16" instead of "uint8".

I'm looking forward, when this will get finished :-).

best regards
Achim Kraus