Subject: [TLS] DTLS 1.3

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Jul 2016 12:21:22 +0200

Hi all,

I have made an attempt to integrate DTLS 1.3 into the TLS 1.3 document
and you can find the result at https://github.com/tlswg/tls13-spec/pull/512

I have worked on a prototype implementation of DTLS 1.3 and if someone
else has something working by the time of the Hackathon in Berlin please
let me know.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jul 2016 06:27:37 -0700

Thank you. I will examine the PR ASAP.

NSS already implements the obvious extrapolation of TLS 1.3 to DTLS and we
are planning to start testing it in Firefox WebRTC shortly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1284103

-Ekr

On Mon, Jul 4, 2016 at 3:21 AM, Hannes Tschofenig <[email-masked]
> wrote:

> and you can find the result at
> https://github.com/tlswg/tls13-spec/pull/512
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 17:03:12 +0300

> else has something working by the time of the Hackathon in Berlin please

Taking a look:

- The version field is described as identical to TLS 1.3 version field.
  What value is there actually? FCFE (wasn't that how "DTLS 1.0" was
  encoded on wire)?
- Length and payload is is described as identical to version (which
  seems pretty odd...)
- The PR talks about "rehandshake". I believe that concept no longer
  exists in TLS 1.3.
- KeyUpdate does not work in DTLS. Might just use epochs for similar
  purpose, and reserve first few epochs for special purposes.
- One could allow epochs to wrap (sequence number arithmetic). Won't
  cause nonce reuse due to different keys. 
- The PMTU section talks about block padding and compression. Neither
  exists anymore (there is padding, but the minimum expansion is
  exactly known, e.g. the 30 bytes for most ciphersuites).
- The full handshake protocol is only run once. After that, there's
  only rekeying, new tickets and dynamic reauth.
- There's special case with cookies: DTLS 1.3 ClientHello getting
  rejected with HelloVerifyRequest. I think the correct reaction
  is for client to send a DTLS 1.3 ClientHello without 0-RTT data,
  containing the cookie sent now in legacy cookie field (NOT the
  extension).
- According to TLS 1.3 rules, handshakes rejected using
  HelloRetryRequest use the Cookie extension for cookie
  transmitback, not the legacy cookie field (the cookie might not
  even fit into that field!)
- If handshake is rejected using HelloRetryRequest, according to
  the TLS 1.3 rules, the first ClientHello and HelloRetryRequest
  ARE included in handshake hashes.
- Is the DTLS 1.2 written as 0303 on the wire? I seem to remember
  it would be FCFC (but I could be wrong about that)? If it is
  not 0303, then DTLS 1.3 is not going to be 0304...
- In DTLS, AFAIK 0-RTT appdata is not reliable (but the 0-RTT
  handshake messages are). This brings all sorts of "fun" with
  message reordering and loss.
- The handshake retransmit scheme doesn't seem to work that
  well with post-handshake auth, and even less well with
  session tickets.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Jul 2016 21:45:38 +0200

Hi Ilari,

thanks for your super quick response.

>   What value is there actually? FCFE (wasn't that how "DTLS 1.0" was

For the record layer TLS 1.3 says that the version field is deprecated
and ignored. I guess the same approach applies to DTLS 1.3. So, it
probably doesn't matter what is really is. In DTLS 1.2 the version value
was 254.253.

For the client_version and server_version in the handshake I thought it
would be fine to just re-use the TLS 1.3 version number.

> - Length and payload is is described as identical to version (which

Copy-and-paste mistake. Fixed.

> - The PR talks about "rehandshake". I believe that concept no longer

Updated the text and referred to the KeyUpdate where applicable.

>   purpose, and reserve first few epochs for special purposes.

Could you explain in more detail why you think a key update does not
work with DTLS?

>   cause nonce reuse due to different keys. 

I have no preference regarding this issue.

>   exactly known, e.g. the 30 bytes for most ciphersuites).

Deleted sentence you mentioned.

>   only rekeying, new tickets and dynamic reauth.

How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen.

>   even fit into that field!)

Regarding the issue of where to send the cookie in the ClientHello there
are two options. The first option is to use the cookie extension, and
the second option is to use the DTLS 1.2 style where the cookie is
placed in the ClientHello directly (without using an extension).

My (weak) preference is to use the cookie extension also in the
ClientHello. My main reason was the length mismatch between the DTLS 1.2
cookie extension (which is now in the legacy_cookie filed) and the
cookie extension. The cookie extension has a max length of 2^16-1 bytes
and the legacy_cookie extension only 2^8-1 bytes long. If the design of
the ClientHello uses the legacy_cookie extension then the server has to
take care that the cookie size does not exceed the 2^8-1 bytes.

>   ARE included in handshake hashes.

Fixed it but I am not sure that's a good idea unless the cookie carries
that state information. With 255 bytes that's going to be difficult...

>   not 0303, then DTLS 1.3 is not going to be 0304...

Are you referring to the version field?

>   message reordering and loss.

That's certainly something to take a closer look at. I haven't
implemented that part yet ....

>   well with post-handshake auth, and even less well with
Why do you think so? Of course, unreliable transports creates
inconvenience; is it that what you are referring to?

Ciao
Hannes

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 4 Jul 2016 15:54:19 -0400 (EDT)

----- Original Message -----
> else has something working by the time of the Hackathon in Berlin please

May I recommend a more radical approach for DTLS? My experience with servers
handling DTLS traffic from various clients is that the clients change IPs (while
roaming) and incoming ports (due to firewall state timeout), making impossible
for the server to map the encrypted incoming packets from unknown IP/port combinations
to any particular handler (i.e., handling process/thread or logical handler). That
is because an independently received DTLS record packet has no session identifying
information.

For that I'd like to propose the DTLS record format to include at least a
3-byte identifier which will allow servers to recognize streams coming from unknown
sources. That would be similar to the SPI field in the ESP packets. That is,
a format similar to:

      struct {
          ContentType type;
          ProtocolVersion record_version = { 3, 1 };    /* TLS v1.x */
          uint24 id;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

where id is sent by the server to the client either via an extension, or
by simply assuming that the client will copy and keep the ID seen at the
server packets (it doesn't really matter that this ID is unprotected as
it doesn't contribute nor affect the security in any way).

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 23:46:03 +0300

> probably doesn't matter what is really is. In DTLS 1.2 the version value

Oh, it was that. Then I presume DTLS 1.0 was 254,255 (yup, checked the
RFC).
 
> would be fine to just re-use the TLS 1.3 version number.

I think that is not a good idea, and one should follow the pattern (which
would give 254,252 for ClientHello/ServerHello).

But for record version, reusing previous versions (either 254,255 or
254,253) should be fine.

> Could you explain in more detail why you think a key update does not

That message is not idempotent (nor has it timely ACK).
 
> How TLS 1.3/DTLS 1.3 is used in specific environments remains to be seen.

Well, certainly the main handshake only runs once per connection.
 
> take care that the cookie size does not exceed the 2^8-1 bytes.

I think the obvious way is:

- Cookies from HelloVerifyRequest go to legacy cookie field.
- Cookies from HelloRetryRequest go to extension cookie field.

If you don't do the first, you can't downnegotiate successfully. And
if you don't do the second, you would have to have special case with
cookie sizes (since HRR can transmit >255 byte cookie, which would be
too big for legacy cookie).
 
> that state information. With 255 bytes that's going to be difficult...

Well, it can be larger than 255 bytes. And barring client sending large
0-RTT context (what are those anyway???), one can fit it into very
few bytes (<16 should be possible with blank context).

> Are you referring to the version field?

Yeah, CH/SH version field. And DTLS was FEFD...

> implemented that part yet ....

Yeah, I haven't really taken a closer look at it either...

> inconvenience; is it that what you are referring to?

DTLS assumes handshake messages are reliable, and that reliability is
implemented via handshake messages ACKing one another.

- Session tickets have no ACK at all.
- CertificateRequest can have very slow ACK.
- KeyUpdate has no real ACK (and isn't idempotent either).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 23:51:14 +0300

> is because an independently received DTLS record packet has no session identifying

I think in DTLS 1.2, that was meant to be handled at lower layer (of course, often
there isn't such layer even when needed).
 
> sources. That would be similar to the SPI field in the ESP packets. That is,

One can't change the headers in ClientHello/ServerHello and expect to remain
backwards compatible.

And how would that identifier be assigned? 0 in ClientHello, then copy whatever
the server sends?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Jul 2016 13:56:01 -0700

> too big for legacy cookie).

IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send
HRR.

> - Session tickets have no ACK at all.

DTLS 1.3 should add an ACK, IMO.

> - KeyUpdate has no real ACK (and isn't idempotent either).

Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch
instead.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Jul 2016 22:07:26 +0100

> it doesn't contribute nor affect the security in any way).

Does that id need to be static? If so, then it'd act as an
additional way to track a user roaming over different IP and
ports. That'd be a pity. If such an id is useful, maybe there's
a way to allow it to change as well, in a way predictable for
the server.

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Jul 2016 23:09:27 +0200

Hi Nikos,

when it comes to optimizing the record layer then it basically boils
down to the question about how middleboxes react to this type of change.

In the IoT context the story is a bit easier since there greenfield
deployments with new radio technologies where these types of middleboxes
are not yet there. For those environments more radical changes, as you
and Thomas mentioned, are probably useful.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 5 Jul 2016 00:18:05 +0300

> IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send

Yes, DTLS 1.3 servers can't send HVR, but that doesn't mean DTLS 1.3
clients can't receive HVR (and then need to handle it somehow).

And if downnegotiation is to be possible, then that way should be
compatible with DTLS 1.2 (sticking the cookie into legacy cookie
field and clearing the hash should be compatbile enough).

> DTLS 1.3 should add an ACK, IMO.
 
Yeah, not going to work without. And I presume something might be
needed for dynamic reauth too...
 
> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch

How many special epochs we need?

0 => Unencrypted messages
1 => 0-RTT control messages (just one finished[1]!)
2 => 0-RTT data messages
3 => primary handshake
4 => application data
5-N => rekey connection

Would that be enough?

Reserving epochs would clearly expose the 0-RTT records and the
handshake through. Would solve the reordering with 0-RTT tho.

And can epochs wrap around (this would not cause problems with nonce
reuse, since keys are not going to match)?

[1] Whereas in TLS 1.3 that finished seems pointless (you have a
MAC to check anyway), now in DTLS if there are no 0-RTT handshake
messages, there is no guarantee that any 0-RTT message is received,
resulting no MAC to check.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 5 Jul 2016 11:29:20 +0300

> DTLS 1.3 should add an ACK, IMO.

Some quick napkin^Wtext editor sketch:

Handshake message type: acknowledge
- DTLS 1.3 only, not TLS 1.3.
- No retransmissions (transmitted once per trigger)
- Triggered if a complete flight is received with:
  * session_ticket message by client
  * certificate_request message by client and the client can't quickly
    produce the authentication block[1]
  * finished message by server.
- Contents:
  * Enumerated type:
    + SESSION_TICKET_RECEIVED
    + CERTIFICATE_REQUEST_IN_PROGRESS
    + CLIENT_FINISHED_RECEIVED
  * req_context: Certificate request context
    (CERTIFICATE_REQUEST_IN_PROGRESS only).

The certficate_request case could occur during the handshake, it then
would kill the server retransmit timer if received, having only the
client hold the retransmit (after it has finished assembling the
authentication block).

This design can probably be improved quite a bit.

[1] Including block that rejects the request.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Jul 2016 10:42:08 +0200

Hi Ilari,

> field and clearing the hash should be compatbile enough).

Consider the following three cases:

* Client supports DTLS 1.2 / 1.3 but the server supports only DTLS 1.2.

If the client starts the exchange with DTLS 1.3 then the server could
return a HelloVerifyRequest as defined in DTLS 1.2 and the exchange can
continue. For the client it is not a problem to deal with the HVR since
it supports both stacks.

* Client supports only DTLS 1.3 and server supports DTLS 1.2/1.3.

Here the client starts with a DTLS 1.3 exchange and the server will only
reply with a HelloRetryRequest as defined in TLS 1.3. It should bother
dealing with the DTLS 1.2 functionality when interacting with a DTLS 1.3
client.

* Client supports only DTLS 1.2 and the server supports DTLS 1.2/1.3.

In this case, the client starts with the regular ClientHello and the
server will determine based on the version that it has to proceed with
DTLS 1.2.

I believe that this could work fine.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Jul 2016 10:59:10 +0200

Hi Ekr,

~snip~

> IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send

That makes sense to me.

Btw, Section 11 "IANA Considerations" says that the Cookie extension is
encrypted in the HelloRetryRequest message. I wonder whether this is a
mistake particularly in the combination where the server returns the
cookie as part of the incorrect key share (and therefore does not yet
have a key to create the EncryptedExtension). The table should also say
that the cookie is also contained in the ClientHello (in clear, unless
it is a 0-RTT handshake).

> DTLS 1.3 should add an ACK, IMO.

Sounds reasonable.

> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch

Ok.

Ciao
Hannes

>     [email-masked] <mailto:[email-masked]>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 5 Jul 2016 13:54:49 +0300

> I believe that this could work fine.

There are two more cases if server-side fallback is possible. One that
can't work at all (fallback below minimum supported version) and another
where the server has to be careful what cookie field it uses.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 5 Jul 2016 09:47:28 -0400 (EDT)

----- Original Message -----
> I think in DTLS 1.2, that was meant to be handled at lower layer (of course,
> often there isn't such layer even when needed).

I'm not sure that is discussed at DTLS 1.2 protocol at all. It is mostly ignored
as a problem. In the most unreliable layers (including UDP), this cannot be handled
at the lower layer without introducing another layer.

> One can't change the headers in ClientHello/ServerHello and expect to remain

Why would these headers need to change? The ClientHello will be sent under
DTLS 1.0 and if the server see that the client supports the version with the
new format, it will reply using the new fields. The protocol's design can
cope with such changes.

> And how would that identifier be assigned? 0 in ClientHello, then copy
> whatever the server sends?

If the procedure above is followed the client will copy whatever it
sees from the server's hello packet.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 5 Jul 2016 09:49:42 -0400 (EDT)

----- Original Message -----
> a way to allow it to change as well, in a way predictable for

Could be, but I don't have a use case for such a switch nor can think something
obvious, what do you have in mind?

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Jul 2016 15:24:02 +0100

On 05/07/16 14:49, Nikos Mavrogiannopoulos wrote:
> Could be, but I don't have a use case for such 

Hmm. I'd hope we can all share a use case of bring more
privacy-friendly where possible and of not introducing
changes that are privacy-unfriendly unless absolutely
unavoidable.

Adding a new identifier that doesn't change despite changes
in client IP address etc. seems like it fails if one has
the "use case" above in mind. Actually, the above is not
really a use-case, but is nonetheless something on which I
think we ought be able to agree so not all changes need to
correspond to some use or abuse case:-)

> a switch nor can think something

I've no specific proposal. If it were the case that a new
cleartext identifier is wanted, then there could be ways in
which that can be modified (e.g. a hash-chain based on
something known to both client and server but not sent in
clear) so that the server can know then next "N" ids to be
expected but an observer can't use these to re-identify a
client.

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 14:34:07 +0200

Hi Ilari, Hi Ekr,

a few remarks inline:

~snip~

> needed for dynamic reauth too...

I was wondering about one design decision regarding the ack.

If we don't use the epoch instead of the KeyUpdate then there is only
one other message that does not have an ack, namely the NewSessionTicket
message. (I might be worthwhile to think about why the server can send
it at any time and why it isn't sent as part of the regular handshake
instead. This would make the issue with acks potentially go away.)

The post-handshake authentication with the CertificateRequest comes with
an ack (even though it may be delayed), namely Certificate,
CertificateVerify, and Finished (and in case of a decline with a
certificate and a finished). Would it be worthwhile to ack them as well
due to the potential delay caused by user interaction?

Let us say that we provide an ack for the NewSessionTicket message then
it is sufficient to specify a very simple ack, namely one that is
defined as: struct {} Ack;

If we also ack the post-handshake authentication then it is necessary to
include some identifier in the Ack message to indicate which message is
acked.

What are your thoughts about this?

>> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch

I believe that using epoch for updating the cryptographic keys is pretty
much like a key update. Essentially, we are talking about taking the
epoch value from the incoming packet and then figuring out what security
context is applicable. Correct?

An alternative design would be to require the receiver of a KeyUpdate to
return a KeyUpdate as well. This would then constitute a flight.
Wouldn't this be better?
> 1 => 0-RTT control messages (just one finished[1]!)

I guess you want to introduce these different epoch values and associate
them with different phases during the handshake since the TLS 1.3 key
derivation is more sophisticated than the TLS 1.2 version.

Is this correct?

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Jul 2016 17:47:08 +0300

> instead. This would make the issue with acks potentially go away.)

Being part of regular handshake is problematic, since those are assumed
to be tickets, and as such one needs the dynamic PSK key. But the dynamic
PSK key includes the entiere handshake up to Client Finished. And this
can't really be changed (or things start going badly wrong).

So the minimum time to send some tickets is 4th flight, whereas normal
handshake is only 3 flights.

> include some identifier in the Ack message to indicate which message is

Certificate requests have context identifiers...

> context is applicable. Correct?

Yeah.
 
> return a KeyUpdate as well. This would then constitute a flight.

I don't think this works, because KeyUpdate is not idempotent (causes
problems if reply is lost) and worse yet, because of potential desyncs
with the main data flow (IP packet reordering!).

> derivation is more sophisticated than the TLS 1.2 version.

Each listed one essentially corresponds to one key connection can use:

- Unencrypted (CH/SH/HRR)
- 0-RTT handshake key (Finished)
- 0-RTT data key (0-RTT appdata)
- Handshake key (Encrypted Extensions to Client Finished)
- Application key from initial traffic_secret_0.
- Application key from traffic_secret_N  (N>0).

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jul 2016 21:25:15 +0200

Hi Ilari,

a few remarks inline:

> handshake is only 3 flights.

Was just an idea. The TLS 1.2 ticket mechanism was also transmitted
during the handshake.

> Certificate requests have context identifiers...

I was more thinking about including the HandshakeType to distinguish the
ack for a NewSessionTicket from an ack to a CertificateRequest.

> with the main data flow (IP packet reordering!).

Maybe it should be made idempotent...

> - Application key from traffic_secret_N  (N>0).
Thanks. Makes sense.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Jul 2016 22:34:54 +0300

> Was just an idea. The TLS 1.2 ticket mechanism was also transmitted

The TLS 1.2 ticket mechanism actually did nasty things to forward secrecy.
In TLS 1.2, the ticket happens to be in 4th flight after Client Finished,
which avoids most of the problems TLS 1.3 would have with tickets in-
handshake.
 
> ack for a NewSessionTicket from an ack to a CertificateRequest.

Oh yes. I posted a rough sketch of such message, it had a corresponding
field...
 
> Maybe it should be made idempotent...

You still have packet reordering even if it is idempotent...

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 07 Jul 2016 10:13:37 +0200

> changes that are privacy-unfriendly unless absolutely

Thank you, now I understand your concern. However, I would like to
point that a static identifier does not make the situation any worse
than we have today. DTLS over UDP (or any other layer) is not
anonymous, and DTLS as a protocol it was never meant to be. Moreover,
any method to have a dynamic identifier should be of complexity that
would make such an approach reasonable for a server to calculate
without state (the problem this identifier solves is that a server
doesn't know to which client this session belongs on receipt of a
packet, thus it would have to calculate any dynamic identifiers without
any state).

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jul 2016 10:37:34 +0100

Hiya,

Just on this one thing...

On 07/07/16 09:13, Nikos Mavrogiannopoulos wrote:
>  does not make the situation any worse
> than we have today.

I don't accept that is the correct goal. That form of
argument is what lead to us standardising the HTTP
Forwarded header field, which IMO was a disimprovement.
(An argument I lost in the end in that case [1], but
'twas close, and back in 2012 so might go the other
way today;-)

I would argue that the correct goal is to make things
better whenever possible, with that being especially
important for protocols like (D)TLS on which many
other things depend.

I do agree that any scheme developed would need to
meet the state management requirements of servers.
I'm not convinced those requirements call for a new
super-cookie though:-)

S.

[1] https://datatracker.ietf.org/doc/rfc7239/ballot/

---

From: Mike Copley <[email-masked]>
Date: Thu, 7 Jul 2016 11:10:39 +0100

> I'm not convinced those requirements call for a new

What about making it an optional value, with clients that don’t need such behaviour specifying an all-zero value? I have a use case where I control both clients and servers and would like to automatically and simply deal with changing IPs/ports on both sides, and would much rather have this functionality built into DTLS than having to somehow preface the DTLS packet with this ID added.

If we were to go down this route, I would ask that there is a mechanism for an endpoint (server or client) to verify the legitimacy of the IP/port change before handing the data to an upper layer. E.g. Recipient (server or client) receives the ID from a new source (Initiator), sends an encrypted challenge to the new source/initiator, and the initiator replies with an encrypted challenge response at which point the recipient can validate and adjust its return path.

Regards,

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 07 Jul 2016 13:52:58 +0200

> I'm not convinced those requirements call for a new

I understand your point, I'm not fully convinced by that argumentation.
I may be wrong of course, but I'll try to explain my point. Indeed
putting privacy first should be a goal of TLS/DTLS, but to the extent
it covers the protocol goals. What you propose is to make a stream
anonymous, untrackable. However, that (anonymity or untrackability of
the stream) was never a stated goal of TLS/DTLS. In fact TLS is by
definition trackable over TCP and one can see in the clear the IPs of
the two peers communicating. That doesn't change by switching to DTLS,
except for unfortunate situations of routers losing state and client
roaming, which current servers cannot easily cope with, and that's the
problem I attempt to address.

I think the principle of doing one simple thing and doing it well,
applies to protocols as well. TLS and DTLS provide a layer of
confidentiality and authenticity. Anonymity, untrackability can be
provided by other protocols focused on that such as TOR.

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jul 2016 12:57:06 +0100

On 07/07/16 12:52, Nikos Mavrogiannopoulos wrote:
> anonymous, untrackable. 

Totally wrong, sorry. What I propose is not adding new ways to
allow a network observer to track a tls client using the same
tls session over multiple transport layer connections, unless
that is really unavoidable.

Exaggerating my argument is not useful. Not is it at all convincing.

S.

> However, that (anonymity or untrackability of

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 08:34:47 +0000

Hi Nikos, Stephen,

It seems to me that both your views (high resistance to traceability and
low resource investment on server side) can be accommodated in a single
scheme.

Going back to the hash chain proposal that Stephen did a few emails ago on
this same thread. If:

1. the length of the hash chain is the shortest between the lengths each
peer proposes, and
2. the client is left in complete control of the rollover policy for the
session identifier (i.e. deciding when to switch to a new Id),

then we would have a lot of flexibility (ranging from one session
identifier which lives forever to one session identifier per packet --
that's entirely decided by the client), while at the same time giving the
server a voice in determining an upper bound to the resources it needs to
reserve per each session.

Cheers, t

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Jul 2016 10:44:19 +0200

On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote:
> low resource investment on server side) can be accommodated in a
> single scheme.

Hi,
 How would the hash chain matching work for a server handling multiple
clients?

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Jul 2016 11:05:53 +0200

On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote:

> Sorry, I'm not sure I understand the question.  Are you asking what
> happens if there is an Id collision between two separate hash chains?

No, my question is much simpler. How would a server handling for
example 20000 clients, will figure to which chain a hash of H(x)
belongs to? Will it have to iterate through all the chains (client
states) and test for matching or there is something more clever than
that?

regards,
Nikos

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 08:59:15 +0000

Hi Nikos,

Sorry, I'm not sure I understand the question.  Are you asking what
happens if there is an Id collision between two separate hash chains?  If
so, in general the nature of the keyed hash used to produce the chain
would help keeping the number of collisions low.  In case an Id is a dup,
the server can spot the condition and signal it back to the client.

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 09:29:42 +0000

>states) and test for matching or there is something more clever than

Ah! The hash chain would be computed at the end of the handshake, so all L
Ids can be put in a hash table that maps them to the same DTLS context.
When a data record comes in, its Id can be used to look up the context in
O(1).
Clearly the server needs to negotiate a sensible L if it doesn't want to
blow up.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Jul 2016 11:55:52 +0200

On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote:

> Clearly the server needs to negotiate a sensible L if it doesn't want
> to blow up.

As long as both the client and the server are able to notify each other
that they only support L=1 I'd be content with it. However, I'd prefer
a simple solution and defer the hash chain negotiation for a separate
extension, since we cannot foresee how and if such an extension will be
used. As we saw with heartbleed any unused complexity is not necessary
adding value.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 13:36:03 +0300

>   purpose, and reserve first few epochs for special purposes.

Eeh... Epochs have the problem that processing records with epochs
far into the future is expensive (even to reject records in failed
MAC check).

This problem didn't turn out to be trivial... :-/

-Ilari

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 11:06:46 +0000

Hi Nikos,

On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" <[email-masked]> wrote:
>that they only support L=1 I'd be content with it.

In the straw man I proposed above, it is sufficient for the server to say
L=1.  In that case the client will trigger a re-handshake when its Id
rollover policy says so.

>However, I'd prefer

I wholeheartedly agree on the implementation simplicity goal.  I think the
proposal allows both sides to be as simple as they want to.

Cheers, t

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 16:25:49 +0300

> L=1.  In that case the client will trigger a re-handshake when its Id

The client can't re-handshake. It probably would be able to obtain a new ID
to replace the "burned" one.

This way the client only needs enough IDs to obtain a new one before all
IDs are exhausted.

However, turns out this doesn't actually work as well as hoped in
practice. The problem is that client can't really change address voluntarily
(even if it is behind CGNAT, it probably can't change the outgoing address
until CGNAT triggers involuntary rebinding, and client can't react to
such rebindings fast enough.

So it would be limited to cases where the client has non-NAT connection
and is renumbered. And such pretty rarely happens.

Given the above, I wonder if just having main and backup ID would be
enough: When changing addresses, backup ID becomes main ID, and
client asks server for a new ID that becomes the new backup ID.

-Ilari

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 16:25:09 +0000

Hi Ilari,

On 08/07/2016 14:25, "[email-masked] on behalf of Ilari
>such rebindings fast enough.

You are right.  If client doesn't know that a re-bind has happened and
therefore sends data using the same Id, it's trackable.  In this case I
think the trade-off you are doing is letting the session survive even you
are potentially trackable.  This is probably Nikos' use case.

>and is renumbered. And such pretty rarely happens.

My use case is an IoT device that voluntarily (or better, knowingly)
migrates its attachment from IP to GSM-SMS and vice-versa and wants to
keep the (painfully) negotiated session open.  Here the client is in
complete control of the situation and can do the Id rollover at the right
point in time.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 8 Jul 2016 20:46:05 +0300

> complete control of the situation and can do the Id rollover at the right

Hmm.. GSM-SMS... Would 1 backup ID be enough for that (given that it
then would have to get another backup ID using SMS (which I presume
is pletty unpleasant) for renumbering back into IP)? Or would one
preferably have 2?

-Ilari