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 servers
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
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.
-Original Message-
From: TLS On Behalf Of Christopher Wood
Sent: Tuesday, June 12, 2018 1:41 PM
To:
Su
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 and
On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
christopherwoo...@gmail.com> 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 (section 5.4) can be used, rather than sending
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 (sect
On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <
christopherwoo...@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin
> wrote:
> >
> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
> christopherwoo...@gmail.com> wrote:
> >>
> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekrit
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, D
You could use the existing Certificate padding mechanism. Which mechanism?!
The one in this paragraph:
For maximum compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-ent
I'm emerging from lurking to just say this: I think this is a fantastic
idea, and thank you for doing it.
FWIW and IMO, you're better off summarizing the codepoints you are using
and planning to use on a wiki somewhere instead of in registries, given the
timescales and the lifetime of these codepoi
10 matches
Mail list logo
