Re: [TLS] Can flags be responded to with an extension?

[Yoav Nir]

Hi.

Here’s a PR to codify that an extension with content is NOT a proper response 
to a flag.  I’m not merging this for now. It’s proposed text to gauge WG 
consensus.

Yoav

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



> On 9 May 2022, at 19:21, Benjamin Kaduk  wrote:
> 
> Hi Ekr,
> 
> On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote:
>> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk > 40akamai@dmarc.ietf.org> wrote:
>> 
>>> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
 
 
> On 14 Apr 2022, at 1:51, Benjamin Kaduk >> 40akamai@dmarc.ietf.org> wrote:
> 
> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
>> Consider the case where the client wants to offer some capability that
>> the server then responds to with real data, rather than just an
>> acknowledgement.
>> 
>> For instance, supposing the SCT extension from RFC 6962 did not exist,
>> the client would want to indicate support in CH and the server would
>> send the SCT in CERT, but this extension would need to be non-empty
>> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
>> uncelar on this point (unless I'm missing it) but I think we
>> should explicitly allow it.
> 
> In my head this was already disallowed. I couldn't swear to whether
> we actually talked about it previously or not, though.
 
 I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
>>> room). In my head it’s also disallowed. In the text, it’s not explicitly
>>> disallowed, but the text does talk about response flags that are in flag
>>> extensions, not about responses that are in other extensions or other
>>> messages. So implicitly disallowed?
>>> 
>>> I think the description in the abstract of the target class of extension as
>>> those "that carry no interesting information except the 1-bit indication
>>> that a
>>> certain optional feature is supported" also implicitly disallows response
>>> bodies.
>>> 
>> 
>> Hmm... I don't think this is really the right approach at this stage.
>> 
>> The situation here is that the explicit text is ambiguous. If this were
>> already an RFC, we would need to try to determine what it meant so that we
>> could agree how implementations ought to be behaving. In that case, yes, we
>> would look at this kind of language to attempt to resolve the ambiguity.
>> 
>> However, this is not an RFC and so our task is to make the specification as
>> unambiguous as possible. At this stage, we should be asking what the
>> *right* answer is, not what the one that most closely matches the current
>> ambiguous text. My argument is that the right answer is the one that most
> 
> Yes. You've convinced me that we need to be (more) explicit one way or the 
> other.
> 
> Please treat my remark as a contribution to enumerating places in the document
> that would need to change if we were to allow responses outside of the flags
> extension.
> 
> -Ben
> 
>> closely embodies the broader goal of saving bandwidth for low-information
>> signals, in this case the signal that the client could process a given
>> server extension. So, yes, the client's extension contains no interesting
>> information but the server's does, which, I think, is consistent with this
>> text, even if, arguably, it's not the better reading.
>> 
>> I can certainly see arguments against forbidding this practice for
>> technical reasons (e.g., simplicity), but, again, then the specification
>> should just say so.
>> 
>> -Ekr

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

Hi Ekr,

On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote:
> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk  40akamai@dmarc.ietf.org> wrote:
> 
> > On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> > >
> > >
> > > > On 14 Apr 2022, at 1:51, Benjamin Kaduk  > 40akamai@dmarc.ietf.org> wrote:
> > > >
> > > > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> > > >> Consider the case where the client wants to offer some capability that
> > > >> the server then responds to with real data, rather than just an
> > > >> acknowledgement.
> > > >>
> > > >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> > > >> the client would want to indicate support in CH and the server would
> > > >> send the SCT in CERT, but this extension would need to be non-empty
> > > >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> > > >> uncelar on this point (unless I'm missing it) but I think we
> > > >> should explicitly allow it.
> > > >
> > > > In my head this was already disallowed.  I couldn't swear to whether
> > > > we actually talked about it previously or not, though.
> > >
> > > I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
> > room).  In my head it’s also disallowed.  In the text, it’s not explicitly
> > disallowed, but the text does talk about response flags that are in flag
> > extensions, not about responses that are in other extensions or other
> > messages.  So implicitly disallowed?
> >
> > I think the description in the abstract of the target class of extension as
> > those "that carry no interesting information except the 1-bit indication
> > that a
> > certain optional feature is supported" also implicitly disallows response
> > bodies.
> >
> 
> Hmm... I don't think this is really the right approach at this stage.
> 
> The situation here is that the explicit text is ambiguous. If this were
> already an RFC, we would need to try to determine what it meant so that we
> could agree how implementations ought to be behaving. In that case, yes, we
> would look at this kind of language to attempt to resolve the ambiguity.
> 
> However, this is not an RFC and so our task is to make the specification as
> unambiguous as possible. At this stage, we should be asking what the
> *right* answer is, not what the one that most closely matches the current
> ambiguous text. My argument is that the right answer is the one that most

Yes.  You've convinced me that we need to be (more) explicit one way or the 
other.

Please treat my remark as a contribution to enumerating places in the document
that would need to change if we were to allow responses outside of the flags
extension.

-Ben

> closely embodies the broader goal of saving bandwidth for low-information
> signals, in this case the signal that the client could process a given
> server extension. So, yes, the client's extension contains no interesting
> information but the server's does, which, I think, is consistent with this
> text, even if, arguably, it's not the better reading.
> 
> I can certainly see arguments against forbidding this practice for
> technical reasons (e.g., simplicity), but, again, then the specification
> should just say so.
> 
> -Ekr

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

Re: [TLS] Can flags be responded to with an extension?

[Eric Rescorla]

On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk  wrote:

> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> >
> >
> > > On 14 Apr 2022, at 1:51, Benjamin Kaduk  40akamai@dmarc.ietf.org> wrote:
> > >
> > > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> > >> Consider the case where the client wants to offer some capability that
> > >> the server then responds to with real data, rather than just an
> > >> acknowledgement.
> > >>
> > >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> > >> the client would want to indicate support in CH and the server would
> > >> send the SCT in CERT, but this extension would need to be non-empty
> > >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> > >> uncelar on this point (unless I'm missing it) but I think we
> > >> should explicitly allow it.
> > >
> > > In my head this was already disallowed.  I couldn't swear to whether
> > > we actually talked about it previously or not, though.
> >
> > I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
> room).  In my head it’s also disallowed.  In the text, it’s not explicitly
> disallowed, but the text does talk about response flags that are in flag
> extensions, not about responses that are in other extensions or other
> messages.  So implicitly disallowed?
>
> I think the description in the abstract of the target class of extension as
> those "that carry no interesting information except the 1-bit indication
> that a
> certain optional feature is supported" also implicitly disallows response
> bodies.
>

Hmm... I don't think this is really the right approach at this stage.

The situation here is that the explicit text is ambiguous. If this were
already an RFC, we would need to try to determine what it meant so that we
could agree how implementations ought to be behaving. In that case, yes, we
would look at this kind of language to attempt to resolve the ambiguity.

However, this is not an RFC and so our task is to make the specification as
unambiguous as possible. At this stage, we should be asking what the
*right* answer is, not what the one that most closely matches the current
ambiguous text. My argument is that the right answer is the one that most
closely embodies the broader goal of saving bandwidth for low-information
signals, in this case the signal that the client could process a given
server extension. So, yes, the client's extension contains no interesting
information but the server's does, which, I think, is consistent with this
text, even if, arguably, it's not the better reading.

I can certainly see arguments against forbidding this practice for
technical reasons (e.g., simplicity), but, again, then the specification
should just say so.

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> 
> 
> > On 14 Apr 2022, at 1:51, Benjamin Kaduk 
> >  wrote:
> > 
> > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> >> Consider the case where the client wants to offer some capability that
> >> the server then responds to with real data, rather than just an
> >> acknowledgement.
> >> 
> >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> >> the client would want to indicate support in CH and the server would
> >> send the SCT in CERT, but this extension would need to be non-empty
> >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> >> uncelar on this point (unless I'm missing it) but I think we
> >> should explicitly allow it.
> > 
> > In my head this was already disallowed.  I couldn't swear to whether
> > we actually talked about it previously or not, though.
> 
> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the 
> room).  In my head it’s also disallowed.  In the text, it’s not explicitly 
> disallowed, but the text does talk about response flags that are in flag 
> extensions, not about responses that are in other extensions or other 
> messages.  So implicitly disallowed?

I think the description in the abstract of the target class of extension as
those "that carry no interesting information except the 1-bit indication that a
certain optional feature is supported" also implicitly disallows response
bodies.

-Ben

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

Re: [TLS] Can flags be responded to with an extension?

[Eric Rescorla]

Well, sounds like it's an open issue

My view is that it should be explicitly allowed, but I don't feel that
strongly about it. I do, however, feel strongly that the draft should say
explicitly one way or the other.

On Mon, May 9, 2022 at 8:10 AM Yoav Nir  wrote:

>
>
> > On 14 Apr 2022, at 1:51, Benjamin Kaduk  40akamai@dmarc.ietf.org> wrote:
> >
> > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> >> Consider the case where the client wants to offer some capability that
> >> the server then responds to with real data, rather than just an
> >> acknowledgement.
> >>
> >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> >> the client would want to indicate support in CH and the server would
> >> send the SCT in CERT, but this extension would need to be non-empty
> >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> >> uncelar on this point (unless I'm missing it) but I think we
> >> should explicitly allow it.
> >
> > In my head this was already disallowed.  I couldn't swear to whether
> > we actually talked about it previously or not, though.
>
> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
> room).  In my head it’s also disallowed.  In the text, it’s not explicitly
> disallowed, but the text does talk about response flags that are in flag
> extensions, not about responses that are in other extensions or other
> messages.  So implicitly disallowed?
>
> Yoav
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Can flags be responded to with an extension?

[Yoav Nir]

> On 14 Apr 2022, at 1:51, Benjamin Kaduk  
> wrote:
> 
> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
>> Consider the case where the client wants to offer some capability that
>> the server then responds to with real data, rather than just an
>> acknowledgement.
>> 
>> For instance, supposing the SCT extension from RFC 6962 did not exist,
>> the client would want to indicate support in CH and the server would
>> send the SCT in CERT, but this extension would need to be non-empty
>> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
>> uncelar on this point (unless I'm missing it) but I think we
>> should explicitly allow it.
> 
> In my head this was already disallowed.  I couldn't swear to whether
> we actually talked about it previously or not, though.

I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the room).  
In my head it’s also disallowed.  In the text, it’s not explicitly disallowed, 
but the text does talk about response flags that are in flag extensions, not 
about responses that are in other extensions or other messages.  So implicitly 
disallowed?

Yoav

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

Re: [TLS] Can flags be responded to with an extension?

[Eric Rescorla]

On Wed, Apr 13, 2022 at 3:51 PM Benjamin Kaduk  wrote:

> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> > Consider the case where the client wants to offer some capability that
> > the server then responds to with real data, rather than just an
> > acknowledgement.
> >
> > For instance, supposing the SCT extension from RFC 6962 did not exist,
> > the client would want to indicate support in CH and the server would
> > send the SCT in CERT, but this extension would need to be non-empty
> > and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> > uncelar on this point (unless I'm missing it) but I think we
> > should explicitly allow it.
>
> In my head this was already disallowed.  I couldn't swear to whether
> we actually talked about it previously or not, though.
>

That's certainly possible, though I couldn't find text one way or another

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> Consider the case where the client wants to offer some capability that
> the server then responds to with real data, rather than just an
> acknowledgement.
> 
> For instance, supposing the SCT extension from RFC 6962 did not exist,
> the client would want to indicate support in CH and the server would
> send the SCT in CERT, but this extension would need to be non-empty
> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> uncelar on this point (unless I'm missing it) but I think we
> should explicitly allow it.

In my head this was already disallowed.  I couldn't swear to whether
we actually talked about it previously or not, though.

-Ben

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

Re: [TLS] Can flags be responded to with an extension?

[Ilari Liusvaara]

On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> Consider the case where the client wants to offer some capability that
> the server then responds to with real data, rather than just an
> acknowledgement.
> 
> For instance, supposing the SCT extension from RFC 6962 did not exist,
> the client would want to indicate support in CH and the server would
> send the SCT in CERT, but this extension would need to be non-empty
> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> uncelar on this point (unless I'm missing it) but I think we
> should explicitly allow it.
> 
> Thoughts?

There is actually precedent for stuff like this (even if it is a nasty
hack): The TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite. The reply to
that is the renegotiation_info extension, even if that extension was
not present in the client hello.

However, that one is not exactly pleasant to implement in TLS library,
Looking at source of my TLS library, it has some magic hacks in order
to support parsing client hello with TLS_EMPTY_RENEGOTIATION_INFO_SCSV.



-Ilari

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

[TLS] Can flags be responded to with an extension?

[Eric Rescorla]

Consider the case where the client wants to offer some capability that
the server then responds to with real data, rather than just an
acknowledgement.

For instance, supposing the SCT extension from RFC 6962 did not exist,
the client would want to indicate support in CH and the server would
send the SCT in CERT, but this extension would need to be non-empty
and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
uncelar on this point (unless I'm missing it) but I think we
should explicitly allow it.

Thoughts?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls