On Tue, Mar 21, 2017 at 2:24 AM, Martin Thomson <martin.thom...@gmail.com> wrote:
> The doc says that it is maintained at https://github.com/tlswg/dtls13-spec > This is untrue (currently). > I found it at https://github.com/hannestschofenig/tschofenig-ids Actually it lives at: https://github.com/ekr/dtls13-spec <https://github.com/tlswg/dtls13-spec> And I have issues filed on this already, so we can rplicate. > Speaking of which, it would be really nice if there were an issue > tracker that we could use for this. I hope that the working group > adopts this an moves it to this location so that I don't have to dump > issues in an email. Issues in email get lost. > > I realize that we're going to look carefully at the packet format and > probably streamline the record structure a little. ekr has my > analysis on this, which I'm happy to share. > https://github.com/ekr/dtls13-spec/issues/5: > The diagrams in Section 5.5 talk about discrete flights, which makes > sense when talking about the handshake, but once it starts, > application data can be continuously exchanged. That's a detail that > might be lost. > > Retransmissions of handshake messages use new record sequence numbers > (though the handshake sequence number stays the same). This really > isn't dealt with prominently enough to my mind. It's important that > repacketization doesn't produce a two-time pad. > OK. PR wanted. I believe that the rekeying design needs a little better description. > This is what I've implemented and what I think the intent is: > * if you want to update, just send with the next epoch > * if you see the other side update, and you haven't already, update > yourself > * don't update until you see that the other side has used the current epoch > > That's also what QUIC currently uses. With this design, you can > reduce the epoch bits to 2 during the handshake and 1 afterwards, if > you care about saving bits. > Yeah, I haven't thought through this piece of the design space yet. The draft is says this, which I can't really parse: > > Upon receiving > a payload with such a new epoch value, the receiver MUST update their > receiving keys and if they have not already updated their sending > state up to or past the then current receiving generation MUST send > messages with the new epoch value prior to sending any other > messages. > > I really don't understand the "prior to sending any other messages" part. > > Is this right? > > Implementations that receive a payload with an epoch value for which > no corresponding cipher state can be determined MUST generate a > "unexpected_message" alert. For example, client incorrectly uses > epoch value 5 when sending early application data in a 0-RTT > exchange. A server will not be able to compute the appropriate keys > and will therefore have to respond with an alert. > > It seems like that is in violation of the "drop if you can't decrypt it" > rule. > Probably. Maybe OK during the handshake, though, as it's basically a state error. I wonder how many implementations do this: > > However, a DTLS implementation > which would ordinarily issue an alert SHOULD generate a new alert > message if the offending record is received again > > NSS certainly doesn't. > Yeah, I'm not sure. I wouldn't object to removing this. > Section 5.5.2 mentions re-handshake. That's not possible any more. > Probably best to use NewSessionTicket or post-handshake client > authentication as the example here. > Thanks. -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
