[TLS] [Technical Errata Reported] RFC8446 (6152)

The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6152 -- Type: Technical Re

[TLS] Integrity bounds in DTLS

Thanks to some good work from Felix Günther, Marc Fischlin, Christian Janson, and Kenny Paterson we now have a new result to share about the integrity limits in QUIC. There is a long write-up in https://github.com/quicwg/base-drafts/issues/3619, the conclusion of which is that endpoints need to

Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking

On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth wrote: > Section 4.2.10 requires a server receiving early data to behave in ways >>> including (p53): >>> >>> * Ignore the extension and return a regular 1-RTT response. The server >>> then skips past early data by attempting to deprotect received record

Re: [TLS] RFC 8446: Correlating connections with ticket ages

On Thu, Apr 30, 2020 at 2:40 AM Ben Smyth wrote: > Section 4.2.11.1 explains that: > > ...PskIdentity contains an obfuscated version of the ticket age formed by > taking the age in milliseconds and adding the "ticket_age_add"... This > addition prevents passive observers from correlating connecti

[TLS] [Technical Errata Reported] RFC8446 (6151)

The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6151 -- Type: Technical Re

Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking

> > Section 4.2.10 requires a server receiving early data to behave in ways >> including (p53): >> >> * Ignore the extension and return a regular 1-RTT response. The server >> then skips past early data by attempting to deprotect received records >> using the handshake traffic key, discarding reco

[TLS] RFC 8446: Correlating connections with ticket ages

Section 4.2.11.1 explains that: PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add"... This addition prevents passive observers from correlating connections unless tickets are reused. So: Correlations are possib

Re: [TLS] [Technical Errata Reported] RFC8446 (6145)

> Original Text > - > When a PSK is used and early data is allowed for that PSK > > Notes > - > I couldn't find restrictions that forbid early data for a PSK. Explaining > where such restrictions > could exist would be useful. E.g., PSKs might be associated with data that > forbids