Re: [TLS] tlsflags and "responses"

[Yoav Nir]

I have just submitted PR #20 to allow unacknowledged flags.  It is a rewrite of 
section 3 (rules)

https://github.com/tlswg/tls-flags/pull/20 


It still requires that the flag extension not be sent when empty.  Let me know 
if that’s a problem as well.

Yoav

> On 21 Feb 2022, at 2:21, Martin Thomson  wrote:
> 
> I missed this text in draft-ietf-tls-tlsflags:
> 
>   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 intersection of the flags it supports with the flags declared by
>   the client.  
> 
> While sloppy on my part [1], I want to make it clear that this is a 
> show-stopper for me. Requiring an echo prevents a flag extension from 
> attaching semantics to a "response".
> 
> I agree with Ilari's earlier point that these should work just like 
> extensions.  If the server has no need to echo a flag, it should not be 
> required to do that.  That allows the flag value in a "response" to carry 
> semantics.
> 
> Cheers,
> Martin
> 
> [1] I missed this in the second WGLC, though in my defense, I don't think the 
> resolution and changes resulting from the first WGLC were very clearly 
> communicated.
> 
> ___
> 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

Re: [TLS] tlsflags and "responses"

[Eric Rescorla]

Precisely.

On Mon, Feb 21, 2022 at 2:42 PM Martin Thomson  wrote:

> On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote:
> > I think (but don't have a solid recollection) that this may have
> > stemmed from a desire for the sender to know if the recipient supports
> > flags at all.  But thinking about it now (and as Ekr's response
> > suggests), so long as we don't allocate flags for existing extensions,
> > there is not much useful to do with that information in cases where the
> > extension semantics of the flag(s) in question don't require a response.
>
> Wouldn't it be possible to send the extension with an empty set of flags?
> We don't permit trailing zero bytes, but a zero-length sequence indicates
> support without signaling for any specific flag.
>
> ___
> 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

Re: [TLS] tlsflags and "responses"

[Martin Thomson]

On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote:
> I think (but don't have a solid recollection) that this may have 
> stemmed from a desire for the sender to know if the recipient supports 
> flags at all.  But thinking about it now (and as Ekr's response 
> suggests), so long as we don't allocate flags for existing extensions, 
> there is not much useful to do with that information in cases where the 
> extension semantics of the flag(s) in question don't require a response.

Wouldn't it be possible to send the extension with an empty set of flags?  We 
don't permit trailing zero bytes, but a zero-length sequence indicates support 
without signaling for any specific flag.

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

Re: [TLS] tlsflags and "responses"

[Benjamin Kaduk]

On Mon, Feb 21, 2022 at 11:21:38AM +1100, Martin Thomson wrote:
> I missed this text in draft-ietf-tls-tlsflags:
> 
>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 intersection of the flags it supports with the flags declared by
>the client.  
> 
> While sloppy on my part [1], I want to make it clear that this is a 
> show-stopper for me. Requiring an echo prevents a flag extension from 
> attaching semantics to a "response".
> 
> I agree with Ilari's earlier point that these should work just like 
> extensions.  If the server has no need to echo a flag, it should not be 
> required to do that.  That allows the flag value in a "response" to carry 
> semantics.

I think (but don't have a solid recollection) that this may have stemmed from a 
desire for the sender to know if the recipient supports flags at all.  But 
thinking about it now (and as Ekr's response suggests), so long as we don't 
allocate flags for existing extensions, there is not much useful to do with 
that information in cases where the extension semantics of the flag(s) in 
question don't require a response.

-Ben

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