[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt
From:       Yoav Nir <ynir.ietf () gmail ! com>
Date:       2019-08-14 17:21:17
Message-ID: 2A9AE6DD-EE01-4DE6-977D-5A8847FB6BE4 () gmail ! com
[Download RAW message or body]



> On 12 Aug 2019, at 21:25, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> > 
> > Title           : A Flags Extension for TLS 1.3
> > Author          : Yoav Nir
> > 	Filename        : draft-ietf-tls-tlsflags-00.txt
> > 	Pages           : 6
> > 	Date            : 2019-08-12
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00
> 
> Two things:
> 
> 
> 1) uint8 flags<0..31>;
> 
> That adds an extra byte that is not technically necressary (because
> extensions have lengths anyway) and limits number of flags to 248
> (which might be enough).

I hope 248 is enough...

> And I do not think the length of flags field can be 0 (if it would
> be, one could just omit the extension).

There could be a future flag that the server sends unsolicited \
(client-auth-required?).  It's important for the client to show support for the flags \
extension to make sure that it understands what the server is sending.

Depends on how we define the semantics in the draft.

> 
> 
> 2) I think the bit order within octets should be reversed
> 
> That is, pack flags so that 0 is LSB of first octet, 7 is MSB of
> first octet, 8 is LSB of second octet and so on.
> 
> Then one can read status flags by index with code like:
> 
> fn read_flag(flags: &[u8], idx: usize) -> bool
> {
> *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0
> }
> 
> (That code will also happily handle out-of-array flags by reading
> them as false.)

Makes sense. I get caught up in visualizing computer memory and protocol messages as \
a string of bits written from left to right.

> -Ilari
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[prev in list] [next in list] [prev in thread] [next in thread]