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 <bka...@akamai.com> 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= >> 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 <bkaduk= >>> 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
