On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio wrote:
> I really want the savings on the wire that TLS flags extension provides – and
> so I think it’s really good for the future cTLS but I’m not sure when I get
> to use it in TLS 1.3 negotiation. It goes in the clientHello message, b
I really want the savings on the wire that TLS flags extension provides – and
so I think it’s really good for the future cTLS but I’m not sure when I get to
use it in TLS 1.3 negotiation. It goes in the clientHello message, but how
will I know that the server uses this extension? I envision
On Tuesday, 2 April 2019 18:29:18 CEST Christian Huitema wrote:
> On 4/2/2019 4:42 AM, Hubert Kario wrote:
> > On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
> >> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> > would possibly reduce the size of is ServerHello or
> >
On 4/2/2019 4:42 AM, Hubert Kario wrote:
> On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
>> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> would possibly reduce the size of is ServerHello or
> EncryptedExtensions
Those are messages where we have size pressure.
>>>
On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> > > > would possibly reduce the size of is ServerHello or
> > > > EncryptedExtensions
> > >
> > > Those are messages where we have size pressure.
> >
> > why? in what use case?
>
>
On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> > > would possibly reduce the size of is ServerHello or EncryptedExtensions
> >
> > Those are messages where we have size pressure.
>
> why? in what use case?
QUIC. We have 3600 bytes to play with in that flight. And Certificate is often
On Friday, 29 March 2019 10:23:51 CEST Martin Thomson wrote:
> On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote:
> > what about making sure that the legacy and flags remain in-sync? we will
> > have to send the legacy encoding for many years to come, so only thing it
> > would possibly reduce
I think I only allow the server to set bits that had been set by the client.
A server that supports this extension and also supports at least one
of the flag-type features that use this extension and that were
declared by the ClientHello extension SHALL send this extension with
the
In addition to this, the document would seem to allow a server to set bit k if
the client did not set that bit. (Or more generally, the responder can set bits
the initiator did not set. )
In fitting with the TLS model, I would recommend allowing a responder to set
only bits that the initiator
Hi,
The document only talks about use in ClientHello, ServerHello, and
EncryptedExtensions. I think it should also discuss usage in
CertificateRequest, Certificate from the server, and Certificate from the
client. It should likely be left to the document that specifies a specific
feature to
On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote:
> what about making sure that the legacy and flags remain in-sync? we will have
> to send the legacy encoding for many years to come, so only thing it would
> possibly reduce the size of is ServerHello or EncryptedExtensions
Those are messages
On Wednesday, 27 March 2019 14:42:49 CET Martin Thomson wrote:
> Why not go all in - make this a byte string and start from 0x80 in the first
> byte. When we define the 9th flag, we add another byte. Then you have up
> to 2040 flags (though it might pay to split the space before that).
>
>
On Wed, Mar 27, 2019, at 14:47, Eric Rescorla wrote:
> Of course, at some point it starts to make sense to do RLE.
I considered that, but I don't see this being sufficiently sparsely populated.
___
TLS mailing list
TLS@ietf.org
Of course, at some point it starts to make sense to do RLE.
-Ekr
On Wed, Mar 27, 2019 at 6:43 AM Martin Thomson wrote:
> Why not go all in - make this a byte string and start from 0x80 in the
> first byte. When we define the 9th flag, we add another byte. Then you
> have up to 2040 flags
> On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor wrote:
>
> On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
>> Right. What about defining a set of extensions (e.g., 2 extensions) of
>> flags as:
>>
>> struct {
>> uint64 flags;
>> } Flags;
>
> If we're going to be doing this
On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> Right. What about defining a set of extensions (e.g., 2 extensions) of
> flags as:
>
> struct {
>uint64 flags;
> } Flags;
If we're going to be doing this kind of bit-shaving, this is the way to
go, starting with a single
On Tue, 2019-03-26 at 10:49 +0100, Yoav Nir wrote:
> > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos
> > wrote:
> >
> > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> > > > On 26 Mar 2019, at 9:06, Martin Thomson
> > > > wrote:
> > > >
> > > > This needs more space for each flag. 8
On Tue, Mar 26, 2019 at 04:38:11PM +0100, Yoav Nir wrote:
>
>
> > On 26 Mar 2019, at 14:45, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi. Today at the TLS meeting, there was a discussion at the mic about
> >> 1-bit
> >> extensions that only serve
> On 26 Mar 2019, at 18:49, Hubert Kario wrote:
>
> On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
>>> On 26 Mar 2019, at 14:45, Hubert Kario wrote:
>>>
>>> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
Hi. Today at the TLS meeting, there was a discussion at the mic
On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
> > On 26 Mar 2019, at 14:45, Hubert Kario wrote:
> >
> > On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> >> Hi. Today at the TLS meeting, there was a discussion at the mic about
> >> 1-bit extensions that only serve to indicate
> On 26 Mar 2019, at 14:45, Hubert Kario wrote:
>
> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
>> Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
>> extensions that only serve to indicate support for an optional feature. EKR
>> commented that such
On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
> Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
> extensions that only serve to indicate support for an optional feature. EKR
> commented that such extensions take 4 bytes each and that maybe we need to
> replace
> On 26 Mar 2019, at 12:05, Peter Gutmann wrote:
>
> Yoav Nir writes:
>
>> Are we really worried that we’re going to have more than 255 optional
>> features for TLS?
>
> You're new here aren't you?
>
No, but I’m looking at the TLS registries (
Yoav Nir writes:
>Are we really worried that we’re going to have more than 255 optional
>features for TLS?
You're new here aren't you?
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos wrote:
>
> On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
>>> On 26 Mar 2019, at 9:06, Martin Thomson wrote:
>>>
>>> This needs more space for each flag. 8 bits is a pretty small
>>> space. If you are concerned with the size of the
On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> > On 26 Mar 2019, at 9:06, Martin Thomson wrote:
> >
> > This needs more space for each flag. 8 bits is a pretty small
> > space. If you are concerned with the size of the result, we have
> > some variable-length integer encodings you could
On Tue, 26 Mar 2019 at 09:12, Yoav Nir wrote:
> Are we really worried that we’re going to have more than 255 optional
> features for TLS?
Probably not; but what about an optional feature that needs 3 bits? Is
it better to kick them off into 4 bytes?
-tom
> On 26 Mar 2019, at 9:06, Martin Thomson wrote:
>
> This needs more space for each flag. 8 bits is a pretty small space. If you
> are concerned with the size of the result, we have some variable-length
> integer encodings you could try.
Ah, the beautiful variable length encodings. Like:
>This needs more space for each flag. 8 bits is a pretty small space. If
> you are concerned with the size of the result, we have some variable-length
> integer encodings you could try.
Enh, just take 16 bits. Nobody will ever need more than 640k
>
> *From: *Yoav Nir
> *Date: *Monday, March 25, 2019 at 10:10 PM
> *To: *"tls@ietf.org"
> *Subject: *[TLS] A flags extension
>
>
> Hi. Today at the TLS meeting, there was a discussion at the mic about
> 1-bit extensions that only serve to ind
That was FAST.
Looks good.
From: Yoav Nir
Date: Monday, March 25, 2019 at 10:10 PM
To: "tls@ietf.org"
Subject: [TLS] A flags extension
Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
extensions that only serve to indicate support for an optional fe
Hi. Today at the TLS meeting, there was a discussion at the mic about 1-bit
extensions that only serve to indicate support for an optional feature. EKR
commented that such extensions take 4 bytes each and that maybe we need to
replace them with a flags extension.
So I threw together a quick
32 matches
Mail list logo
