[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
From:       Achim Kraus <achimkraus () gmx ! net>
Date:       2020-10-30 12:56:17
Message-ID: 2a8e1752-667c-2211-fe84-5e69d0999280 () gmx ! net
[Download RAW message or body]

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


Am 30.10.20 um 13:39 schrieb Peter Gutmann:
> Achim Kraus <achimkraus@gmx.net> writes:
>
>> 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.
>
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]