Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

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

Re: [TLS] Connection ID Draft

. 发件人: 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 <yinxinx...@huawei.com<mailto:yinxinx...@huawei.com>> wrote: Hi Ekr, Sorry for the delay. I don’t quit

Re: [TLS] Connection ID Draft

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 &g

Re: [TLS] Connection ID Draft

la [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 <yinxinx...@huawei.com<mailto:yinxinx...@huawei.com>> wrote: Hi Ekr

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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 > > > &g

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

(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

Re: [TLS] Connection ID Draft

(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) <thomas.foss...@nokia.com> wrote: > This is quite similar to the trial and error / heuristic that I was > mentioning in [1]. You didn

Re: [TLS] Connection ID Draft

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 /

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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)

Re: [TLS] Connection ID Draft

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 >

Re: [TLS] Connection ID Draft

On 10/13/2017 7:29 AM, Eric Rescorla wrote: > > > 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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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 >

Re: [TLS] Connection ID Draft

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 >

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

th 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日

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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 >

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

Re: [TLS] Connection ID Draft

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

[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