Subject: [TLS] DTLS 1.3 comments

From: Martin Thomson <[email-masked]>
Date: Tue, 21 Mar 2017 20:24:30 +1100

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

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.

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.

The effect of processing packets independently isn't given proper
treatment in security considerations.  In TLS, when a packet doesn't
decrypt, the connection dies, so an attacker has to start over if they
want to probe the decryption oracle.  In DTLS, packets that don't
decrypt just get dropped, which gives an attacker a huge advantage.

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.

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.

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.

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Mar 2017 05:08:37 -0700

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

> repacketization doesn't produce a two-time pad.

OK. PR wanted.

> you care about saving bits.

Yeah, I haven't thought through this piece of the design space yet.

> It seems like that is in violation of the "drop if you can't decrypt it"

Probably. Maybe OK during the handshake, though, as it's basically a state
error.

>    message if the offending record is received again

Yeah, I'm not sure. I wouldn't object to removing this.

> authentication as the example here.

Thanks.

-Ekr

>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Mar 2017 08:29:23 -0400

> On Mar 21, 2017, at 08:08, Eric Rescorla <[email-masked]> wrote:
> 
> Actually it lives at:
> https://github.com/ekr/dtls13-spec

Assuming it gets adopted I’ll set up a WG repo for it.

spt