On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote: > > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <davemgarr...@gmail.com> > > wrote: > > > > > > This last bit stops this, yes. I would prefer the spec say this very > > > explicitly, as right now it doesn't and all I see is a line saying: > > > "If any of these checks fail, the server MUST NOT respond with the > > > extension and must discard all the remaining first flight data (thus > > > falling back to 1-RTT)." > > > > Well, this is a general requirement any time the record MAC is bad: > > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2 > > "If the decryption fails, a fatal “bad_record_mac” alert MUST be > generated." > > > > > The current text doesn't explicitly say how to handle 0-RTT data that > it > > > thinks it should be able to decrypt but can't. After rereading things > a bit > > > I think you're correct in that the correct course of action the spec > > > currently expects is to abort, however implementers frequently err on > the > > > side of working partially vs not at all when given any wiggle room. A > clear > > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this > and > > > avoid any other possible misunderstanding. Either do or do not; no try. > > > > > > > If you have suggested text, I'd be happy to see a PR. > > Except that when server is doing 1RTT fallback and skipping 0-RTT data, > then records that get deprotect failure (is that the proper term?) are > ignored instead of generating bad_record_mac like "normal" deprotect > failure would. > > Then there's also the case where server is skipping 0-RTT data for retry > (there one can recognize end of data from content-type 23 changing back > to 22). > Correct. These need to be special cased. And of course with DTLS you just drop such packets rather than terminating the connectin. However, it's worth nothing that even if the first-flight handshake data weren't encrypted, it would still not be possible to create confusion here because the server would still be waiting for the 0-RTT Finished message prior to being willing to accept application data from the client. Then one has to ensure that configuration_id's are never reused: If > client and server disagree about server-valid configuration, the result > can easily be hard failure (instead of fallback). > Yes, agreed. I had always assumed that configuration ids were unique. One server-side trick to ensure non-reuse would be to hash the server > certificate and the configuration messages (with configuration_id being > zeroes of approriate length) using e.g. SHA-256 and then use the resulting > hash as configuration_id. > -Ekr > > > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
