Re: [TLS] Are we holding TLS wrong?

Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please

Re: [TLS] Connection ID in TLS

On 20/03/2018, 16:38, "TLS on behalf of John Mattsson" wrote: > At the Monday afternoon TLS session, it was stated that Connection ID > in TLS was unemployable in the wild due to middleboxes. Couldn't that > be solved by placing the

[TLS] a slightly different DTLSShortCiphertext

Hi all, In an off-list discussion on the wire format for DTLS CID Eric raised the point that a DTLSShortCiphertext header is completely stuffed, and it'd be impossible to grab another bit from the sequence number (already down to 12 bits) to signal the presence of a CID. I made a proposal for a

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

Hi Yoav, Thanks for the answers - much appreciated. On 27/01/2018, 19:31, "Yoav Nir" wrote: > The length field is byte-aligned. So any implementation of a TLS > parser or TLS proxy will do one of two things: > > 1. Consider the MSB to be a must-be-zero bit and drop any

[TLS] A question for TLS middle-box/middleware vendors/implementers

Hi TLS middle-box/middleware folks, If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is set, how does your software react? Is it going to drop the session/record or not bothering at all? I'm trying to understand a bit better whether and when it'd be safe to grab that bit and

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

On 24/01/2018, 15:53, "alang...@gmail.com on behalf of Adam Langley" <alang...@gmail.com on behalf of a...@imperialviolet.org> wrote: > On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote: > > > >

[TLS] extended headers for (D)TLS (and their use with connection-id)

How to make the existence of a connection id explicit on the wire? We have looked at a few different approaches - in reverse hackery order: defining new content types, using an invalid length and bumping the version number. Each of them comes with its small or big complications but, irrespective

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

Hi Martin, sorry for taking so long to replay. > On 18/10/2017, 09:08, "Martin Thomson" <martin.thom...@gmail.com> > wrote: > > On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote: > > T

Re: [TLS] Connection ID Draft

On 17/10/2017, 22:35, "Martin Thomson" <martin.thom...@gmail.com> wrote: > On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote: > > The following case (NAT box reboot) is problematic: > > > >

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

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

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

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] WG Call for adoption of draft-rescorla-tls-subcerts

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.foss...@nokia.com<mailto:thomas.foss...@nokia.com>> wrote: Hi Nick, I am not against delegated credentials, in fact I think it’s a good thing per se. I had expressed a couple of concerns at the tim

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

Hi Nick, I am not against delegated credentials, in fact I think it’s a good thing per se. I had expressed a couple of concerns at the time the call for adoption was first issued [1], which I think are still valid. Could you please comment on / add them to your pro-cons analysis? Cheers,

Re: [TLS] Suggestions in draft-mavrogiannopoulos-tls-cid

Hi Ashok, Thanks very much for your comments. See inline. Cheers, t On 07/07/2017, 14:44, "Raja ashok" > wrote: Hi Nikos, Hannes & Thomas, This ConnectionID concept is really a useful feature for a client node which faces a change in

Re: [TLS] draft-rescorla-tls-subcerts-01

Hi Hannes, On 24/04/2017 16:39, "Hannes Tschofenig" wrote: > On 04/21/2017 12:48 PM, Ilari Liusvaara wrote: > > Regarding clients, I think the draft specifies LURK as backup plan > > for clients that don't support subcerts (which causes some extra > > latency if

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

I've read draft-rescorla-tls-subcerts-01 and have a few comments. It's a well written document and the low-level mechanics look ok. However, I think I have a couple of issues with the overall design. First: it is not self-sufficient. The fact that clients must opt-in implies that servers must

Re: [TLS] draft-rescorla-tls-subcerts-01

On 21/04/2017 16:50, "Salz, Rich" wrote: > > Speaking as one of the co-authors of [1]: it is not completely clear to me > > what is the limitation in CT that would prevent it to cope with the > > pervasive use of short-term certificates. Can anyone shed a light on this? > > I

Re: [TLS] draft-rescorla-tls-subcerts-01

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara" wrote: On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote: > > What is also not clear to my why some of the certificate management > > protocols, which provide the