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

[Martin Thomson <[e-mail]>]

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.

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.

> §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.  In this case, you
would only want to kill the connection if the record is authentic.
But if you have a record size limit, it's usually because you don't
want to decrypt big records.  So you probably won't bother even trying
to decrypt the big packet, even if you could.

So yes, discard ends up looking like packet loss, akin to the loss you
get when a path doesn't support the MTU.  Except that you don't have
any hope of receiving feedback (inasmuch as ICMP is available to DTLS
anyway...).

Given that it's a protocol error, I'm not all that enthusiastic about
fixing the problem.  Even writing it down seems wrong.  "If an
endpoint violates its negotiated constraints, then it can induce
denial of service on itself."  There's only so much defensive design
we can build in.

FWIW, QUIC has the exact same mechanism built in, but you don't
retransmit packets verbatim, so it could rectify itself if it was a
one-off.  More likely, it would compound when more outstanding data is
available to send in every subsequent packet, perpetuating the use of
over-large packets.