[TLS] 答复: 答复: Connection ID Draft

(I mean that we give some warning and suggestion on the linkability, although there are lots of valid ways.) I miss reading the security consideration part, now, I have saw the warning of linkability. No problem now. Yin Xinxing 发件人: Eric Rescorla [mailto:e...@rtfm.com] 发送时间: 2017年10月14日

Re: [TLS] 答复: Connection ID Draft

On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing wrote: > Thanks Ekr. > > > > For “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.”, the key > point of describing the generation of CID is to avoid

Re: [TLS] 答复: Connection ID Draft

On Fri, Oct 13, 2017 at 7:36 PM, Eric Rescorla wrote: > > > On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing wrote: > >> Hi Hannes, >> >> "exchange new CIDs and switch between them every day" may not be a good >> choice for power constrained IOT devices. From

Re: [TLS] 答复: Connection ID Draft

On Fri, Oct 13, 2017 at 7:28 PM, yinxinxing wrote: > Hi Hannes, > > "exchange new CIDs and switch between them every day" may not be a good > choice for power constrained IOT devices. From the point of saving battery, > it is better to transfer the new CID to the other

[TLS] 答复: Connection ID Draft

Hi Hannes, "exchange new CIDs and switch between them every day" may not be a good choice for power constrained IOT devices. From the point of saving battery, it is better to transfer the new CID to the other peer in the application responding message in passing, instead of sending an

[TLS] 答复: Connection ID Draft

I agree with Stephen. It is essential to ensure the new connection ID couldn't be linked to the old one to avoid tracking risk. However, it is some sort of implementation issues, and there are more ways to do that(not only hash method). Maybe we can at least give suggestions or warning in the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Friday, 13 October 2017 14:45:35 CEST Stephen Farrell wrote: > On 13/10/17 12:05, Hubert Kario wrote: > > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: > >> (With the obvious caveat that I hate the whole > >> idea... :-) > > > > to be clear: me too > > IMO the more we hear

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

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

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] Publication of draft-rhrd-tls-tls13-visibility-00

I am opposed to the basic concept of injecting a third-party into the E2E TLS process. We don’t even have a TLS 1.3 RFC yet. We have no deployments yet. We have no insight into whether or not there is an actual need for this. How can we put this on-hold for, say, two years.

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

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

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] Publication of draft-rhrd-tls-tls13-visibility-00

On 13/10/17 12:05, Hubert Kario wrote: > On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: >> (With the obvious caveat that I hate the whole >> idea... :-) > > to be clear: me too IMO the more we hear of that the better > 1. Alice sends a share to Bob: g^a > 2. Bob sends

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: > (With the obvious caveat that I hate the whole > idea... :-) to be clear: me too > On 12/10/17 13:57, Hubert Kario wrote: > >> Anyway, I think key life length could be addressed in later drafts, but > >> the > >> inability of

Re: [TLS] Should CCM_8 CSs be Recommended?

CCM_8 is used in the IoT space because some SDOs believed that they need to optimize the transmission overhead. Clearly, this is not meant for general purpose use but rather for IoT only. Is it a good idea to truncate the authentication tag? I don't have an opinion about that but that's what the

Re: [TLS] Connection ID Draft

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

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