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

[Martin Thomson]

On Wed, Apr 4, 2018 at 5:44 PM, Adam Roach  wrote:
>>> 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).

My fault.  Sean prompted me to push out a new version, then IESG
reviews started coming in, so I held back.  That was the result of a
secdir review.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Adam Roach]

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  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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls