On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote: > > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema < > huit...@microsoft.com> > > wrote: > > > > > For DTLS, we have to consider the packet injection threat. It is fairly > > > easy to send some random bytes with a fake source to a UDP destination. > > > Such attacks should not cause the DTLS association to fail! The normal > > > behavior ought to be to just ignore UDP packets that fail to decrypt. > This > > > would cause 0-RTT rejects to just result in dropped packets. Can we > ensure > > > that the handshake protocol is robust against that? > > > > > > > We obviously need to distinguish here between handshake and application > > data messages, because DTLS is intended to allow loss of application data > > messages. > > > > WRT handshake messages, as I indicated before, I believe that there is > > enough information in the handshake messages to prevent removal. > > Namely: > > > > 1. The ClientHello contains an indication that 0-RTT handshake messages > > are coming. > > 2. The Client's 0-RTT Finished contains a MAC of all the Client's > > 0-RTT messages. > > 3. The Server's Finished contains a MAC of the ClientHello. > > > > Thus, provided that the client and server in fact share a configuration > > (which, again, is in the ClientHello) then the server knows at the time > > of receiving the first-flight Finished that he has (or has not) received > > all the client's 0-RTT Handshake messages. [0]. > > Also, maybe a stupid question: > > While the 0-RTT handshake parts are obviously reliably transmitted, is > the same true for the 0-RTT data part? > No, nor for any DTLS data. The assumption is that this is handled at the layer above. That is, is the server allowed to ACK the flight after having received > ClientHello/Certificate/CertificateVerify/Finished; and deal with any > 0-RTT data messages should they arrive (these are not necressarily > retransmitted if lost)? > I would anticipate that this is the correct behavior and in fact this seems like the right behavior for TLS as well, since part of the point of 0-RTT data is to stream it ASAP. Note that there is no explicit ACK, though. Or if the context does not support early auth, just ACK immediately > after ClientHello. Yes, this is currently technicaly possible. It occurs to me that data messages in DTLS 1.2 lack the fields needed > for automatic retransmission. > > > The more interesting question, however, is what drives the DTLS state > > machine forward to ensure progress in the face of innocuous loss. > > The basic DTLS design is that the receipt of the first message of the > > peer's next flight indicates receipt of the entire flight. In this case, > > then, the receipt of the ServerHello would indicate receipt of the > > Client's 0-RTT Finished. However, this would place a requirement > > that the server not *send* the ServerHello until that point, which we've > > left open in WIP-11 by not hashing in the 0-RTT plaintext. > > I think that would be fairly easy way to deal with it (not saying that > simpler ways don't exist). > > > Also, on topic of DTLS 1.3... It occurs to me that naively doing it > would leave it open to "fragementation attacks" a'la IPv6. > > Basically, it occurs to me that ClientHello messages SHOULD NOT be > fragmented (at TLS level, SCTP(?) or IP level fragmentation is another > kettle of fish) and if it is fragmented, the Cookie extension MUST be > in the first fragment. > Sorry, I'm not sure I am processing this. Can you explain in more detail. Also, there's question of how to handle HelloVerifyReqest (one can't > just downgrade to DTLS 1.2!). One way: > > - If it was in reply to ClientHello with EarlyData extension (at least > with early auth?), treat it as fatal protocol_version Alert. TLS 1.2 > can't handle early data. > - If it was in reply to ClientHello without EarlyData extension, write > the cookie into the header cookie field (not extension cookie field) > and resend. This counts as a retry. Yes, this seems like the right answer. I.e., You only do HVR in TLS 1.2 and as we have discussed previously, once you have sent a ServerConfig, you have to continue to be able to do TLS 1.3, even if you forget the config. Best, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
