Got it — thanks for the clarification! I agree with your conclusion assuming we
do not want to make an incompatible wire format change. However, if we’re
willing to budge on that, I think it’s worth including. I’m curious to hear
what others think.
Best,
Chris
On Jun 12, 2018, 11:48 AM -0700,
On Tue, Jun 12, 2018 at 11:32 AM David Benjamin wrote:
>
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood
> wrote:
>>
>> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote:
>> >
>> > Since the Certificate message is sent in an encrypted record, the normal
>> > record padding mechanism
On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote:
>
> Since the Certificate message is sent in an encrypted record, the normal
> record padding mechanism (section 5.4) can be used, rather than sending the
> padding as actual handshake data.
Of course, and that requires padding on the fly
Hi folks,
In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21)
extension is restricted to the CH and no other handshake messages.
Another plausible spot for this extension is in the Certificate
message. Specifically, although we're encrypting this message, we may
not want to reveal its
Hi all,
Now that TLS 1.3 is about done, perhaps it is time to reflect on the
ossification problems.
TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
we had problems. Widespread non-compliant
