Hiya,
Was just adding code for this and I noticed that the draft says
a server: "SHOULD pad the Certificate message, via padding at
the record layer, such that its length equals the size of the
largest possible Certificate (message) covered by the same ESNI
key."
I think that ought also mention
On 13/12/2018 13:10, Stephen Farrell wrote:
>
> Hiya,
>
> Was just adding code for this and I noticed that the draft says
> a server: "SHOULD pad the Certificate message, via padding at
> the record layer, such that its length equals the size of the
> largest possible Certificate (message)
On 13/12/2018 13:36, Matt Caswell wrote:
> You can set a padding callback using SSL_CTX_set_record_padding_callback() (or
> SSL_set_record_padding_callback()). The callback can determine whether it is
> padding a handshake message by examining its "type" parameter, and which
> message
> it is
On Thu, Dec 13, 2018 at 5:10 AM Stephen Farrell
wrote:
>
> Hiya,
>
> Was just adding code for this and I noticed that the draft says
> a server: "SHOULD pad the Certificate message, via padding at
> the record layer, such that its length equals the size of the
> largest possible Certificate
> On Dec 13, 2018, at 8:10 AM, Stephen Farrell
> wrote:
>
> Was just adding code for this and I noticed that the draft says
> a server: "SHOULD pad the Certificate message, via padding at
> the record layer, such that its length equals the size of the
> largest possible Certificate (message)
On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
> Random padding does poorly with repeated trials. So, for instance,
> if I get to observe a large number of requests from the same client
> to the same server, you can gradually infer the length of the cert
> chain.
Yes, I was aware
On Thu, Dec 13, 2018 at 7:28 AM Viktor Dukhovni
wrote:
> > On Dec 13, 2018, at 8:10 AM, Stephen Farrell
> wrote:
> >
> > Was just adding code for this and I noticed that the draft says
> > a server: "SHOULD pad the Certificate message, via padding at
> > the record layer, such that its length
Hiya,
On 13/12/2018 15:09, Eric Rescorla wrote:
> Sure. Send a PR.
Just did that adding in CerticateVerify. [1]
That PR does also take out the "longest cert length" aspect
of the current text - I reckon Viktor's right that one might
not know that, and it could be error prone as new certs get
On Thu, Dec 13, 2018 at 11:02:54AM -0500, Viktor Dukhovni wrote:
> On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
>
> > Random padding does poorly with repeated trials. So, for instance,
> > if I get to observe a large number of requests from the same client
> > to the same
On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote:
> Hi folks,
>
> We have one more update for you all on TLS 1.3 deployment issues. Over the
> course of deploying TLS 1.3 to Google servers, we found that JDK 11
> unfortunately implemented TLS 1.3 incorrectly. On resumption, it
On Thu, Dec 13, 2018 at 8:03 AM Viktor Dukhovni
wrote:
> On Thu, Dec 13, 2018 at 07:51:17AM -0800, Eric Rescorla wrote:
>
> > Random padding does poorly with repeated trials. So, for instance,
> > if I get to observe a large number of requests from the same client
> > to the same server, you can
On Thursday, 13 December 2018 18:04:12 CET David Benjamin wrote:
> On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario wrote:
> > On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote:
> > > Hi folks,
> > >
> > > We have one more update for you all on TLS 1.3 deployment issues. Over
> > >
On Thu, Dec 13, 2018 at 10:54 AM Hubert Kario wrote:
> On Wednesday, 12 December 2018 23:21:43 CET David Benjamin wrote:
> > Hi folks,
> >
> > We have one more update for you all on TLS 1.3 deployment issues. Over
> the
> > course of deploying TLS 1.3 to Google servers, we found that JDK 11
> >
13 matches
Mail list logo
