Re: [TLS] Connection ID Draft

[Simon Bernard]

Hi,

Here are the scenarios we would be interested to see covered by this CID 
extension.


1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID 
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID 
connections.


Linkability is not an issue for us, we have almost the same kind of 
linkability than with fixed IP.


Point 1. seems already supported.
Points 2. and 3. seems not ok for now because its not so easy to know if 
a record contains a CID or not.


To know if a record contains a CID, the proposed solution in this thread 
are:

- using content type (not sure to see how?)
- using version (not available in DTLS 1.3? impact on current 
implementation?)

- add a MAC for CID (bandwidth cost?)

I don’t know which one could be the best, but I have one question: how 
to know the CID length for stateless middlebox or packet introspector ?


Simon

Le 03/11/2017 à 11:12, Matt Caswell a écrit :


On 03/11/17 09:28, Martin Thomson wrote:

On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:

It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.

Yes, and the connection ID is that marking.  The contention - I think
- is what to do when there is a mix of marked connections and
unmarked.

Right - where you have a mix of packets with connection ID and no
connection ID you don't know whether to look for one or not. IMO this
draft won't really be addressing the issues unless it includes a
mechanism for determining that.

Matt

___
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

Re: [TLS] Connection ID Draft

[Matt Caswell]

On 03/11/17 09:28, Martin Thomson wrote:
> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:
>>
>> It was my understanding that it is precisely this sort of problem that
>> this draft was attempting to address. Explicit marking would solve this.
> 
> Yes, and the connection ID is that marking.  The contention - I think
> - is what to do when there is a mix of marked connections and
> unmarked.

Right - where you have a mix of packets with connection ID and no
connection ID you don't know whether to look for one or not. IMO this
draft won't really be addressing the issues unless it includes a
mechanism for determining that.

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 03/11/2017, 09:28, "TLS on behalf of Martin Thomson"  wrote:
> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:
> > It was my understanding that it is precisely this sort of problem
> > that this draft was attempting to address. Explicit marking would
> > solve this.
> 
> Yes, and the connection ID is that marking.  The contention - I think
> - is what to do when there is a mix of marked connections and
> unmarked.

Specifically, the two lines of contention seem to be:
- On the receiver side, whether to favour survival of CID v non-CID
  bearing sessions;
- Packet analyser friendliness (i.e., being able to correctly parse
  the stream without requiring it to keep state.)

Cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:
>
> It was my understanding that it is precisely this sort of problem that
> this draft was attempting to address. Explicit marking would solve this.

Yes, and the connection ID is that marking.  The contention - I think
- is what to do when there is a mix of marked connections and
unmarked.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Matt Caswell]

On 02/11/17 23:34, Martin Thomson wrote:
> On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell  wrote:
>> Just skimming this old thread...doesn't this fail in the case where the
>> five tuple has been reused? In that case five_tuples.lookup will return
>> an old stale connection which the server thinks is still valid so we
>> never get to lookup the connection id. With an explicit marking we would
>> not fail in this scenario.
> 
> I'm assuming that once a connection is closed (or moved), the entry is
> removed.  There's some fudging needed there for migrations (it might
> be in two places at once for a while), but I don't see a significant
> problem.  (Note that I didn't include the update parts of this code -
> when a packet decrypts successfully, you need to update the
> five_tuples list.)
>

Imagine the scenario where you have a large number of clients sitting
behind a NAT middlebox talking to a server. If the NAT crashes/reboots
then all of the associations are lost and the server will not know to
remove any of them from its table. It then seems highly likely that a
tuple will get reused with stale connections in the server's table.

It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[yinxinxing]

I agree with Matt. The port/IP could be reallocated to the peer that sends 
packets with connection ID.

Yin Xinxing

-邮件原件-
发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Matt Caswell
发送时间: 2017年11月3日 0:32
收件人: tls@ietf.org
主题: Re: [TLS] Connection ID Draft



On 17/10/17 22:35, Martin Thomson wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - 
> GB/Cambridge, UK)  wrote:
>> The following case (NAT box reboot) is problematic:
>>
>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>>host B (B.1);
>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; 3. 
>> The NAT box reboots (all previous 5-tuple mappings are lost); 4. B.1 
>> receives a record from A.1 (whose 5-tuple has changed in the
>>meanwhile);
>>
>> How is B.1 supposed to correctly interpret the bytes starting at 
>> offset
>> +11?  (For what it knows, it could be CID from A.1 or the length 
>> +field
>> from A.2.)
> 
> I don't think that this is a problem.
> 
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
>   connection = 
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset
> +connection_id_length])
> }

Just skimming this old thread...doesn't this fail in the case where the five 
tuple has been reused? In that case five_tuples.lookup will return an old stale 
connection which the server thinks is still valid so we never get to lookup the 
connection id. With an explicit marking we would not fail in this scenario.

Matt

___
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

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell  wrote:
> Just skimming this old thread...doesn't this fail in the case where the
> five tuple has been reused? In that case five_tuples.lookup will return
> an old stale connection which the server thinks is still valid so we
> never get to lookup the connection id. With an explicit marking we would
> not fail in this scenario.

I'm assuming that once a connection is closed (or moved), the entry is
removed.  There's some fudging needed there for migrations (it might
be in two places at once for a while), but I don't see a significant
problem.  (Note that I didn't include the update parts of this code -
when a packet decrypts successfully, you need to update the
five_tuples list.)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Matt Caswell]

On 17/10/17 22:35, Martin Thomson wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
>> The following case (NAT box reboot) is problematic:
>>
>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>>host B (B.1);
>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
>> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
>> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
>>meanwhile);
>>
>> How is B.1 supposed to correctly interpret the bytes starting at offset
>> +11?  (For what it knows, it could be CID from A.1 or the length field
>> from A.2.)
> 
> I don't think that this is a problem.
> 
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
>   connection = 
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
> }

Just skimming this old thread...doesn't this fail in the case where the
five tuple has been reused? In that case five_tuples.lookup will return
an old stale connection which the server thinks is still valid so we
never get to lookup the connection id. With an explicit marking we would
not fail in this scenario.

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[yinxinxing]

1.   I mean that NewconnectionID message and the RequesConnectionID message 
should use the new record format (instead of standard DTLS1.2 record format). 
Besides, the CID in the record header shall not be the new CID.


2.   (c): Since the first two bits of 16-bit length variable is zero, we 
can use a  specifically-constructed CID like “11…” (or other proper format) 
to identify a CID packet.
(I have mentioned this in previous email and you gave some feedback:

1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t 
differentiate whether the packet from client is a “connection ID” packet or a 
standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced 
this problem)

Maybe we can add a new “ContentType” in the DTLS record format to help server 
identify the “connection ID” packet. In addition, you see the length of the 
record payload is limited by 2^14-1, this means the first two bits of “length” 
is zero. We could utilize this feature and set the first two bits or more bits 
of CID being one, e.g., ….(but the CID must be put between sequence number 
and length). When server finds  after sequence number, it knows this is a 
“connection ID” packet. However, I don’t know whether it is proper to use such 
magic number. In my view, adding new contenttype may be a choice.
As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID that 
would not be a valid length field. This can actually just have the leading bit 
set. As we're revising the DTLS 1.3 record format, we would need to do 
something different for that.
)


3.   For (d), I have some comments about its precondition. You see NAT 
device can reallocate the released port/IP address to client, which means the 
precondition doesn’t always hold.

发件人: Eric Rescorla [mailto:e...@rtfm.com]
发送时间: 2017年10月26日 12:05
收件人: yinxinxing
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft



On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing 
mailto:yinxinx...@huawei.com>> wrote:
Hi Ekr,

Sorry for the delay. I don’t quite understand “The way that this mechanism 
works is that it either replaces all of them or supplements the set.” I see the 
new CID is encrypted in the post-handshake message and transferred to the peer. 
So, the record header of this message needs to contain the “old” CID.

Yes. I don't understand what your question is.

When you send a new CID, you can either label it as  cid_immediate or 
cid_spare. "immediate" means "stop using all the other CIDs you have and 
"spare" means "this is a CID you can use in addition to the others you have.


Besides, I have summarized the ways of distinguishing the CID packet and 
standard packet that people have discussed in the mailing list:

a)   Adding new ContentType.

b)   Adding new version. (As you replied, since 1.3 is going to remove 
version field in the record header, so this choice may not be proper.)

c)   Using specifically-constructed CID. (I saw you replied that it would 
be a way for DTLS 1.2. But for 1.3, you want a different way.)

d)   By comparing the 5-tuple. Martin made this. (If I understand right) 
His idea is that first check the 5-tuple of the packet, if there is a match, 
then use the corresponding key. If there is no match, then treat the packet as 
a CID packet and find the CID in the packet according to the new format. But, 
the precondition for well working is that the 5-tuple of the CID packet will 
not be successfully matched in the receiver's 5-tuple table.


For the above choices, what do you think? Or do you have any other good 
solution to be updated in the draft?

I think we should do neither (a) nor (b). I don't really understand (c) but I 
think (d) is fine, though not the only technique implementors could use.

-Ekr



Regards,
Yin Xinxing

发件人: Eric Rescorla [mailto:e...@rtfm.com<mailto:e...@rtfm.com>]
发送时间: 2017年10月23日 20:13
收件人: yinxinxing
抄送: tls@ietf.org<mailto:tls@ietf.org>
主题: Re: [TLS] Connection ID Draft



On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing 
mailto:yinxinx...@huawei.com>> wrote:
Hi Ekr,

For the post-handshake messages in the draft, I have some comments.


1.   When one peer sends NewconnectionID message to the other, it uses a 
newly defined handshake type. This new CID is attached in the payload of the 
record message. But there must be some information for the receiver to know 
which CID is going to be updated. I mean that when sending new CID through the 
NewConnectionID message, the record header should include the “old” CID, so 
that the receiver knows which one to replace.
The way that this mechanism works is that it either replaces all of them or 
supplements the set. I'm not sure that this is the right dynamic, but I'd first 
want to see some worked through cases.


2.   In the draft, is the new CID encrypted? I suggest that the new CID 
(for the first time sending) can 

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing  wrote:

> Hi Ekr,
>
>
>
> Sorry for the delay. I don’t quite understand “The way that this
> mechanism works is that it either replaces all of them or supplements the
> set.” I see the new CID is encrypted in the post-handshake message and
> transferred to the peer. So, the record header of this message needs to
> contain the “old” CID.
>

Yes. I don't understand what your question is.

When you send a new CID, you can either label it as  cid_immediate or
cid_spare. "immediate" means "stop using all the other CIDs you have and
"spare" means "this is a CID you can use in addition to the others you have.



> Besides, I have summarized the ways of distinguishing the CID packet and
> standard packet that people have discussed in the mailing list:
>
> a)   Adding new ContentType.
>
> b)   Adding new version. (As you replied, since 1.3 is going to
> remove version field in the record header, so this choice may not be
> proper.)
>
> c)   Using specifically-constructed CID. (I saw you replied that it
> would be a way for DTLS 1.2. But for 1.3, you want a different way.)
>
> d)   By comparing the 5-tuple. Martin made this. (If I understand
> right) His idea is that first check the 5-tuple of the packet, if there is
> a match, then use the corresponding key. If there is no match, then treat
> the packet as a CID packet and find the CID in the packet according to the
> new format. But, the precondition for well working is that the 5-tuple of
> the CID packet will not be successfully matched in the receiver's 5-tuple
> table.
>
>
>
> For the above choices, what do you think? Or do you have any other good
> solution to be updated in the draft?
>

I think we should do neither (a) nor (b). I don't really understand (c) but
I think (d) is fine, though not the only technique implementors could use.

-Ekr



>
>
> Regards,
>
> Yin Xinxing
>
>
>
> *发件人:* Eric Rescorla [mailto:e...@rtfm.com]
> *发送时间:* 2017年10月23日 20:13
> *收件人:* yinxinxing
> *抄送:* tls@ietf.org
> *主题:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing 
> wrote:
>
> Hi Ekr,
>
>
>
> For the post-handshake messages in the draft, I have some comments.
>
>
>
> 1.   When one peer sends NewconnectionID message to the other, it
> uses a newly defined handshake type. This new CID is attached in the
> payload of the record message. But there must be some information for the
> receiver to know which CID is going to be updated. I mean that when sending
> new CID through the NewConnectionID message, the record header should
> include the “old” CID, so that the receiver knows which one to replace.
>
> The way that this mechanism works is that it either replaces all of them
> or supplements the set. I'm not sure that this is the right dynamic, but
> I'd first want to see some worked through cases.
>
>
>
> 2.   In the draft, is the new CID encrypted? I suggest that the new
> CID (for the first time sending) can be encrypted  to make sure that an
> attacker can not associate a new CID with an old CID. Let’s consider a case
> where an attacker wants to track an IOT device. If the newly generated CID
> is not encrypted when updating, the attacker can associate the new CID with
> the old one. Then, when the peer sends message with the new CID later, the
> attacker knows this packet is sent from the victim. If we encrypt the new
> CID when updating, this tracking problem can be avoided.
>
>
>
> TLS 1.3 post-handshake messages are always encrypted.
>
>
>
>  Another comment is about symmetrical CID.
>
> 1.   Consider a client sends a normal CID (CID length is not zero,
> named C-CID) to server, but the server doesn’t wants to use client’s CID
> and sends a CID generated by the server (named S-CID) to the client.
>
> No. The CID is for the client's benefit, so why would this be useful?
>
>
>
> At the same time, client needs to know server has ignored C-CID (which
> means the downlink application message from the server will not include
> C-CID), and client will use S-CID in its application message. Will the
> draft cover this scenario?
>
> No.
>
>
>
> -Ekr
>
>
>
>
>
> Yin Xinxing
>
>
>
> *发件人**:* Eric Rescorla [mailto:e...@rtfm.com]
> *发送时间**:* 2017年10月13日 21:00
> *收件人**:* yinxinxing
> *抄送**:* tls@ietf.org
> *主题**:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing  wrote:
>
> Hi Ekr,
>
>
>
> Thanks for your effort. The draft looks good. A few comments 

Re: [TLS] Connection ID Draft

[yinxinxing]

Hi Ekr,

Sorry for the delay. I don’t quite understand “The way that this mechanism 
works is that it either replaces all of them or supplements the set.” I see the 
new CID is encrypted in the post-handshake message and transferred to the peer. 
So, the record header of this message needs to contain the “old” CID.

Besides, I have summarized the ways of distinguishing the CID packet and 
standard packet that people have discussed in the mailing list:

a)   Adding new ContentType.

b)   Adding new version. (As you replied, since 1.3 is going to remove 
version field in the record header, so this choice may not be proper.)

c)   Using specifically-constructed CID. (I saw you replied that it would 
be a way for DTLS 1.2. But for 1.3, you want a different way.)

d)   By comparing the 5-tuple. Martin made this. (If I understand right) 
His idea is that first check the 5-tuple of the packet, if there is a match, 
then use the corresponding key. If there is no match, then treat the packet as 
a CID packet and find the CID in the packet according to the new format. But, 
the precondition for well working is that the 5-tuple of the CID packet will 
not be successfully matched in the receiver's 5-tuple table.


For the above choices, what do you think? Or do you have any other good 
solution to be updated in the draft?

Regards,
Yin Xinxing

发件人: Eric Rescorla [mailto:e...@rtfm.com]
发送时间: 2017年10月23日 20:13
收件人: yinxinxing
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft



On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing 
mailto:yinxinx...@huawei.com>> wrote:
Hi Ekr,

For the post-handshake messages in the draft, I have some comments.


1.   When one peer sends NewconnectionID message to the other, it uses a 
newly defined handshake type. This new CID is attached in the payload of the 
record message. But there must be some information for the receiver to know 
which CID is going to be updated. I mean that when sending new CID through the 
NewConnectionID message, the record header should include the “old” CID, so 
that the receiver knows which one to replace.
The way that this mechanism works is that it either replaces all of them or 
supplements the set. I'm not sure that this is the right dynamic, but I'd first 
want to see some worked through cases.


2.   In the draft, is the new CID encrypted? I suggest that the new CID 
(for the first time sending) can be encrypted  to make sure that an attacker 
can not associate a new CID with an old CID. Let’s consider a case where an 
attacker wants to track an IOT device. If the newly generated CID is not 
encrypted when updating, the attacker can associate the new CID with the old 
one. Then, when the peer sends message with the new CID later, the attacker 
knows this packet is sent from the victim. If we encrypt the new CID when 
updating, this tracking problem can be avoided.

TLS 1.3 post-handshake messages are always encrypted.

 Another comment is about symmetrical CID.

1.   Consider a client sends a normal CID (CID length is not zero, named 
C-CID) to server, but the server doesn’t wants to use client’s CID and sends a 
CID generated by the server (named S-CID) to the client.
No. The CID is for the client's benefit, so why would this be useful?


At the same time, client needs to know server has ignored C-CID (which means 
the downlink application message from the server will not include C-CID), and 
client will use S-CID in its application message. Will the draft cover this 
scenario?
No.

-Ekr



Yin Xinxing

发件人: Eric Rescorla [mailto:e...@rtfm.com<mailto:e...@rtfm.com>]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: tls@ietf.org<mailto:tls@ietf.org>
主题: Re: [TLS] Connection ID Draft



On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing 
mailto:yinxinx...@huawei.com>> wrote:
Hi Ekr,

Thanks for your effort. The draft looks good. A few comments are listed below.


1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t 
differentiate whether the packet from client is a “connection ID” packet or a 
standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced 
this problem)

Maybe we can add a new “ContentType” in the DTLS record format to help server 
identify the “connection ID” packet. In addition, you see the length of the 
record payload is limited by 2^14-1, this means the first two bits of “length” 
is zero. We could utilize this feature and set the first two bits or more bits 
of CID being one, e.g., ….(but the CID must be put between sequence number 
and length). When server finds  after sequence number, it knows this is a 
“connection ID” packet. However, I don’t know whether it is proper to use such 
magic number. In my view, adding new contenttype may be a choice.

As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID that 
would not be a valid length field. This can actually just have the leading bit 
set. As we're revisin

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Mon, Oct 23, 2017 at 2:22 PM, Benjamin Kaduk  wrote:

> On 10/23/2017 07:12 AM, Eric Rescorla wrote:
>
>  Another comment is about symmetrical CID.
>>
>> 1.   Consider a client sends a normal CID (CID length is not zero,
>> named C-CID) to server, but the server doesn’t wants to use client’s CID
>> and sends a CID generated by the server (named S-CID) to the client.
>>
> No. The CID is for the client's benefit, so why would this be useful?
>
>
>> At the same time, client needs to know server has ignored C-CID (which
>> means the downlink application message from the server will not include
>> C-CID), and client will use S-CID in its application message. Will the
>> draft cover this scenario?
>>
> No.
>
>
> That is to say, this draft does not consider symmetrical CIDs at all.
>

You could of course echo the other side's CID, but no.

-Ekr


> -Ben
>
> ___
> 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

Re: [TLS] Connection ID Draft

[Benjamin Kaduk]

On 10/23/2017 07:12 AM, Eric Rescorla wrote:
>
>  Another comment is about symmetrical CID.
>
> 1.   Consider a client sends a normal CID (CID length is not
> zero, named C-CID) to server, but the server doesn’t wants to use
> client’s CID and sends a CID generated by the server (named S-CID)
> to the client.
>
> No. The CID is for the client's benefit, so why would this be useful?
>  
>
> At the same time, client needs to know server has ignored C-CID
> (which means the downlink application message from the server will
> not include C-CID), and client will use S-CID in its application
> message. Will the draft cover this scenario?
>
> No.

That is to say, this draft does not consider symmetrical CIDs at all.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Mon, Oct 23, 2017 at 12:53 AM, yinxinxing  wrote:

> Hi Ekr,
>
>
>
> For the post-handshake messages in the draft, I have some comments.
>
>
>
> 1.   When one peer sends NewconnectionID message to the other, it
> uses a newly defined handshake type. This new CID is attached in the
> payload of the record message. But there must be some information for the
> receiver to know which CID is going to be updated. I mean that when sending
> new CID through the NewConnectionID message, the record header should
> include the “old” CID, so that the receiver knows which one to replace.
>
The way that this mechanism works is that it either replaces all of them or
supplements the set. I'm not sure that this is the right dynamic, but I'd
first want to see some worked through cases.

2.   In the draft, is the new CID encrypted? I suggest that the new CID
> (for the first time sending) can be encrypted  to make sure that an
> attacker can not associate a new CID with an old CID. Let’s consider a case
> where an attacker wants to track an IOT device. If the newly generated CID
> is not encrypted when updating, the attacker can associate the new CID with
> the old one. Then, when the peer sends message with the new CID later, the
> attacker knows this packet is sent from the victim. If we encrypt the new
> CID when updating, this tracking problem can be avoided.
>

TLS 1.3 post-handshake messages are always encrypted.

 Another comment is about symmetrical CID.
>
> 1.   Consider a client sends a normal CID (CID length is not zero,
> named C-CID) to server, but the server doesn’t wants to use client’s CID
> and sends a CID generated by the server (named S-CID) to the client.
>
No. The CID is for the client's benefit, so why would this be useful?


> At the same time, client needs to know server has ignored C-CID (which
> means the downlink application message from the server will not include
> C-CID), and client will use S-CID in its application message. Will the
> draft cover this scenario?
>
No.

-Ekr


>
>
> Yin Xinxing
>
>
>
> *发件人:* Eric Rescorla [mailto:e...@rtfm.com]
> *发送时间:* 2017年10月13日 21:00
> *收件人:* yinxinxing
> *抄送:* tls@ietf.org
> *主题:* Re: [TLS] Connection ID Draft
>
>
>
>
>
>
>
> On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing  wrote:
>
> Hi Ekr,
>
>
>
> Thanks for your effort. The draft looks good. A few comments are listed
> below.
>
>
>
> 1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t
> differentiate whether the packet from client is a “connection ID” packet or
> a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also
> introduced this problem)
>
> Maybe we can add a new “ContentType” in the DTLS record format to help
> server identify the “connection ID” packet. In addition, you see the length
> of the record payload is limited by 2^14-1, this means the first two bits
> of “length” is zero. We could utilize this feature and set the first two
> bits or more bits of CID being one, e.g., ….(but the CID must be put
> between sequence number and length). When server finds  after sequence
> number, it knows this is a “connection ID” packet. However, I don’t know
> whether it is proper to use such magic number. In my view, adding new
> contenttype may be a choice.
>
>
>
> As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID
> that would not be a valid length field. This can actually just have the
> leading bit set. As we're revising the DTLS 1.3 record format, we would
> need to do something different for that.
>
>
>
> 2.For DTLS 1.2, there is no NewConnectionID and
> RequestConnectionID message. DTLS 1.2 server and client also has the
> requirement to request for a new CID, and at present, many products still
> use DTLS1.2 and I believe it will continue to be used for a long time even
> if TLS/DTLS1.3 is published. My point is that we need a corresponding
> method for updating CID for DTLS1.2 too.
>
> In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really
> that excited about putting a lot of effort into enhancing TLS 1.2. The
> basic extension works fine for them, but if they want to change CIDs, then
> they should adopt DTLS 1.3.
>
>
>
> I don’t quite understand the following sentences
>
> “In DTLS 1.2, connection ids are exchanged at the beginning of the
>
>DTLS session only.  There is no dedicated "connection id update"
>
>message that allows new connection ids to be established mid-session,
>
>because DTLS 1.2 in general does not allow post-handshake messages
>
>that do not themselves begin other handshakes.”
>
>
>
> 

Re: [TLS] Connection ID Draft

[yinxinxing]

Hi Ekr,

For the post-handshake messages in the draft, I have some comments.


1.   When one peer sends NewconnectionID message to the other, it uses a 
newly defined handshake type. This new CID is attached in the payload of the 
record message. But there must be some information for the receiver to know 
which CID is going to be updated. I mean that when sending new CID through the 
NewConnectionID message, the record header should include the “old” CID, so 
that the receiver knows which one to replace.

2.   In the draft, is the new CID encrypted? I suggest that the new CID 
(for the first time sending) can be encrypted  to make sure that an attacker 
can not associate a new CID with an old CID. Let’s consider a case where an 
attacker wants to track an IOT device. If the newly generated CID is not 
encrypted when updating, the attacker can associate the new CID with the old 
one. Then, when the peer sends message with the new CID later, the attacker 
knows this packet is sent from the victim. If we encrypt the new CID when 
updating, this tracking problem can be avoided.

Another comment is about symmetrical CID.

1.   Consider a client sends a normal CID (CID length is not zero, named 
C-CID) to server, but the server doesn’t wants to use client’s CID and sends a 
CID generated by the server (named S-CID) to the client. At the same time, 
client needs to know server has ignored C-CID (which means the downlink 
application message from the server will not include C-CID), and client will 
use S-CID in its application message. Will the draft cover this scenario?

Yin Xinxing

发件人: Eric Rescorla [mailto:e...@rtfm.com]
发送时间: 2017年10月13日 21:00
收件人: yinxinxing
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft



On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing 
mailto:yinxinx...@huawei.com>> wrote:
Hi Ekr,

Thanks for your effort. The draft looks good. A few comments are listed below.


1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t 
differentiate whether the packet from client is a “connection ID” packet or a 
standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced 
this problem)

Maybe we can add a new “ContentType” in the DTLS record format to help server 
identify the “connection ID” packet. In addition, you see the length of the 
record payload is limited by 2^14-1, this means the first two bits of “length” 
is zero. We could utilize this feature and set the first two bits or more bits 
of CID being one, e.g., ….(but the CID must be put between sequence number 
and length). When server finds  after sequence number, it knows this is a 
“connection ID” packet. However, I don’t know whether it is proper to use such 
magic number. In my view, adding new contenttype may be a choice.

As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID that 
would not be a valid length field. This can actually just have the leading bit 
set. As we're revising the DTLS 1.3 record format, we would need to do 
something different for that.


2.For DTLS 1.2, there is no NewConnectionID and RequestConnectionID 
message. DTLS 1.2 server and client also has the requirement to request for a 
new CID, and at present, many products still use DTLS1.2 and I believe it will 
continue to be used for a long time even if TLS/DTLS1.3 is published. My point 
is that we need a corresponding method for updating CID for DTLS1.2 too.
In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really that 
excited about putting a lot of effort into enhancing TLS 1.2. The basic 
extension works fine for them, but if they want to change CIDs, then they 
should adopt DTLS 1.3.


I don’t quite understand the following sentences

“In DTLS 1.2, connection ids are exchanged at the beginning of the

   DTLS session only.  There is no dedicated "connection id update"

   message that allows new connection ids to be established mid-session,

   because DTLS 1.2 in general does not allow post-handshake messages

   that do not themselves begin other handshakes.”

The only post-handshake messages allowed in DTLS 1.2 are ClientHello and 
HelloRequest.


Besides, for CID in DTLS1.3, I think the corresponding responding messages of  
NewConnectionID and RequestConnectionID are also needed to ensure that the peer 
has received CID.

No, you use the ACK for these 
(https://tools.ietf.org/html/draft-ietf-tls-dtls13-01#section-7). This is one 
reason why there is not a straightforward port to DTLS 1.2 for these messages.


4.   The generation of CID should be more concrete. For example, using 
random number or a counter?
I explicitly did not want to do that, because there are a lot of valid ways to 
generate CID. This is also what we did in QUIC.

-Ekr



Regards,
Yin Xinxing

发件人: TLS [mailto:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] 代表 Eric 
Rescorla
发送时间: 2017年10月13日 7:14
收件人: tls@ietf.org<mailto:tls@ietf.org>
主题: [

Re: [TLS] Connection ID Draft

[Stephen Farrell]

On 22/10/17 17:04, Eric Rescorla wrote:
> On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell 
> wrote:
> 
>>
>>
>> On 22/10/17 16:41, Eric Rescorla wrote:
>>>
 Maybe the thing we could agree at this stage is that the cid scheme
 has to be usable in that one-message-per-day scenario and needs to
 provide some way that such messages aren't easily linkable based on
 cids.
>>>
>>> I think that's a requirement in some cases but not others. It might be
>>> best to settle for the others.
>>
>> Sorry, I'm not sure what you mean there. Are you saying that you think
>> the above requirement can't be met by a generally usable scheme?
>>
>> I agree that not all scenarios need to meet the req posited above.
>>
>> I'd worry that if DTLS1.3 can't meet the above requirement then folks
>> will invent something that does, which may be worse than using DTLS
>> in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
>> that DTLS really doesn't scale down quite that far, which'd I guess
>> argue that there's a need for some other security protocol for those
>> situations.
>>
> 
> It's not a matter of DTLS versus non-DTLS. 

Not sure tbh, ISTM there's a bunch of challenges in trying to
use the kind of lpwan technologies being developed with DTLS,
with cid just being one of those. But time will tell I guess,
and that's a different discussion.

> I am unaware of any method
> of providing conn-IDs that simultaneously meets the requirements of:
> 
> - Unlinkability
> - Being able to survive multiple conn-ID changes in one round-trip
>   (which is implicit in both the one-packet per day and the unknown
>   address changes scenarios)
> - Low bandwidth
> - Good receiver-side scaling (both state and computational)
> 

Fair enough - I can buy that the last above suffers when one tries
to satisfy all the rest. Maybe that means a WG draft ought have an
applicability statement section that captures the scenarios where
that particular cid extension is suitable.

I'll be sad though if the end result is to sacrifice unlinkability
which I fear will be the likely outcome in practice.

> This is a generic problem, not one limited to DTLS. And as I said earlier,
> to the extent to which we either need specific schemes that meet different
> subsets of these requirements or we come up with a better generic scheme,
> the extension-based approach accommodates it.

Again, maybe some applicability text as per the above would make
it clearer that the draft is describing one (though hopefully the
most commonly useful) scheme and that others may be needed in
other situations.

Cheers,
S.

PS: In case it helps, with the additions discussed earlier and
above, and with the understanding that exploring other cid schemes
for cases where this one isn't fully satisfactory isn't ruled
out, I think this draft would be a fine starting point for a WG
document.


> 
> 
> PS: I fully accept your point that purely napkin-based schemes aren't
>> good enough and if those're the only kind of hash-chain based proposals
>>
> seen, then the WG oughtn't go for one of those.
>>
> 
> We've seen others, and they fail the receiver-side scaling test, IMO
> 
> -Ekr
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell 
wrote:

>
>
> On 22/10/17 16:41, Eric Rescorla wrote:
> >
> >> Maybe the thing we could agree at this stage is that the cid scheme
> >> has to be usable in that one-message-per-day scenario and needs to
> >> provide some way that such messages aren't easily linkable based on
> >> cids.
> >
> > I think that's a requirement in some cases but not others. It might be
> > best to settle for the others.
>
> Sorry, I'm not sure what you mean there. Are you saying that you think
> the above requirement can't be met by a generally usable scheme?
>
> I agree that not all scenarios need to meet the req posited above.
>
> I'd worry that if DTLS1.3 can't meet the above requirement then folks
> will invent something that does, which may be worse than using DTLS
> in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
> that DTLS really doesn't scale down quite that far, which'd I guess
> argue that there's a need for some other security protocol for those
> situations.
>

It's not a matter of DTLS versus non-DTLS. I am unaware of any method
of providing conn-IDs that simultaneously meets the requirements of:

- Unlinkability
- Being able to survive multiple conn-ID changes in one round-trip
  (which is implicit in both the one-packet per day and the unknown
  address changes scenarios)
- Low bandwidth
- Good receiver-side scaling (both state and computational)

This is a generic problem, not one limited to DTLS. And as I said earlier,
to the extent to which we either need specific schemes that meet different
subsets of these requirements or we come up with a better generic scheme,
the extension-based approach accommodates it.


PS: I fully accept your point that purely napkin-based schemes aren't
> good enough and if those're the only kind of hash-chain based proposals
>
seen, then the WG oughtn't go for one of those.
>

We've seen others, and they fail the receiver-side scaling test, IMO

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Stephen Farrell]

On 22/10/17 16:41, Eric Rescorla wrote:
> 
>> Maybe the thing we could agree at this stage is that the cid scheme
>> has to be usable in that one-message-per-day scenario and needs to
>> provide some way that such messages aren't easily linkable based on
>> cids.
> 
> I think that's a requirement in some cases but not others. It might be
> best to settle for the others.

Sorry, I'm not sure what you mean there. Are you saying that you think
the above requirement can't be met by a generally usable scheme?

I agree that not all scenarios need to meet the req posited above.

I'd worry that if DTLS1.3 can't meet the above requirement then folks
will invent something that does, which may be worse than using DTLS
in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
that DTLS really doesn't scale down quite that far, which'd I guess
argue that there's a need for some other security protocol for those
situations.

S.

PS: I fully accept your point that purely napkin-based schemes aren't
good enough and if those're the only kind of hash-chain based proposals
seen, then the WG oughtn't go for one of those.




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Sun, Oct 22, 2017 at 8:23 AM, Stephen Farrell 
wrote:

>
> (Sorry for the slow response...)
>
> Two things below...
>
> On 13/10/17 16:58, Eric Rescorla wrote:
> > On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 13/10/17 15:29, Eric Rescorla wrote:
> >>> There are a number of cases where this is actually much harder to
> >> implement
> >>> than a design where one side dictates the connection ID. For instance,
> >>> consider a design where you have a pool of servers P1, P2, ... P_n
> with a
> >>> load balancer in front.
> >>> Each server i generates connection IDs of the form i || Random. The
> load
> >>> balancer then just looks at the first byte and routes to the
> appropriate
> >>> load balancer [0]. In this design, the LB can be totally stateless,
> >> whereas
> >>> in the design you propose, it has to (a) have a back-channel to the
> >> server
> >>> to get the initial conn-id (b), do crypto (c) store state for all the
> >> live
> >>> connections.
> >>
> >> Pre-pending a fixed length (known to both sides) load-balancer
> >> ID would be fine, sure. That'd change the function to something
> >> like:
> >> next-id = lb-id || H(foo||prev-id)
> >>
> >> So long as each load balancer is busy enough that still has the
> >> hard-to-link property I think. The length of the lb-id could be
> >> fixed or part of the negotiation, with zero being a fine length
> >> when there's no lb-id needed.
> >>
> >
> > Well, this is a lot more complicated for the client and unless you place
> > very strict limits on lb-id, it ends up with the server just dictating an
> > identifier to the client so you have the scheme in this draft.
> >
> >
> >
> >> I think this'd work ok regardless of who controls the initial id
> >> value, so long as we don't need ids to work like tickets (where
> >> the id value would be the ciphertext of some state info).
> >>
> >
> > That's actually a design that people consider quite often and has been
> > discussed
> > for QUIC.
>
> So, if the WG want to allow for such designs, then I think that'd
> be better explicitly stated as some level of requirement, e.g. to
> say that some aspect of the scheme needs to allow some cids to be
> an encrypted form of something else. (I do think allowing for such
> is quite reasonable.)
>

I'd be fine with adding that sort of text.


>> In addition, consider what happens when you get a CID you don't
> recognize.
> >>> It might be nonsense but it might be that there was a cryptic CID
> change
> >>> (e.g., the client did two changes but you missed a packet). You need to
> >>> decide the number of changes you're willing to tolerate and then the
> >> table
> >>> has to be that big times the number of connections (or you need to fill
> >> it
> >>> in whenever you get an unknown CID, which the attacker can send you at
> >> any
> >>> time).
> >>
> >> Yes, schemes like this can be worse when packets go missing
> >> around the time of an id change.
> >>
> >> However, I think with this scheme (which isn't even on a napkin
> >> yet, just these mails:-),
> >
> >
> > Sure but we contemplated a number of these designs for QUIC, so we're not
> > starting from scratch here.
> >
> >
> >
> >
> >> he sending side would just make the
> >> change when they want, and wouldn't signal that it's changed the
> >> id. So, in some cases (say if receivers store current and next,
> >> and id changes and packet losses are infrequent) a single packet
> >> drop would be just that and the id change wouldn't affect things
> >> at all. In the putative nb-IoT case I mentioned before then it
> >> could be a good bit worse unless the receiver stores a bunch of
> >> future ids. (I agree some work is needed to figure out if there's
> >> an acceptable scheme here, so for now I'm arguing that we not
> >> preclude such schemes when adopting your draft.)
> >>
> >> In figuring this out, I'd argue that we ought be comparing ideas
> >> like this against two things: 1) the simplest solution that does
> >> allow linkabillity and 2) the costs of setting up a new TLS
> >> session to avoid linkability. While this or similar schemes will
> >> look bad compared to (1), they will likely look pretty good
> >> compared to (2).
> >>
> >> Of course, how one evaluates such comparisons will depend on how
> >> serious a threat one considers linkabillity. I'd argue that many
> >> devices that'll need connections ids will be devices where the
> >> possibility of linkability could be a significant threat and where
> >> new TLS session establishment will be rare, so we therefore ought
> >> provide some good method of avoiding linkability.
> >>
> >
> > I'd say three things here:
> >
> > 1. First, as I said we considered a lot of different designs for
> providing
> > better unlinkability than the design in this draft, and none of the
> > ones that did significantly better had reasonable scaling properties.
> >
> > 2. The precise point of designing this as an

Re: [TLS] Connection ID Draft

[Stephen Farrell]

(Sorry for the slow response...)

Two things below...

On 13/10/17 16:58, Eric Rescorla wrote:
> On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell 
> wrote:
> 
>>
>> Hiya,
>>
>> On 13/10/17 15:29, Eric Rescorla wrote:
>>> There are a number of cases where this is actually much harder to
>> implement
>>> than a design where one side dictates the connection ID. For instance,
>>> consider a design where you have a pool of servers P1, P2, ... P_n with a
>>> load balancer in front.
>>> Each server i generates connection IDs of the form i || Random. The load
>>> balancer then just looks at the first byte and routes to the appropriate
>>> load balancer [0]. In this design, the LB can be totally stateless,
>> whereas
>>> in the design you propose, it has to (a) have a back-channel to the
>> server
>>> to get the initial conn-id (b), do crypto (c) store state for all the
>> live
>>> connections.
>>
>> Pre-pending a fixed length (known to both sides) load-balancer
>> ID would be fine, sure. That'd change the function to something
>> like:
>> next-id = lb-id || H(foo||prev-id)
>>
>> So long as each load balancer is busy enough that still has the
>> hard-to-link property I think. The length of the lb-id could be
>> fixed or part of the negotiation, with zero being a fine length
>> when there's no lb-id needed.
>>
> 
> Well, this is a lot more complicated for the client and unless you place
> very strict limits on lb-id, it ends up with the server just dictating an
> identifier to the client so you have the scheme in this draft.
> 
> 
> 
>> I think this'd work ok regardless of who controls the initial id
>> value, so long as we don't need ids to work like tickets (where
>> the id value would be the ciphertext of some state info).
>>
> 
> That's actually a design that people consider quite often and has been
> discussed
> for QUIC.

So, if the WG want to allow for such designs, then I think that'd
be better explicitly stated as some level of requirement, e.g. to
say that some aspect of the scheme needs to allow some cids to be
an encrypted form of something else. (I do think allowing for such
is quite reasonable.)

>> In addition, consider what happens when you get a CID you don't recognize.
>>> It might be nonsense but it might be that there was a cryptic CID change
>>> (e.g., the client did two changes but you missed a packet). You need to
>>> decide the number of changes you're willing to tolerate and then the
>> table
>>> has to be that big times the number of connections (or you need to fill
>> it
>>> in whenever you get an unknown CID, which the attacker can send you at
>> any
>>> time).
>>
>> Yes, schemes like this can be worse when packets go missing
>> around the time of an id change.
>>
>> However, I think with this scheme (which isn't even on a napkin
>> yet, just these mails:-),
> 
> 
> Sure but we contemplated a number of these designs for QUIC, so we're not
> starting from scratch here.
> 
> 
> 
> 
>> he sending side would just make the
>> change when they want, and wouldn't signal that it's changed the
>> id. So, in some cases (say if receivers store current and next,
>> and id changes and packet losses are infrequent) a single packet
>> drop would be just that and the id change wouldn't affect things
>> at all. In the putative nb-IoT case I mentioned before then it
>> could be a good bit worse unless the receiver stores a bunch of
>> future ids. (I agree some work is needed to figure out if there's
>> an acceptable scheme here, so for now I'm arguing that we not
>> preclude such schemes when adopting your draft.)
>>
>> In figuring this out, I'd argue that we ought be comparing ideas
>> like this against two things: 1) the simplest solution that does
>> allow linkabillity and 2) the costs of setting up a new TLS
>> session to avoid linkability. While this or similar schemes will
>> look bad compared to (1), they will likely look pretty good
>> compared to (2).
>>
>> Of course, how one evaluates such comparisons will depend on how
>> serious a threat one considers linkabillity. I'd argue that many
>> devices that'll need connections ids will be devices where the
>> possibility of linkability could be a significant threat and where
>> new TLS session establishment will be rare, so we therefore ought
>> provide some good method of avoiding linkability.
>>
> 
> I'd say three things here:
> 
> 1. First, as I said we considered a lot of different designs for providing
> better unlinkability than the design in this draft, and none of the
> ones that did significantly better had reasonable scaling properties.
> 
> 2. The precise point of designing this as an extension is that if we
> had a better design we could drop it in with a new extension code point,
> so accepting this design doesn't preclude anything.
> 
> 3. You seem to be claiming that your design has better linkability
> properties than the design in this draft, but as far as I can tell that's
> not correct. In both cases, either side can occasional

Re: [TLS] Connection ID Draft

[yinxinxing]

Hi Martin,

According to the code you described in previous email, ISTM your idea of 
parsing the standard packet and CID packet is using the 5-tuple. The benefit is 
that no new contenttype or version is needed. But the precondition for well 
working is that the 5-tuple of the CID packet will not be successfully matched 
in the receiver's 5-tuple table. However, this condition is not always true. 

If I misunderstand your idea, please correct me. Thanks.  

Yin Xinxing

-邮件原件-
发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Martin Thomson
发送时间: 2017年10月18日 16:08
收件人: Fossati, Thomas (Nokia - GB/Cambridge, UK)
抄送: tls@ietf.org
主题: Re: [TLS] Connection ID Draft

On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) 
 wrote:
> This is quite similar to the trial and error / heuristic that I was 
> mentioning in [1].

You didn't mention 5-tuples.  And it isn't trial and error: you use 5-tuple as 
your primary key and use connection ID to latch.

> Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails 
> to recognise A.1 as CID-enabled and sends it forward to the crypto 
> handler when it shouldn't.

As I said before, any connection without a connection ID monopolizes that 
5-tuple making it inaccessible to other connections.  I think that in this 
case: too bad.

> And the already discussed limitations:
> - Fragility on corner cases (e.g., the 5-tuple swap above);

I don't see how you can avoid this in the general case.  Any connection without 
connection ID is going to be hard to correlate if it moves.  As for the 
connection that does have a connection ID but moves on top of a connection that 
doesn't, I don't think that is an acceptable loss.

> - Forcing middleware to keep state;
> - Breaking wireshark & co unless they can see the whole session;

Both of these are acceptable to me.  Unless you can describe a middlebox use 
case that needs access to this information and can't deal with the solution 
that I described.  Wireshark and co will need to see the handshake if they want 
to decrypt and that's the only case that is important.

> - (Depending on the use case, the cost of the two lookups per record
>   on the parsing might have a performance impact.)

The second lookup only happens after a migration.  I neglected to mention that 
successful use of a connection ID causes the 5-tuple to be assigned to that 
connection; there's a trick there in that you need to watch for reordering, but 
it saves the double lookup.

___
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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

sorry for taking so long to replay.

> On 18/10/2017, 09:08, "Martin Thomson" 
> wrote:
> 
> On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> > This is quite similar to the trial and error / heuristic that I was
> > mentioning in [1].
> 
> You didn't mention 5-tuples.  And it isn't trial and error: you use
> 5-tuple as your primary key and use connection ID to latch.

We seem to have a slightly different opinion on the meaning of trial and
error :-)  But more importantly, we seem to disagree on whether parsing
a binary header is orthogonal to context lookup (either via 5-tuple or
CID) or not.

> > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails
> > to recognise A.1 as CID-enabled and sends it forward to the crypto
> > handler when it shouldn't.
> 
> As I said before, any connection without a connection ID monopolizes
> that 5-tuple making it inaccessible to other connections.  I think
> that in this case: too bad.

I'm not sure I agree with that.  CID should be the tie breaker exactly
in these situations.  When something like that happens, if your
implementation supports CID it should win/survive over one that doesn't.

> > And the already discussed limitations:i
> > - Fragility on corner cases (e.g., the 5-tuple swap above);
> 
> I don't see how you can avoid this in the general case.  Any
> connection without connection ID is going to be hard to correlate if
> it moves.  As for the connection that does have a connection ID but
> moves on top of a connection that doesn't, I don't think that is an
> acceptable loss.

I think you mean "I do think that is an acceptable loss", or "I don't
think that is an unacceptable loss", right?
 
> > - Forcing middleware to keep state;
> > - Breaking wireshark & co unless they can see the whole session;
> 
> Both of these are acceptable to me.  Unless you can describe a
> middlebox use case that needs access to this information and can't
> deal with the solution that I described.  Wireshark and co will need
> to see the handshake if they want to decrypt and that's the only case
> that is important.

For diagnostics, it'd be pretty useful if one could filter a capture by
CID and follow *that* session among lots of others.  Irrespective of
what's in the encrypted payloads (which one can probably get from the
endpoint, if needed).  This is one use case that seems very useful to me
and doesn't require wireshark to keep state.  I'm not saying that there
are no work-arounds: we know how to make do with pcap filters.  But I'd
prefer to design something that is simple and cheap to implement and use
in the first place, if possible.

What I'm asking for is a codepoint and an explicit length for the CID,
i.e., a total +1 byte per 1.2 record on the wire.  I'm not sure the
tiny saving we get with the current proposal justifies the increase in
complexity.

> > - (Depending on the use case, the cost of the two lookups per record
> >   on the parsing might have a performance impact.)
> 
> The second lookup only happens after a migration.

In the IoT use cases, re-binding during a sleep cycle is the common
pattern, so the second lookup is going to be fairly common.

> I neglected to mention that successful use of a connection ID causes
> the 5-tuple to be assigned to that connection; there's a trick there
> in that you need to watch for reordering, but it saves the double
> lookup.

The thing that makes me slightly nervous is that we are talking about
doing trial & errors (at least in my definition of the term) and other
implementation tricks to achieve the very trivial task of parsing a
binary header.  This is what makes red flags pop up and makes me
think that we can do better.

Cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Wed, Oct 18, 2017 at 9:39 AM, Simon Bernard 
wrote:

> This makes me think about if this is feasible/desirable to use connection
> id to do load balancing.
>
> I think about use cases where you have a cluster of server behind only one
> IP address. Often traffic will be load balanced by IP.
> But with UDP and Nat environment, the IP can change.
>
> Thx to CID, if client is redirected to the same server in the cluster,
> even if its IP has changed it will be able to communicate without new
> handshake.
> But if its IP has changed there is little chance than load balancer will
> balance it on the same server and so new handshake is needed. (unless
> server share their connection state)
>

The usual procedure is for the server and load balancer to coordinate on
the CID algorithm.
A trivial version would be for the server to generate the connection ID as
 || .

-Ekr


>
> Any thought about that ?
>
>
>
> Le 17/10/2017 à 23:35, Martin Thomson a écrit :
>
>> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
>> GB/Cambridge, UK)  wrote:
>>
>>> The following case (NAT box reboot) is problematic:
>>>
>>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>>> host B (B.1);
>>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
>>> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
>>> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
>>> meanwhile);
>>>
>>> How is B.1 supposed to correctly interpret the bytes starting at offset
>>> +11?  (For what it knows, it could be CID from A.1 or the length field
>>> from A.2.)
>>>
>> I don't think that this is a problem.
>>
>> connection = five_tuples.lookup(packet.five_tuple)
>> if (!connection) {
>>connection = connection_ids.lookup(packet[c
>> onnection_id_offset:connection_id_offset+connection_id_length])
>> }
>> if (!connection) {
>>// is this a ClientHello?  otherwise drop it
>> }
>>
>> Of course this doesn't help you with A.2, but that's why this draft
>> exists.
>>
>> If the server can insist on connection IDs from all clients (in the
>> far future perhaps, or for an entirely new protocol), then the code is
>> more simply:
>>
>> connection = connection_ids.lookup(packet[connection_id_offset:connection
>> _id_offset+connection_id_length])
>> if (!connection) {
>>// is this a ClientHello?  otherwise drop it
>> }
>>
>> I might be missing something fundamental here, but isn't the length
>>> encoded in the CID field on the wire?
>>>
>> Not by my understanding.  There isn't any need (the intent is to have
>> the CID only consumable by the entity that created it, and any others
>> that it collaborates with, like a load balancer).
>>
>> ___
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Simon Bernard]

This makes me think about if this is feasible/desirable to use 
connection id to do load balancing.


I think about use cases where you have a cluster of server behind only 
one IP address. Often traffic will be load balanced by IP.

But with UDP and Nat environment, the IP can change.

Thx to CID, if client is redirected to the same server in the cluster, 
even if its IP has changed it will be able to communicate without new 
handshake.
But if its IP has changed there is little chance than load balancer will 
balance it on the same server and so new handshake is needed. (unless 
server share their connection state)


Any thought about that ?


Le 17/10/2017 à 23:35, Martin Thomson a écrit :

On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:

The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
meanwhile);

How is B.1 supposed to correctly interpret the bytes starting at offset
+11?  (For what it knows, it could be CID from A.1 or the length field
from A.2.)

I don't think that this is a problem.

connection = five_tuples.lookup(packet.five_tuple)
if (!connection) {
   connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
}
if (!connection) {
   // is this a ClientHello?  otherwise drop it
}

Of course this doesn't help you with A.2, but that's why this draft exists.

If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:

connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
if (!connection) {
   // is this a ClientHello?  otherwise drop it
}


I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?

Not by my understanding.  There isn't any need (the intent is to have
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).

___
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

Re: [TLS] Connection ID Draft

[Nikos Mavrogiannopoulos]

On Wed, 2017-10-18 at 06:43 +, Fossati, Thomas (Nokia -
GB/Cambridge, UK) wrote:
> Hi Nikos,
> 
> On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos"  -boun...@ietf.org on behalf of n...@redhat.com> wrote:
> > Another worrying feature is that the client can make the server
> > send
> > up to 255 verbatim bytes on the wire of his choice. Why was this
> > feature added? Are there use cases related with it (intro doesn't
> > mention any), or it was only thought as a make it as generic as
> > possible approach? If it is the latter, I'd recommend to provide a
> > simple approach that covers the described use cases.
> > 
> > The same argument applies to the server being able to set such a
> > long
> > sequence of verbatim bytes to each of the client packets.
> 
> I'd like to get a better understanding of your concern here.
> Is it size?

I had in mind scenarios of using these bytes to make the peer of talk
another protocol with an unsuspecting party, or using the peer to
attack a middle box which parses packets, e.g, by attempting buffer
overflows to it.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:
> This is quite similar to the trial and error / heuristic that I was
> mentioning in [1].

You didn't mention 5-tuples.  And it isn't trial and error: you use
5-tuple as your primary key and use connection ID to latch.

> Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
> recognise A.1 as CID-enabled and sends it forward to the crypto handler
> when it shouldn't.

As I said before, any connection without a connection ID monopolizes
that 5-tuple making it inaccessible to other connections.  I think
that in this case: too bad.

> And the already discussed limitations:
> - Fragility on corner cases (e.g., the 5-tuple swap above);

I don't see how you can avoid this in the general case.  Any
connection without connection ID is going to be hard to correlate if
it moves.  As for the connection that does have a connection ID but
moves on top of a connection that doesn't, I don't think that is an
acceptable loss.

> - Forcing middleware to keep state;
> - Breaking wireshark & co unless they can see the whole session;

Both of these are acceptable to me.  Unless you can describe a
middlebox use case that needs access to this information and can't
deal with the solution that I described.  Wireshark and co will need
to see the handshake if they want to decrypt and that's the only case
that is important.

> - (Depending on the use case, the cost of the two lookups per record
>   on the parsing might have a performance impact.)

The second lookup only happens after a migration.  I neglected to
mention that successful use of a connection ID causes the 5-tuple to
be assigned to that connection; there's a trick there in that you need
to watch for reordering, but it saves the double lookup.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 17/10/2017, 22:35, "Martin Thomson"  wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK)  wrote:
> > The following case (NAT box reboot) is problematic:
> >
> > 1. Application '1' on host A (A.1) uses DTLS+CID with application
> >'1' on host B (B.1);
> > 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> > 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> > 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
> >meanwhile);
> >
> > How is B.1 supposed to correctly interpret the bytes starting at
> > offset +11?  (For what it knows, it could be CID from A.1 or the
> > length field from A.2.)
> 
> I don't think that this is a problem.
> 
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
>   connection = 
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
> }
> if (!connection) {
>   // is this a ClientHello?  otherwise drop it
> }

This is quite similar to the trial and error / heuristic that I was
mentioning in [1].

Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
recognise A.1 as CID-enabled and sends it forward to the crypto handler
when it shouldn't. 

It looks simple, but it introduces subtle complexity in that parsing is
not self-contained anymore: it depends on a couple of things (the
connection_ids and five_tuples stores) that in principle should have
nothing to do with making sense of an incoming record.

And the already discussed limitations:
- Fragility on corner cases (e.g., the 5-tuple swap above);
- Forcing middleware to keep state;
- Breaking wireshark & co unless they can see the whole session;
- (Depending on the use case, the cost of the two lookups per record
  on the parsing might have a performance impact.)

> > I might be missing something fundamental here, but isn't the length
> > encoded in the CID field on the wire?
> 
> Not by my understanding.  There isn't any need (the intent is to have
> the CID only consumable by the entity that created it, and any others
> that it collaborates with, like a load balancer).

You are right.  For some reasons, I was implying cid was encoded as a
variable-length array.  That said, I don't think saving 1 byte here is
worth the self-inflicted pain of making tshark unusable :-)

Cheers

[1] https://www.ietf.org/mail-archive/web/tls/current/msg24575.html

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nikos,

On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" 
 wrote:
> Another worrying feature is that the client can make the server send
> up to 255 verbatim bytes on the wire of his choice. Why was this
> feature added? Are there use cases related with it (intro doesn't
> mention any), or it was only thought as a make it as generic as
> possible approach? If it is the latter, I'd recommend to provide a
> simple approach that covers the described use cases.
> 
> The same argument applies to the server being able to set such a long
> sequence of verbatim bytes to each of the client packets.

I'd like to get a better understanding of your concern here.

Is it size?

Or is that it creates a potential sub-channel for sending identifying
information?

If the latter, it doesn't look much different from Random (except it's
larger)?  And then it gets hashed in the finished message, so, the room
for a third party to fiddle with it seems really limited.

Exactly, what risk do you foresee?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:
> The following case (NAT box reboot) is problematic:
>
> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
>host B (B.1);
> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
>meanwhile);
>
> How is B.1 supposed to correctly interpret the bytes starting at offset
> +11?  (For what it knows, it could be CID from A.1 or the length field
> from A.2.)

I don't think that this is a problem.

connection = five_tuples.lookup(packet.five_tuple)
if (!connection) {
  connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
}
if (!connection) {
  // is this a ClientHello?  otherwise drop it
}

Of course this doesn't help you with A.2, but that's why this draft exists.

If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:

connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
if (!connection) {
  // is this a ClientHello?  otherwise drop it
}

> I might be missing something fundamental here, but isn't the length
> encoded in the CID field on the wire?

Not by my understanding.  There isn't any need (the intent is to have
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

On 17/10/2017, 00:42, "Martin Thomson"  wrote:
> Thomas mentioned a heuristic, but I don't think that we need that.
> The only case that is difficult, and it's one that you might not care
> about, is one where a connection migrates to the same 5-tuple as an
> another connection.  There, you will match to an existing connection
> and find that the packet doesn't decrypt.  If the connection that you
> have associated with the 5-tuple supports and uses a connection ID,
> you can recover without trial decryption.  Otherwise, you just have to
> drop the packet when it doesn't decrypt.  (You could look up all the
> connections without connection IDs and use trial decryption, but why
> bother spending the effort and undermine the strength of your ciphers
> in that way.)

The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
   host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
   meanwhile);
 
How is B.1 supposed to correctly interpret the bytes starting at offset
+11?  (For what it knows, it could be CID from A.1 or the length field
from A.2.)
 
That's where the heuristic I mentioned in the other email comes in,
I think.

> Packet inspection boxes will have maintain state, I don't see a way
> around that.  The point here being that you need state to know how
> long the connection ID is, as well as how long it is.

I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?

Cheers

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Christian Huitema]

On 10/13/2017 7:29 AM, Eric Rescorla wrote:
>
>
> On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell
> mailto:stephen.farr...@cs.tcd.ie>> wrote:
>
>
> Hiya,
>
> On 13/10/17 14:56, Eric Rescorla wrote:
> > I've seen a number of designs like these, but in general they
> > have quite poor scaling properties. Can you describe the precise
> > design you have in mind so that we can analyze it.
>
> Sure, I can try...
>
> What I'm suggesting is that we define a way that a TLS
> node can change the connection ID to a new value that
> is hard to link to the old, as a function that can be
> used when the implementation chooses to use it.
> ...
> To change an id, pick a value foo that depends on the TLS
> session, e.g. like an extractor, and that is not visible
> to the network. Then set next-id to H(foo||prev-id) or
> some similar construct.
>

The problem with these encrypted or hashed schemes is the scaling part.
When you receive a packet from a yet-uncategorized 5-tuple, you have to
find the context. It can be "any of the contexts currently establish",
so you end up having to try them all, or maybe 1/2 of them in average.
That can be a lot of hashes or encryptions. If the sender can only send
some token that the recipient already expects, the demuxing becomes much
simpler.

I  like EKR's design. But it is a scheme that can be implemented, and
will work. There are edge cases, like controlling how many connection ID
a peer is willing to provide in advance.  And it tends to fall in the
"sharp knife" category of tools, i.e., you have better understand what
you are doing. In particular, you need a strategy for breaking the
linkability of sequence numbers, otherwise connection-id changes will
not accomplish much. But there may well be other issues, like time
correlation, or traffic patterns.

By the way, the often considered scenario is "what happens if the NAT
rebinds and the client does not know." I think a simple heuristic of
changing the connection ID when coming out of long sleeps would help a
lot there. NAT  bindings don't change much if the traffic is sustained.
But if the last packet was many seconds ago, the client would be wise to
just rotate the connection ID before sending anything new.

The other often considered scenarios are variations of the "mobile
network". The NAT rebinds because the mobile router moved to a new
connection, but the client does not know. I can't think of a good
heuristic there, but it certainly would be helpful if the mobile router
somehow informed the clients. That's probably easier to engineer than
changing connection ID on every packet.

-- 
Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

Going back to the start, it seems like there is an implied problem
with the draft in that connections with the identifier are hard to
distinguish from connections without.  Is that the main problem?

I can't see how an explicit marking helps.  If we admit the
possibility that some connections will not support this new feature,
then the recipient of packets is forced to identify those connections
by 5-tuple.  That's invariant.  Mixed deployments have some
challenges, but it's not completely unworkable.

My conclusion is that peers without connection ID support monopolize
the 5-tuple that they use, so that other connections can't migrate to
that 5-tuple.  They also cannot migrate to another 5-tuple.
Otherwise, things work out.

To reach that point, you have to realize that a mixed deployment has
to use 5-tuple as a primary key.  Packets that come in on a new
5-tuple are matched to connections opportunistically on what might or
might not be a connection ID.  If it is, then great (better make sure
you ask for the same length ID from all peers, or match on
prefixes...).  If it isn't, then the ciphertext will be read as a
connection ID, but even if it does identify a connection it will fail
to decrypt.

Thomas mentioned a heuristic, but I don't think that we need that.
The only case that is difficult, and it's one that you might not care
about, is one where a connection migrates to the same 5-tuple as an
another connection.  There, you will match to an existing connection
and find that the packet doesn't decrypt.  If the connection that you
have associated with the 5-tuple supports and uses a connection ID,
you can recover without trial decryption.  Otherwise, you just have to
drop the packet when it doesn't decrypt.  (You could look up all the
connections without connection IDs and use trial decryption, but why
bother spending the effort and undermine the strength of your ciphers
in that way.)

You can only truly dispense with the 5-tuple mapping if you can
guarantee that all of your clients support connection ID; at which
point you can drop that table and route on connection ID alone.

Packet inspection boxes will have maintain state, I don't see a way
around that.  The point here being that you need state to know how
long the connection ID is, as well as how long it is.

The middlebox issue is somewhat more interesting.  If it is *your*
middlebox, then there might be a case for routing connections with a
connection ID differently.  Based on the above, I would have said that
it might be better to only deploy that sort of configuration when you
can insist on receiving a connection ID.  An explicit marking helps,
but the cost is pretty high if we care about saving bits.

My suggestion for the middlebox is to use a longer connection ID and
include a MAC inside the connection ID.  It ends up being a longer
connection ID than the one QUIC uses, but it would allow the stateless
routing middlebox to identify packets with and without a connection ID
without any explicit marking.  That doesn't require any change to the
design.



On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla  wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.
>
> -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

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Mon, Oct 16, 2017 at 6:11 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK)
 wrote:

> Hi Matt,
>
> On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell" <
> tls-boun...@ietf.org on behalf of fr...@baggins.org> wrote:
> > Recently I met with Yin Xinxing and we have had much the same
> > conversation about what a Connection ID draft would need to do, and
> > how we could detect its use on the wire. Mechanisms we talked about
> > included setting something in the "length" field, using ContentType or
> > using version. IMO using "length" is just horrible. I'm also not keen
> > on version - it further complicates the "is this version greater than,
> > equal to, or less than this other version" question. It's already
> > slightly complicated in code that implements both TLS and DTLS due to
> > DTLS versions being high and decrementing for a new version. I foresee
> > lots of subtle bugs and problems from reusing "version". In my mind
> > ContentType is the way to go.
>
> Re: the length hack.  I agree with you that it is not the right way to
> go here.
>
> Re: CT vs version, a couple of quick thoughts:
> - I'm still unconvinced that CT is the right place to signify a change
>   in the parsing logics that effectively spans all CTs;
> - Besides, ISTM that version is the only field that would potentially
>   work for 1.3 as well as 1.2?
>

We expect to remove version in the 1.3 encrypted record format,

-Ekr


>
> Cheers,
>
> ___
> 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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Matt,

On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell"  wrote:
> Recently I met with Yin Xinxing and we have had much the same
> conversation about what a Connection ID draft would need to do, and
> how we could detect its use on the wire. Mechanisms we talked about
> included setting something in the "length" field, using ContentType or
> using version. IMO using "length" is just horrible. I'm also not keen
> on version - it further complicates the "is this version greater than,
> equal to, or less than this other version" question. It's already
> slightly complicated in code that implements both TLS and DTLS due to
> DTLS versions being high and decrementing for a new version. I foresee
> lots of subtle bugs and problems from reusing "version". In my mind
> ContentType is the way to go.

Re: the length hack.  I agree with you that it is not the right way to
go here.

Re: CT vs version, a couple of quick thoughts:
- I'm still unconvinced that CT is the right place to signify a change
  in the parsing logics that effectively spans all CTs;
- Besides, ISTM that version is the only field that would potentially
  work for 1.3 as well as 1.2?

Cheers,

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Sat, Oct 14, 2017 at 9:54 AM, Benjamin Kaduk  wrote:

> On 10/12/2017 06:13 PM, Eric Rescorla wrote:
>
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
>
> Comments welcome.
>
>
> I see it already got some good comments, so I'll try to stick to just new
> ones.
>
> Since a participant that wants to make use of DTLS CIDs might expect to
> talk to many peers, some of which do and some of which do not support the
> CID extension, it seems like the participant might want to always use the
> same cid_length for all its peers that support CIDs, to ease the parsing
> decision and CID lookup process, and we could mention this expectation. Or
> am I missing some reason why the CID would be easy to pick out of the
> ciphertext otherwise?
>

No, I think that's a good suggestion. PR Welcome :)


In the security/privacy considerations:
>
>An on-path adversary, who is able to observe the DTLS 1.2 protocol
>exchanges between the DTLS client and the DTLS server, is able to
>link the initial handshake to all subsequent payloads carrying the
>same connection id pair (for bi-directional communication).
>
> My first time reading this I thought that the text was only claiming that 
> linkability was possible if the initial handshake was observed, which is not 
> really needed.  It might be better to avoid mentioning the handshake at all 
> and just say that the attacker is able to link all observed payloads carrying 
> the same connection id pair as being exchanges between the same client and 
> server.
>
>
Yeah, that seems like a good point.

-Ekr


> -Ben
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Benjamin Kaduk]

On 10/12/2017 06:13 PM, Eric Rescorla wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
>
> Comments welcome.
>

I see it already got some good comments, so I'll try to stick to just
new ones.

Since a participant that wants to make use of DTLS CIDs might expect to
talk to many peers, some of which do and some of which do not support
the CID extension, it seems like the participant might want to always
use the same cid_length for all its peers that support CIDs, to ease the
parsing decision and CID lookup process, and we could mention this
expectation. Or am I missing some reason why the CID would be easy to
pick out of the ciphertext otherwise?

In the security/privacy considerations:

   An on-path adversary, who is able to observe the DTLS 1.2 protocol
   exchanges between the DTLS client and the DTLS server, is able to
   link the initial handshake to all subsequent payloads carrying the
   same connection id pair (for bi-directional communication).

My first time reading this I thought that the text was only claiming that 
linkability was possible if the initial handshake was observed, which is not 
really needed.  It might be better to avoid mentioning the handshake at all and 
just say that the attacker is able to link all observed payloads carrying the 
same connection id pair as being exchanges between the same client and server.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 13/10/17 15:29, Eric Rescorla wrote:
> > There are a number of cases where this is actually much harder to
> implement
> > than a design where one side dictates the connection ID. For instance,
> > consider a design where you have a pool of servers P1, P2, ... P_n with a
> > load balancer in front.
> > Each server i generates connection IDs of the form i || Random. The load
> > balancer then just looks at the first byte and routes to the appropriate
> > load balancer [0]. In this design, the LB can be totally stateless,
> whereas
> > in the design you propose, it has to (a) have a back-channel to the
> server
> > to get the initial conn-id (b), do crypto (c) store state for all the
> live
> > connections.
>
> Pre-pending a fixed length (known to both sides) load-balancer
> ID would be fine, sure. That'd change the function to something
> like:
> next-id = lb-id || H(foo||prev-id)
>
> So long as each load balancer is busy enough that still has the
> hard-to-link property I think. The length of the lb-id could be
> fixed or part of the negotiation, with zero being a fine length
> when there's no lb-id needed.
>

Well, this is a lot more complicated for the client and unless you place
very strict limits on lb-id, it ends up with the server just dictating an
identifier to the client so you have the scheme in this draft.



> I think this'd work ok regardless of who controls the initial id
> value, so long as we don't need ids to work like tickets (where
> the id value would be the ciphertext of some state info).
>

That's actually a design that people consider quite often and has been
discussed
for QUIC.



> In addition, consider what happens when you get a CID you don't recognize.
> > It might be nonsense but it might be that there was a cryptic CID change
> > (e.g., the client did two changes but you missed a packet). You need to
> > decide the number of changes you're willing to tolerate and then the
> table
> > has to be that big times the number of connections (or you need to fill
> it
> > in whenever you get an unknown CID, which the attacker can send you at
> any
> > time).
>
> Yes, schemes like this can be worse when packets go missing
> around the time of an id change.
>
> However, I think with this scheme (which isn't even on a napkin
> yet, just these mails:-),


Sure but we contemplated a number of these designs for QUIC, so we're not
starting from scratch here.




> he sending side would just make the
> change when they want, and wouldn't signal that it's changed the
> id. So, in some cases (say if receivers store current and next,
> and id changes and packet losses are infrequent) a single packet
> drop would be just that and the id change wouldn't affect things
> at all. In the putative nb-IoT case I mentioned before then it
> could be a good bit worse unless the receiver stores a bunch of
> future ids. (I agree some work is needed to figure out if there's
> an acceptable scheme here, so for now I'm arguing that we not
> preclude such schemes when adopting your draft.)
>
> In figuring this out, I'd argue that we ought be comparing ideas
> like this against two things: 1) the simplest solution that does
> allow linkabillity and 2) the costs of setting up a new TLS
> session to avoid linkability. While this or similar schemes will
> look bad compared to (1), they will likely look pretty good
> compared to (2).
>
> Of course, how one evaluates such comparisons will depend on how
> serious a threat one considers linkabillity. I'd argue that many
> devices that'll need connections ids will be devices where the
> possibility of linkability could be a significant threat and where
> new TLS session establishment will be rare, so we therefore ought
> provide some good method of avoiding linkability.
>

I'd say three things here:

1. First, as I said we considered a lot of different designs for providing
better unlinkability than the design in this draft, and none of the
ones that did significantly better had reasonable scaling properties.

2. The precise point of designing this as an extension is that if we
had a better design we could drop it in with a new extension code point,
so accepting this design doesn't preclude anything.

3. You seem to be claiming that your design has better linkability
properties than the design in this draft, but as far as I can tell that's
not correct. In both cases, either side can occasionally change
conn-ids (you can't change in each packet for the scaling reasons
I indicated). In your design one side does so unilaterally, but there
are packet loss concerns, and in the draft, you have to solicit new
conn-ids from the peer but as long as you have one you can change
unilaterally.

The primary difference in your design is that the IDs are opaque
rather than containing data contributed by the other side, but that
difference is immediately weakened as soon as you try to introduce
structure to hand

Re: [TLS] Connection ID Draft

[Hannes Tschofenig]

I would like to focus on one of the points raised below:
> 3.   We have a practical usecase in IoT. The IOT device, like
> intelligent water meter, sends one message per day, and goes to sleep.
> It wakes up in the second day and sends a message and then goes to
> sleep. If it always (or for a long time) use the same CID, there may be
> a risk of tracing IOT device or the owner of this device. Therefore, it
> is important to recommend user to update CID once it finishes sending
> message. For the CID in DTLS1.2, this becomes worse.


The user is typically not doing anything.


Without this CID extension you would send a full exchange or use session
resumption. This would allow someone in the middle to see the handshake.
In DTLS/TLS 1.2 this would reveal the client certificate.

With DTLS 1.3 and this extension you would hide the certificate and you
could echange new CIDs and switch between them every day. The source IP
address will most likely still reveal the subscriber (if you consider
some cooperation with the ISP).

So, you actually get pretty good privacy properties with DTLS 1.3 & CID
(unless some of the data center folks destroy it again with their fancy
extensions). With DTLS 1.2 there is only a performance benefit but the
privacy properties remain the same IMHO.

Ciao
Hannes


> 
>  
> 
> Regards,
> 
> Yin Xinxing
> 
>  
> 
> *发件人:*TLS [mailto:tls-boun...@ietf.org] *代表 *Eric Rescorla
> *发送时间:*2017年10月13日7:14
> *收件人:*tls@ietf.org
> *主题:*[TLS] Connection ID Draft
> 
>  
> 
> Hi folks,
> 
>  
> 
> I have just posted a first cut at a connection ID draft.
> 
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
>  
> 
> Comments welcome.
> 
>  
> 
> -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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

Hiya,

On 13/10/17 15:29, Eric Rescorla wrote:
> There are a number of cases where this is actually much harder to implement
> than a design where one side dictates the connection ID. For instance,
> consider a design where you have a pool of servers P1, P2, ... P_n with a
> load balancer in front.
> Each server i generates connection IDs of the form i || Random. The load
> balancer then just looks at the first byte and routes to the appropriate
> load balancer [0]. In this design, the LB can be totally stateless, whereas
> in the design you propose, it has to (a) have a back-channel to the server
> to get the initial conn-id (b), do crypto (c) store state for all the live
> connections.

Pre-pending a fixed length (known to both sides) load-balancer
ID would be fine, sure. That'd change the function to something
like:
next-id = lb-id || H(foo||prev-id)

So long as each load balancer is busy enough that still has the
hard-to-link property I think. The length of the lb-id could be
fixed or part of the negotiation, with zero being a fine length
when there's no lb-id needed.

I think this'd work ok regardless of who controls the initial id
value, so long as we don't need ids to work like tickets (where
the id value would be the ciphertext of some state info).

> 
> In addition, consider what happens when you get a CID you don't recognize.
> It might be nonsense but it might be that there was a cryptic CID change
> (e.g., the client did two changes but you missed a packet). You need to
> decide the number of changes you're willing to tolerate and then the table
> has to be that big times the number of connections (or you need to fill it
> in whenever you get an unknown CID, which the attacker can send you at any
> time).

Yes, schemes like this can be worse when packets go missing
around the time of an id change.

However, I think with this scheme (which isn't even on a napkin
yet, just these mails:-), the sending side would just make the
change when they want, and wouldn't signal that it's changed the
id. So, in some cases (say if receivers store current and next,
and id changes and packet losses are infrequent) a single packet
drop would be just that and the id change wouldn't affect things
at all. In the putative nb-IoT case I mentioned before then it
could be a good bit worse unless the receiver stores a bunch of
future ids. (I agree some work is needed to figure out if there's
an acceptable scheme here, so for now I'm arguing that we not
preclude such schemes when adopting your draft.)

In figuring this out, I'd argue that we ought be comparing ideas
like this against two things: 1) the simplest solution that does
allow linkabillity and 2) the costs of setting up a new TLS
session to avoid linkability. While this or similar schemes will
look bad compared to (1), they will likely look pretty good
compared to (2).

Of course, how one evaluates such comparisons will depend on how
serious a threat one considers linkabillity. I'd argue that many
devices that'll need connections ids will be devices where the
possibility of linkability could be a significant threat and where
new TLS session establishment will be rare, so we therefore ought
provide some good method of avoiding linkability.

Cheers,
S.






signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 13/10/17 14:56, Eric Rescorla wrote:
> > I've seen a number of designs like these, but in general they
> > have quite poor scaling properties. Can you describe the precise
> > design you have in mind so that we can analyze it.
>
> Sure, I can try...
>
> What I'm suggesting is that we define a way that a TLS
> node can change the connection ID to a new value that
> is hard to link to the old, as a function that can be
> used when the implementation chooses to use it.
>
> I'm not currently arguing that the ids should be changed
> for each packet. E.g. if a node is able to detect that the
> 5-tuple has just changed, it could use this then. If a
> node sends one packet per day over say an nb-IoT network
> where it might have a different IP address each time (not
> that we know how nb-IoT will operate, so I'm guessing:-)
> then it might make sense to do this for every packet.
>
> I assume ids are initialised in some reasonable way.
>
> To change an id, pick a value foo that depends on the TLS
> session, e.g. like an extractor, and that is not visible
> to the network. Then set next-id to H(foo||prev-id) or
> some similar construct.
>
> Receivers can store a set of ids calculated when the
> session is established. I'd guess storing two (current
> and next) might be a sensible thing to do.
>
> The inefficiently compared to simply incrementing the
> id value is to add another column to the lookup table I
> guess. I don't know if that's a big scaling deal or not.
>

There are a number of cases where this is actually much harder to implement
than a design where one side dictates the connection ID. For instance,
consider a design where you have a pool of servers P1, P2, ... P_n with a
load balancer in front.
Each server i generates connection IDs of the form i || Random. The load
balancer then just looks at the first byte and routes to the appropriate
load balancer [0]. In this design, the LB can be totally stateless, whereas
in the design you propose, it has to (a) have a back-channel to the server
to get the initial conn-id (b), do crypto (c) store state for all the live
connections.

In addition, consider what happens when you get a CID you don't recognize.
It might be nonsense but it might be that there was a cryptic CID change
(e.g., the client did two changes but you missed a packet). You need to
decide the number of changes you're willing to tolerate and then the table
has to be that big times the number of connections (or you need to fill it
in whenever you get an unknown CID, which the attacker can send you at any
time).

-Ekr

[0] This has non-ideal topology-hiding properties, but there are obvious
extensions with better properties.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Stephen Farrell]

Hiya,

On 13/10/17 14:56, Eric Rescorla wrote:
> I've seen a number of designs like these, but in general they
> have quite poor scaling properties. Can you describe the precise
> design you have in mind so that we can analyze it.

Sure, I can try...

What I'm suggesting is that we define a way that a TLS
node can change the connection ID to a new value that
is hard to link to the old, as a function that can be
used when the implementation chooses to use it.

I'm not currently arguing that the ids should be changed
for each packet. E.g. if a node is able to detect that the
5-tuple has just changed, it could use this then. If a
node sends one packet per day over say an nb-IoT network
where it might have a different IP address each time (not
that we know how nb-IoT will operate, so I'm guessing:-)
then it might make sense to do this for every packet.

I assume ids are initialised in some reasonable way.

To change an id, pick a value foo that depends on the TLS
session, e.g. like an extractor, and that is not visible
to the network. Then set next-id to H(foo||prev-id) or
some similar construct.

Receivers can store a set of ids calculated when the
session is established. I'd guess storing two (current
and next) might be a sensible thing to do.

The inefficiently compared to simply incrementing the
id value is to add another column to the lookup table I
guess. I don't know if that's a big scaling deal or not.

Cheers,
S.



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Fri, Oct 13, 2017 at 6:37 AM, Stephen Farrell 
wrote:

>
>
> On 13/10/17 00:13, Eric Rescorla wrote:
> > Hi folks,
> >
> > I have just posted a first cut at a connection ID draft.
> > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> >
> > Comments welcome.
>
> As a near-nit, I don't think "dismissed" is a good way
> to describe the analysis of some of the ideas that came
> up earlier.
>
> In particular, I still think there's merit in some use
> of a hash chains, to decrease linkability, even if that's
> not done for every packet.
>
> For example, considering a client that might detect an
> occasional change of 5-tuple, it could use something like
>
>id_n=H(foo||id_(n-1)) where foo is something dependent
>on the TLS session secrets (exporter-like)
>
> That way the TLS stacks can pre-calculate the next id
> (or a bunch of those) and then only lookups are needed
> (though the tables are bigger of course) just as with a
> static connection id.
>
> I'd argue that such designs not be dismissed.
>

I've seen a number of designs like these, but in general they
have quite poor scaling properties. Can you describe the precise
design you have in mind so that we can analyze it.

-Ekr


>
> I accept that the design needs to end up being efficient
> enough to get used but I don't think that we need to go
> for the simplest possible design, if that exposes 5-tuple
> linkages in ways that setting up new TLS sessions would
> not.
>
> Cheers,
> S.
>
>
> >
> > -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

Re: [TLS] Connection ID Draft

[Stephen Farrell]

On 13/10/17 00:13, Eric Rescorla wrote:
> Hi folks,
> 
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
> Comments welcome.

As a near-nit, I don't think "dismissed" is a good way
to describe the analysis of some of the ideas that came
up earlier.

In particular, I still think there's merit in some use
of a hash chains, to decrease linkability, even if that's
not done for every packet.

For example, considering a client that might detect an
occasional change of 5-tuple, it could use something like

   id_n=H(foo||id_(n-1)) where foo is something dependent
   on the TLS session secrets (exporter-like)

That way the TLS stacks can pre-calculate the next id
(or a bunch of those) and then only lookups are needed
(though the tables are bigger of course) just as with a
static connection id.

I'd argue that such designs not be dismissed.

I accept that the design needs to end up being efficient
enough to get used but I don't think that we need to go
for the simplest possible design, if that exposes 5-tuple
linkages in ways that setting up new TLS sessions would
not.

Cheers,
S.


> 
> -Ekr
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Matt Caswell]

On 13 October 2017 at 07:31, Fossati, Thomas (Nokia - GB/Cambridge,
UK)  wrote:
> To solve this, we'd need a place in the wire image of the record with
> semantics: "I'm carrying a CID."
>
> In 1.2, we could use CT or version.  (In 1.3, that would not be possible
> because the diet header doesn't have them - too bad.)  To me it'd make
> slightly more sense to use the version. (I had previous discussions on this
> topic with Nikos and he told me that though anyconnect does this version
> override for some reasons, there is no reported conflict with middle-boxes.)
> Also, there would be only one code-point to allocate, instead of separate
> code-points for each CID-enabled content type variant.  I'm happy to be
> convinced of the opposite, though.

Recently I met with Yin Xinxing and we have had much the same
conversation about what a Connection ID draft would need to do, and
how we could detect its use on the wire. Mechanisms we talked about
included setting something in the "length" field, using ContentType or
using version. IMO using "length" is just horrible. I'm also not keen
on version - it further complicates the "is this version greater than,
equal to, or less than this other version" question. It's already
slightly complicated in code that implements both TLS and DTLS due to
DTLS versions being high and decrementing for a new version. I foresee
lots of subtle bugs and problems from reusing "version". In my mind
ContentType is the way to go.


> I guess my main point here is to make sure we do as much as we can to allow
> simple, efficient, robust implementations, which are also, en passant,
> Wireshark-friendly, and leave heuristics-based approaches only for when
> there is no real alternative.

I fully agree here! It does occur to me that we could go further along
that road by swapping the order of the "length" and "cid" fields in
the new record header format, so that the new fields appear at the
end. Middlebox/wireshark code would then still be able to interpret it
because the beginning of the header is identical. The length would be
wrong of course (too short by cid_length bytes), but it would still be
parseable. That could be fixed (by adding the cid_length to the
payload length) but I'm not sure if its worth it.

Matt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Fri, Oct 13, 2017 at 1:11 AM, yinxinxing  wrote:

> Hi Ekr,
>
>
>
> Thanks for your effort. The draft looks good. A few comments are listed
> below.
>
>
>
> 1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t
> differentiate whether the packet from client is a “connection ID” packet or
> a standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also
> introduced this problem)
>
> Maybe we can add a new “ContentType” in the DTLS record format to help
> server identify the “connection ID” packet. In addition, you see the length
> of the record payload is limited by 2^14-1, this means the first two bits
> of “length” is zero. We could utilize this feature and set the first two
> bits or more bits of CID being one, e.g., ….(but the CID must be put
> between sequence number and length). When server finds  after sequence
> number, it knows this is a “connection ID” packet. However, I don’t know
> whether it is proper to use such magic number. In my view, adding new
> contenttype may be a choice.
>

As I said to Nikos, for DTLS 1.2, you can use a specially-constructed CID
that would not be a valid length field. This can actually just have the
leading bit set. As we're revising the DTLS 1.3 record format, we would
need to do something different for that.

2.For DTLS 1.2, there is no NewConnectionID and RequestConnectionID
> message. DTLS 1.2 server and client also has the requirement to request for
> a new CID, and at present, many products still use DTLS1.2 and I believe it
> will continue to be used for a long time even if TLS/DTLS1.3 is published.
> My point is that we need a corresponding method for updating CID for
> DTLS1.2 too.
>
In general, the WG is working on TLS 1.3, not TLS 1.2, so I'm not really
that excited about putting a lot of effort into enhancing TLS 1.2. The
basic extension works fine for them, but if they want to change CIDs, then
they should adopt DTLS 1.3.

I don’t quite understand the following sentences
>
> “In DTLS 1.2, connection ids are exchanged at the beginning of the
>
>DTLS session only.  There is no dedicated "connection id update"
>
>message that allows new connection ids to be established mid-session,
>
>because DTLS 1.2 in general does not allow post-handshake messages
>
>that do not themselves begin other handshakes.”
>

The only post-handshake messages allowed in DTLS 1.2 are ClientHello and
HelloRequest.


> Besides, for CID in DTLS1.3, I think the corresponding responding messages
> of  NewConnectionID and RequestConnectionID are also needed to ensure that
> the peer has received CID.
>

No, you use the ACK for these (
https://tools.ietf.org/html/draft-ietf-tls-dtls13-01#section-7). This is
one reason why there is not a straightforward port to DTLS 1.2 for these
messages.


> 4.   The generation of CID should be more concrete. For example,
> using random number or a counter?
>
I explicitly did not want to do that, because there are a lot of valid ways
to generate CID. This is also what we did in QUIC.

-Ekr


>
>
>
> Regards,
>
> Yin Xinxing
>
>
>
> *发件人:* TLS [mailto:tls-boun...@ietf.org] *代表 *Eric Rescorla
> *发送时间:* 2017年10月13日 7:14
> *收件人:* tls@ietf.org
> *主题:* [TLS] Connection ID Draft
>
>
>
> Hi folks,
>
>
>
> I have just posted a first cut at a connection ID draft.
>
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
>
>
> Comments welcome.
>
>
>
> -Ekr
>
>
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Thu, Oct 12, 2017 at 11:21 PM, Nikos Mavrogiannopoulos 
wrote:

> On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote:
> > Hi folks,
> >
> > I have just posted a first cut at a connection ID draft.
> > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
> I believe the major issue with that is the fact that the record packet
> format changes, but there is no way for a party in between to be able
> to determine the record packet format without keeping session state.
> Think not only of middle boxes, but of super-servers which may receive
> of a stray udp packet which they have to forward to the appropriate
> server [0]. With that change, they cannot figure whether the packet
> contains the CID or not in a deterministic way for a random CID.
>
> One can hack around that limitation by providing a CID which starts
> with 0x which is an illegal size currently for TLS or DTLS, but
> would have to worry with future extensions to the protocol which may
> increase the maximum size.


Yes, Thomas raised this issue as well. Unfortunately, we need to take the
structure of existing TLS records as it is, and at least in DTLS 1.3 we're
going to effort to shorten the header and I'm not eager to make everyone
pay on the wire whether they want to use connection ids or not.

In DTLS 1.2, as you say, it seems most straightforward to just provide
what would be an illegal length, as it seems pretty unlikely that any
future DTLS extension is going to allow 65k-sized packets. In DTLS 1.3,
we could probably steal one code point for this if we had to.


Another worrying feature is that the client can make the server send up
> to 255 verbatim bytes on the wire of his choice. Why was this feature
> added? Are there use cases related with it (intro doesn't mention any),
> or it was only thought as a make it as generic as possible approach? If
> it is the latter, I'd recommend to provide a simple approach that
> covers the described use cases.
>

Well, any connection ID feature of this type involves forcing the other
side to
send a certain amount of fixed verbatim data, so we're really just debating
how long that value ought to be. There are good reasons to allow at least
16 octets (in the super-server case you suggest, you might want the
connection ID
to to be an encrypted label for the actual server, and it's much more
convenient
to encrypt 16-byte quantities because that's AES's block size and many of
those machines will have AES-NI). And once you're carrying 16 bytes,
I don't see a big point in minimizing it below that. If people want an upper
limit that is greater than 16 (32?) I would be fine with that.

-Ekr


The same argument applies to the server being able to set such a long
> sequence of verbatim bytes to each of the client packets.
>
> regards,
> Nikos
>
> [0]. That was exactly my use case for introducing the CID info, as in
> openconnect server, the super-server receives the stray UDP packets
> arriving after a NAT disassociates existing connections.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[yinxinxing]

Hi Ekr,

Thanks for your effort. The draft looks good. A few comments are listed below.


1.   Based on the draft, for either DTLS1.2 or 1.3, server can’t 
differentiate whether the packet from client is a “connection ID” packet or a 
standard DTLS 1.2/1.3 packet. (I saw Thomas Fossati and Nikos also introduced 
this problem)

Maybe we can add a new “ContentType” in the DTLS record format to help server 
identify the “connection ID” packet. In addition, you see the length of the 
record payload is limited by 2^14-1, this means the first two bits of “length” 
is zero. We could utilize this feature and set the first two bits or more bits 
of CID being one, e.g., ….(but the CID must be put between sequence number 
and length). When server finds  after sequence number, it knows this is a 
“connection ID” packet. However, I don’t know whether it is proper to use such 
magic number. In my view, adding new contenttype may be a choice.



2.For DTLS 1.2, there is no NewConnectionID and RequestConnectionID 
message. DTLS 1.2 server and client also has the requirement to request for a 
new CID, and at present, many products still use DTLS1.2 and I believe it will 
continue to be used for a long time even if TLS/DTLS1.3 is published. My point 
is that we need a corresponding method for updating CID for DTLS1.2 too.

I don’t quite understand the following sentences

“In DTLS 1.2, connection ids are exchanged at the beginning of the

   DTLS session only.  There is no dedicated "connection id update"

   message that allows new connection ids to be established mid-session,

   because DTLS 1.2 in general does not allow post-handshake messages

   that do not themselves begin other handshakes.”

Besides, for CID in DTLS1.3, I think the corresponding responding messages of  
NewConnectionID and RequestConnectionID are also needed to ensure that the peer 
has received CID.


3.   We have a practical usecase in IoT. The IOT device, like intelligent 
water meter, sends one message per day, and goes to sleep. It wakes up in the 
second day and sends a message and then goes to sleep. If it always (or for a 
long time) use the same CID, there may be a risk of tracing IOT device or the 
owner of this device. Therefore, it is important to recommend user to update 
CID once it finishes sending message. For the CID in DTLS1.2, this becomes 
worse.



4.   The generation of CID should be more concrete. For example, using 
random number or a counter?


Regards,
Yin Xinxing

发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Eric Rescorla
发送时间: 2017年10月13日 7:14
收件人: tls@ietf.org
主题: [TLS] Connection ID Draft

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

First, thanks for the draft.

As discussed off-list, wrt framing / wire format, we probably have an 
opportunity to do slightly better than this, at least for 1.2.

The thing is that, since there is no flag in the record that says: "I'm 
carrying a CID", a receiver has no explicit way to know whether a record is 
coming from a CID-enabled session or a legacy-DTLS.

This ambiguity complicates the decoder because the receiving end now needs to 
implement a heuristic like:

-  let's first assume at offset +11 we have a CID

-  and then lookup the SAs store using this "maybe" CID

-  if found, OK (*), go on with the parsing

-  if not, fall back to assuming at offset +11 we have the length field 
and go on parsing

This is not ideal for a bunch of reasons:
1. For every incoming record, the receiver needs to lookup the CID store 
just to parse the record;
2. The implementation is more complicate;
3. Heuristics are intrinsically fragile and are known to deal badly with 
corner cases (think the many creative ways the many moving parts can conspire: 
5-tuple reshuffling because of NAT rebinding, lost state due to reboot/restart 
of one or more nodes, co-existing CID and legacy DTLS);
4. Wireshark & co will choke because they typically don't have enough 
context to handle the two different framings;

To solve this, we'd need a place in the wire image of the record with 
semantics: "I'm carrying a CID."

In 1.2, we could use CT or version.  (In 1.3, that would not be possible 
because the diet header doesn't have them - too bad.)  To me it'd make slightly 
more sense to use the version. (I had previous discussions on this topic with 
Nikos and he told me that though anyconnect does this version override for some 
reasons, there is no reported conflict with middle-boxes.)  Also, there would 
be only one code-point to allocate, instead of separate code-points for each 
CID-enabled content type variant.  I'm happy to be convinced of the opposite, 
though.

I guess my main point here is to make sure we do as much as we can to allow 
simple, efficient, robust implementations, which are also, en passant, 
Wireshark-friendly, and leave heuristics-based approaches only for when there 
is no real alternative.

Cheers, t

(*) assuming CID is entropic enough, which may or may not be the case.


On 13/10/2017, 00:13, "TLS on behalf of Eric Rescorla" 
mailto:tls-boun...@ietf.org> on behalf of 
e...@rtfm.com> wrote:

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Nikos Mavrogiannopoulos]

On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote:
> Hi folks,
> 
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

I believe the major issue with that is the fact that the record packet
format changes, but there is no way for a party in between to be able
to determine the record packet format without keeping session state.
Think not only of middle boxes, but of super-servers which may receive
of a stray udp packet which they have to forward to the appropriate
server [0]. With that change, they cannot figure whether the packet
contains the CID or not in a deterministic way for a random CID.

One can hack around that limitation by providing a CID which starts
with 0x which is an illegal size currently for TLS or DTLS, but
would have to worry with future extensions to the protocol which may
increase the maximum size.


Another worrying feature is that the client can make the server send up
to 255 verbatim bytes on the wire of his choice. Why was this feature
added? Are there use cases related with it (intro doesn't mention any),
or it was only thought as a make it as generic as possible approach? If
it is the latter, I'd recommend to provide a simple approach that
covers the described use cases.

The same argument applies to the server being able to set such a long
sequence of verbatim bytes to each of the client packets.

regards,
Nikos

[0]. That was exactly my use case for introducing the CID info, as in
openconnect server, the super-server receives the stray UDP packets
arriving after a NAT disassociates existing connections.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Thu, Oct 12, 2017 at 5:44 PM, Martin Thomson 
wrote:

> On Fri, Oct 13, 2017 at 11:21 AM, Eric Rescorla  wrote:
> > Maybe I'm missing something, but I don't think that that's correct. as
> long
> > as you're
> > willing to (a) restrict the jump to the same size as the transmitted
> part of
> > the sequence
> > number and (b) do a little trial decryption.
> >
> > We could, of course, also adopt the sequence number hopping scheme that
> we
> > use for QUIC, which works without trial decryption.
>
> Either works for me (I was operating on the assumption that we would
> avoid trial decryption).
>

Yeah, I think we should probably import the scheme from QUIC.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Fri, Oct 13, 2017 at 11:21 AM, Eric Rescorla  wrote:
> Maybe I'm missing something, but I don't think that that's correct. as long
> as you're
> willing to (a) restrict the jump to the same size as the transmitted part of
> the sequence
> number and (b) do a little trial decryption.
>
> We could, of course, also adopt the sequence number hopping scheme that we
> use for QUIC, which works without trial decryption.

Either works for me (I was operating on the assumption that we would
avoid trial decryption).

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Thu, Oct 12, 2017 at 5:07 PM, Martin Thomson 
wrote:

> On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla  wrote:
> >> The design for new connection IDs is clearly to handle the linkability
> >> issue, but the draft doesn't propose a solution for linking based on
> >> the monotonic increase of sequence numbers, or acknowledge the
> >> problem.
> >
> > Sorry, that's a good point that somehow didn't make it from my head into
> the
> > draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you
> > don't
> > need contiguous ranges except for anti-replay, so the sender can just
> jump
> > forward and then the receiver can keep a per-connid table. I've filed
> > https://github.com/ekr/dtls-conn-id/issues/2 to address this.
>
> That only true if we don't truncate the sequence number.
>

Maybe I'm missing something, but I don't think that that's correct. as long
as you're
willing to (a) restrict the jump to the same size as the transmitted part
of the sequence
number and (b) do a little trial decryption.

We could, of course, also adopt the sequence number hopping scheme that we
use for QUIC, which works without trial decryption.


>> We had comments about the length of the connection ID and the value
> >> being used as a covert channel.  That issue should at least be
> >> addressed in the security considerations.
> >
> >
> > I filed:
> > https://github.com/ekr/dtls-conn-id/issues/3
> >
> > That said, I'm not sure that any plausible length CID can avoid this.
>
> I agree.  Anything too short is going to be useless for the use cases
> we care about, but anything long enough to be useful is ripe for
> abuse.  We can acknowledge the problem though; and maybe suggest that
> endpoints that care about this could at least disable the extension.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Martin Thomson]

On Fri, Oct 13, 2017 at 10:49 AM, Eric Rescorla  wrote:
>> The design for new connection IDs is clearly to handle the linkability
>> issue, but the draft doesn't propose a solution for linking based on
>> the monotonic increase of sequence numbers, or acknowledge the
>> problem.
>
> Sorry, that's a good point that somehow didn't make it from my head into the
> draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you
> don't
> need contiguous ranges except for anti-replay, so the sender can just jump
> forward and then the receiver can keep a per-connid table. I've filed
> https://github.com/ekr/dtls-conn-id/issues/2 to address this.

That only true if we don't truncate the sequence number.

>> We had comments about the length of the connection ID and the value
>> being used as a covert channel.  That issue should at least be
>> addressed in the security considerations.
>
>
> I filed:
> https://github.com/ekr/dtls-conn-id/issues/3
>
> That said, I'm not sure that any plausible length CID can avoid this.

I agree.  Anything too short is going to be useless for the use cases
we care about, but anything long enough to be useful is ripe for
abuse.  We can acknowledge the problem though; and maybe suggest that
endpoints that care about this could at least disable the extension.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Connection ID Draft

[Eric Rescorla]

On Thu, Oct 12, 2017 at 4:33 PM, Martin Thomson 
wrote:
>
> The example shows the connection ID only being used after the
> handshake completes (that is, on epoch=3), but handshake records
> (epoch=2) use the same record format and we already know the
> preference of the peer when sending them.  I can see why you opted for
> this design (there is no way for the server to signal that it intends
> to use the connection ID before it starts to send it), but that could
> be addressed by moving the extension to the ServerHello.  The value is
> sent on every subsequent record, so there is no real gain in having
> the extension in EncryptedExtensions.  There is value in having record
> construction be consistent.
>

Oops. It *is* in the ServerHello. This is an inconsistency because an early
draft
had it in EncryptedExtensions and I just didn't update the example right.

"enables encryption early in the handshake phase the connection ID will
be enabled earlier. For this reason, the connection ID needs to go in
the DTLS 1.3 ServerHello.
"

It's fixed in the draft.


The design for new connection IDs is clearly to handle the linkability
> issue, but the draft doesn't propose a solution for linking based on
> the monotonic increase of sequence numbers, or acknowledge the
> problem.
>

Sorry, that's a good point that somehow didn't make it from my head into the
draft. In DTLS, it's actually pretty easy to handle this in DTLS b/c you
don't
need contiguous ranges except for anti-replay, so the sender can just jump
forward and then the receiver can keep a per-connid table. I've filed
https://github.com/ekr/dtls-conn-id/issues/2 to address this.

We had comments about the length of the connection ID and the value
> being used as a covert channel.  That issue should at least be
> addressed in the security considerations.
>

I filed:
https://github.com/ekr/dtls-conn-id/issues/3

That said, I'm not sure that any plausible length CID can avoid this.

-Ekr


>
>
> On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla  wrote:
> > Hi folks,
> >
> > I have just posted a first cut at a connection ID draft.
> > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> >
> > Comments welcome.
> >
> > -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

Re: [TLS] Connection ID Draft

[Martin Thomson]

This seems like a pretty solid design.  (Better in many ways to the
QUIC design, but then I might concede that the constraints are
different.)

The example shows the connection ID only being used after the
handshake completes (that is, on epoch=3), but handshake records
(epoch=2) use the same record format and we already know the
preference of the peer when sending them.  I can see why you opted for
this design (there is no way for the server to signal that it intends
to use the connection ID before it starts to send it), but that could
be addressed by moving the extension to the ServerHello.  The value is
sent on every subsequent record, so there is no real gain in having
the extension in EncryptedExtensions.  There is value in having record
construction be consistent.

The design for new connection IDs is clearly to handle the linkability
issue, but the draft doesn't propose a solution for linking based on
the monotonic increase of sequence numbers, or acknowledge the
problem.

We had comments about the length of the connection ID and the value
being used as a covert channel.  That issue should at least be
addressed in the security considerations.


On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla  wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.
>
> -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

[TLS] Connection ID Draft

[Eric Rescorla]

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls