On Friday, 25 January 2019 17:23:22 CET David Benjamin wrote:
> On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson <m...@lowentropy.net> wrote:
> > On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote:
> > > > while record_size_limit extension sends just one value, it does
> > > > specifically
> > > > allow the client to advertise higher values than the protocol versions
> >
> > or
> >
> > > > extensions would indicate
> > > >
> > > > I wonder if sending such values shouldn't be part of GREASE behaviour,
> > > > even if
> > > > it wouldn't use GREASE values...
> > >
> > > I think that should be sorted out in a separate document. This one's
> > > been
> > > sitting around for a while as it is, and record_size_limit doesn't have
> >
> > an
> >
> > > RFC to cite yet. :-)
> >
> > I'm in two minds about this. On the one hand, we don't need any actual
> > machinery here, so why do anything? On the other hand, it's just a note
> > that this is possible, and adding that sort of note is easy.
> >
> > > The record_size_limit extension {{!RFC8449}} includes a value that can
> >
> > be greased by endpoints that don't place constraints on their record size.
> > Advertising values larger than the protocol supports is permitted and has
> > no effect on the behavior of a compliant peer.
>
> I don't feel very strongly either way, though it is odd that it basically
> contradicts the sender's rules in RFC 8449.
>
> Higher values are currently reserved for future
> versions of the protocol that may allow larger records; an endpoint
> MUST NOT send a value higher than the protocol-defined maximum record
> size unless explicitly allowed by such a future version or extension.
> A server MUST NOT enforce this restriction; a client might advertise
> a higher limit that is enabled by an extension or version the server
>
> It does say "unless explicitly allowed by such a future version or
> extension", so this is basically blanket overruling that sentence a few
> months after publication. (But overruling it isn't entirely wrong, given
> the current text imposes a future-proofing receiver rule that the sender is
> forbidden from checking.)
we can claim that GREASE cipher suites are signalling cipher suite value for
this purpose ("unless explicitly allowed by (...) extension")...
but my point was that to ensure future-proofing that "MUST NOT enforce" is
much more important to keep flexible that to be strict ("MUST NOT send")
*unless* the idea was to later create an RFC that just increases the maximum
record sizes without introducing any additional extension to signal support
for it – which I don't think would be safe to do
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
