[TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-tls-tls13-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[TLS] Spencer Dawkins' No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-tls-record-limit-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[TLS] Spencer Dawkins' No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-tls-ecdhe-psk-aead-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

For what it's worth, On Thu, Jan 7, 2021 at 9:15 AM Mikkel Fahnøe Jørgensen wrote: > > > On 7 Jan 2021, at 07.26, Benjamin Kaduk wrote: > > It seems like only QUIC internals would have to change, not TLS internals? > > My expectation is roughly that, if we were to compare the work needed to go