Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)

[Adam Roach <[e-mail]>]

On 4/4/18 1:44 AM, Martin Thomson wrote:
> Hi Adam,
>
> Thanks for the review.  You picked up on something that was a little
> sloppy there.
>
> PR: https://github.com/tlswg/tls-record-limit/pull/19
>
> On Wed, Apr 4, 2018 at 3:58 PM, Adam Roach <[e-mail]> wrote:>
> Adam Roach has entered the following ballot position for
>> §4:
>>
>>>   MUST NOT send a value higher than the protocol-defined maximum record
>>>   size unless explicitly allowed by such a future version or extension.
>> Presumably, recipients MUST gracefully accept values higher than the maximum
>> record size?  That is implied by this text (and the text that follows), but
>> given how TLS frequently aborts connections at the first sign of any
>> irregularity, it's probably worth saying explicitly.
> I thought that the following text was doing precisely that:
>
>> 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.

It would, if it were present. The IESG is reviewing version -02 of the 
document, in which that text does not appear. (I see it's in your repo, 
so presumably the -03 version will address the issue I highlight).

> A client can enforce the restriction, because it knows the entire set
> of possible extensions that determine the maximum size.  I'll concede
> that it's a little sloppy in that it doesn't explicitly say whether a
> client is expected to police the value.  Is that a change you would
> like to see?  As in:
>
>> A client MAY abort the handshake with an illegal_parameter alert if the record_size_limit extension includes a value greater than the maximum record size permitted by the negotiated protocol version and extensions.
> Note that this wasn't made a MUST because if there is an extension
> that raises the limit, the client has to do a second pass over the
> extensions and that's awkward.

I'm okay both with and without the change. What I really wanted was text 
equivalent to what you quote above.

>
>> §4:
>>
>>>   a DTLS endpoint that
>>>   receives a record larger than its advertised limit MAY either
>>>   generate a fatal "record_overflow" alert or discard the record.
>> I'm concerned about the interaction between the option to discard the record and
>> protocols that perform retransmission of lost packets over DTLS (e.g., proposals
>> such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is
>> simply discarded, retransmissions of that (presumably still oversized) packet
>> will take a while to time out (I'm not particularly well-versed in QUIC, but
>> assume it has characteristics similar to TCP's ~nine-minute timeout), which
>> would result in really bad user experiences.  Is there rationale for this optionality?
>> It would seem to be cleaner if the response were simply to always send a fatal
>> error.
> The problem is that you only want to abort if you decrypt the record.
> DTLS doesn't kill connections if it receives junk.

Ah, okay. That makes perfect sense. Under such circumstances, I agree 
that dropping such packets seems to be the least bad path. No document 
change is necessary, although I wouldn't object if you added an 
explanation to the document that says exactly what you say above.

/a