On Thu, Nov 07, 2019 at 11:18:28AM +1100, Martin Thomson wrote:
> > Omitting the length field MUST only be used for data which is
> > protected with one of the application_traffic_secret values, and
> > not for messages protected with either [sender]_handshake_traffic_sercret
> > or [sender]_early_
I believe DTLS is wrong. ChaCha20 is little-endian with the counter going
first and the nonce afterwards. See also RFC 8439, section 2.3, where the
block count is placed before the nonce.
https://tools.ietf.org/html/rfc8439#section-2.3
(Well, "wrong". Both are perfectly well-defined, but the DTLS
> Omitting the length field MUST only be used for data which is protected with
> one of the application_traffic_secret values, and not for messages protected
> with either [sender]_handshake_traffic_sercret or
> [sender]_early_traffic_secret values. When using an
> [sender]_application_traffic
It was pointed out to me that the header protection in QUIC and DTLS 1.3 are
different in a non-useful way:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#hp-chacha says that the
first 4 bytes of the sample are the counter, i.e., `counter[4] || nonce[12]`.
DTLS 1.3 says that the last
One belated comment, editorial in nature: The draft now uses the term "packet"
in quite a few places. The older text uses datagram. I suggest that this be
normalized before the publication request is made.
On Tue, Nov 5, 2019, at 03:08, Sean Turner wrote:
> This WGLC has concluded. I will com
Hi Rob,
The situation we are trying to prevent is when both the client and server
think they have completed a handshake with each other, but disagree on what
happened.
In this case, for example, the client might have used a PSK importer, but
the server might believe the client has used a vanilla P
