[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)
From:       Martin Vigoureux <martin.vigoureux () nokia ! com>
Date:       2018-04-05 13:35:41
Message-ID: 237e9364-6b9a-28eb-da0d-5e032cae86eb () nokia ! com
[Download RAW message or body]

Martin,

thanks for the quick reply. That clarifies.
I asked because the paragraph above that sentence somehow already 
implies that clients may continue advertise the "max_fragment_length" 
(at least that's ow I understand it), so I felt that this sentence must 
mean something different.

-m

Le 2018-04-05 à 12:28, Martin Thomson a écrit  :
> On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux
> <martin.vigoureux@nokia.com> wrote:
>> Hello, I'm not a TLS expert so please disregard if this is irrelevant.
>> Document says:
>>     Clients that depend on having a small record size MAY continue to
>>     advertise the "max_fragment_length".
>>
>> Do you mean:
>>     Clients that depend on having a small record size MAY continue to
>>     advertise the "max_fragment_length" *only*.
> 
> It's "also".  The idea being that if you aren't sure if the server
> supports the new thing, you might offer the old thing in addition to
> the new thing in the hopes that if the new thing isn't supported, the
> old thing might be.
> 
>> If so, what would be the behaviour of a server that supports both
>> "max_fragment_length" and "record_size_limit" in that situation?
> 
> If you don't include record_size_limit, you can't use it.  If the
> client includes both, then the text from the preceding paragraph
> applies: "A server that supports the record_size_limit extension MUST
> ignore a max_fragment_length that appears in a ClientHello if both
> extensions appear."
> 


[prev in list] [next in list] [prev in thread] [next in thread]