On 02/19/2018 04:14 AM, Martin Thomson wrote:
> (+tls@)
> This is a good question Jim and one that I thought through during
> implementation, but failed to capture in the doc.
> Basically, there is no way to validate the extension if the client
> includes an unknown version of TLS or an extension that it doesn't
> understand.  A client can know because it should understand the
> protocol as negotiated.
> The text currently says "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"  I think that we should add "A
> server MUST NOT enforce this restriction; a client might advertise a
> higher limit that is enabled by an extension or version the server
> does not understand."
> Does that make sense?

Mostly.  I am not sure that that exact phrasing is great, though, as we
do want the server to enforce the restriction *as written*, i.e., taking
into account that the client may know better than the server if a newer
version and/or extension is in use.  So, maybe something like "Receiving
a larger value is not necessarily cause for a server to abort the
handshake, given this possibility".


> On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad <i...@augustcellars.com> wrote:
>> I was looking at this document relative to a specific question for Kathleen,
>> and I had one thing that I would like you to look at and see if you think it
>> is clear enough.
>> I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3.   It sends
>> a hello w/ and extension value of 2^14+1.  It is not completely clear to me
>> that the server should accept this as a legal value and compute the min of
>> it and the maximum 1.2 value as the value to use when sending messages to
>> the client rather than producing an error message because the value is too
>> large.
>> Jim
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

TLS mailing list

Reply via email to