On Fri, Oct 13, 2017 at 7:41 PM, yinxinxing <yinxinx...@huawei.com> 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 linkability between > new CID and old ones, although there are lots of valid ways. > I don't really get what you're proposing here. As I said, there are a lot of ways to generate connection IDs and it's not helpful to prescribe one. We might be able to require that it not be possible to distinguish whether two conn IDs are from the same connection with probability > \epsilon, but even that is notrivial if (for instance) they have a generation ID. So I'd prefer to describe the issue in the security considerations and leave the details up to implementations. -Ekr > > Regards, > > 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 <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., 1111….(but the CID must be put > between sequence number and length). When server finds 1111 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
