On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Sat, Jun 24, 2017 at 12:05:44PM -0700, Eric Rescorla wrote: > > > On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara < > > ilariliusva...@welho.com> > > > wrote: > > > > IMO, since handshake only occurs once per connection and DTLS needs to > > be implemented on all kinds of constrained devices (on both client and > > server sides), simplicity is more important than performance. Also, > > packet loss estimates do not seem useful: There are far too few packets > > to get useful statistics. > > > > I think we definitely want to allow acknowledgements of subcomponents of > messages, because otherwise you have to retransmit the entire message, > which is painful in the case of the obese messages. This seems to leave > one with the option of acknowledging either fragments (which we then > need to invent labels for) or records (which already have labels > but need a map of RSN to fragment). My feeling is that on balance the > latter is a better choice, but I'll have a better sense once we've > implemented....
Just noticed that DTLS allows packing multiple independent fragments into one record (and then multiple records into one packet). Which impiles that an implementation that only prcesses one message at a time is not guaranteed to even be able to generate a valid list of RSNs to ACK, in case the peer sends sufficiently twisted (but still seemingly in-spec) input. What's the alert code for dropping in-spec connection detected as attack traffic? :-) -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
