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

[Yoav Nir <[e-mail]>]

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 <https://github.com/tlswg/tls-flags/pull/22>


> On 9 May 2022, at 19:21, Benjamin Kaduk <[e-mail]> 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 <bkaduk=
>> [e-mail]> wrote:
>> 
>>> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
>>>> 
>>>> 
>>>>> On 14 Apr 2022, at 1:51, Benjamin Kaduk <bkaduk=
>>> [e-mail]> 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