On Wed, Feb 13, 2019 at 11:37 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert K
On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> > > > On Wednesday, 13 February 2019 15:39:03 CE
On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > > > I'n not sure I understand your question,
On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > > I'n not sure I understand your question, but I'll try to answer what I
> > > think it says.
> > >
> > >
On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > > > I concur with what I take to be MT's posit
On Wed, Feb 13, 2019 at 04:39:49PM +0100, Hubert Kario wrote:
> On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
>
> > To my knowledge, there was never a WG discussion about this exact question,
> > so we only have the spec to guide us. Were we pre-publication I would have
> > advo
On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > > I concur with what I take to be MT's position here:
> > >
> > > 1. The client is clearly prohibited fro
On Mon, Feb 11, 2019 at 10:43:39AM +1100, Martin Thomson wrote:
> On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
>
> > > If we require or allow checking - and I think that we should definitely
> > > allow a check - the details of the conditions under which a check might
> > > fail aren't compl
On Wed, Feb 13, 2019 at 06:39:03AM -0800, Eric Rescorla wrote:
> On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
>
> > you are not suggesting that which value will be used (from first or second
> > CH), or if the connection will be aborted, to be implementation dependant
> > *by design* , do
On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote:
> On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> > I concur with what I take to be MT's position here:
> >
> > 1. The client is clearly prohibited from changing most elements of the CH
> > (except for listed exceptions).
> >
On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote:
> I concur with what I take to be MT's position here:
>
> 1. The client is clearly prohibited from changing most elements of the CH
> (except for listed exceptions).
> 2. It's reasonable to check for and fail the handshake on any spe
I concur with what I take to be MT's position here:
1. The client is clearly prohibited from changing most elements of the CH
(except for listed exceptions).
2. It's reasonable to check for and fail the handshake on any spec
violation except those where checking is explicitly forbidden (e.g., Must
On Monday, 11 February 2019 00:43:39 CET Martin Thomson wrote:
> On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> > the cookie can be up to 2^16 bytes long, even if client sends all 50
> > extensions and spaces them with unknown extensions between, that's at most
> > 20 bytes per extension = 10
On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> given need for GREASE and two dozen flags across OpenSSL history for
> workarounds for bugs in different implementations, the lesson seems to be
> that
> the receiving side should be as strict as it can (within protocol confines)
> or
> we r
On Friday, 8 February 2019 04:31:18 CET Martin Thomson wrote:
> TLS 1.3 is pretty firm about what you can change in a second ClientHello.
> It lists a small set of allowed changes to extensions (cookie, PSK binder,
> key shares, early data, and padding). For the rest it says that nothing
> can ch
TLS 1.3 is pretty firm about what you can change in a second ClientHello. It
lists a small set of allowed changes to extensions (cookie, PSK binder, key
shares, early data, and padding). For the rest it says that nothing can
change. So clearly a client is in the wrong if it changes, adds, or
16 matches
Mail list logo
