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
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 cid field after the length field?
Are you referring to slide 13
On 05/03/2018, 00:27, "Eric Rescorla" mailto:e...@rtfm.com>>
wrote:
I genuinely can't see what advantage we get by not having its
presence explicitly signalled. Could you elaborate a bit on that?
Well, you're making every packet 1 byte bigger, for starters.
If the cost of having simple, straigh
On 04/03/2018, 23:12, "Martin Thomson" wrote:
> We are about to remove that bit from the QUIC packet. I don't see any
> advantage in adding it here.
>
> Can you explain in more detail who you think consumes this bit?
Server or server-side middleware that doesn't know whether the packet
that nee
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 s
Hi Yoav,
On 28/01/2018, 19:38, "Yoav Nir" wrote:
> > What I was thinking was rather "once handshake is done and client has
> > successfully passed the SNI checks, just blindly copy the byte stream
> > across." I had this specific mental model (that of an HTTPS filter) in
> > my head, which of cou
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 length field
> that has i
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 gi
On 24/01/2018, 15:53, "alang...@gmail.com on behalf of Adam Langley"
wrote:
> On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) wrote:
> >
> > A few months ago, Nikos (can't remember if on this list or on a side
> > conve
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
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 connec
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
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 a
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
> mentio
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,
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 some
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 wheth
have functional TLS on the ability for CAs to maintain
high-availability issuance services. How much Delegated Credentials can be
rotated and diversified inside an organization is only limited by the
operational ability of the organization that has control of the EE private key.
Nick
On Tue, Jul 1
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, than
Hi Ashok,
Thanks very much for your comments.
See inline.
Cheers, t
On 07/07/2017, 14:44, "Raja ashok"
mailto:raja.as...@huawei.com>> wrote:
Hi Nikos, Hannes & Thomas,
This ConnectionID concept is really a useful feature for a client node which
faces a change in transport and network layer.
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 triggered).
> I didn't got that im
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 h
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 believe the concern
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 necessary level of automation, cannot be
> > used with CAs to r
Hi Thomas,
We encountered the same issue and suggested something similar in [1] --
although not at the same level of detail as you below.
I like your proposal, but I'm not convinced that overloading the semantics
of an already existing extension when used in combination with a specific
version of
Hi Achim,
On 16/11/2016 10:21, "TLS on behalf of Kraus Achim (INST/ESY1)"
wrote:
>I'm still wondering, why the "clashing" calculations (section 4) are only
>based on the number of clients and not also on the length of the hash
>chain.
I guess you are right. The left column should say "sessions
When Server sees this, it switches CID accordingly.
From: Martin Thomson mailto:martin.thom...@gmail.com>>
Date: Tuesday, 15 November 2016 10:12
To: "Fossati, Thomas (Nokia - GB)"
mailto:thomas.foss...@nokia.com>>
Cc: Nikos Mavrogiannopoulos mailto:n...@redhat.com>>,
On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections
>(that is, O(N)) when it gets a 5-tuple mismatch.
I don't think I follow. You'd use CID as primary key t
On 15/11/2016 07:36, "TLS on behalf of Martin Thomson"
wrote:
>On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos
>wrote:
>> TLDR; the privacy offered by this extension is the same as the privacy
>> of DTLS over UDP.
>
>I disagree. All the privacy considerations of the QUIC connection ID
>app
On 15/11/2016 03:51, "TLS on behalf of Martin Thomson"
wrote:
>On 15 November 2016 at 10:16, Eric Rescorla wrote:
>>> I'd be interested in an analysis of the potential privacy
>>> impacts of this. Isn't this more or less the same as doing
>>> SPUD-for-DTLS? (If not, sorry for dragging in controve
Hi Nikos,
On 14/11/2016 12:58, "TLS on behalf of Nikos Mavrogiannopoulos"
wrote:
>Hi,
> For draft-mavrogiannopoulos-dtls-cid-00 and we needed to extend the
>DTLS un-authenticated part of the DTLS record header with an additional
>field. That works well if this is the only draft ever extending
Hi Ilari,
On 08/07/2016 14:25, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara" wrote:
>However, turns out this doesn't actually work as well as hoped in
>practice. The problem is that client can't really change address
>voluntarily
>(even if it is behind CGNAT, it probably can't change th
Hi Nikos,
On 08/07/2016 10:55, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 09:29 +0000, Fossati, Thomas (Nokia - GB) wrote:
>
>> > > > How would the hash chain matching work for a server handling
>> > > > multiple
>> > > >
On 08/07/2016 10:05, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 08:59 +0000, Fossati, Thomas (Nokia - GB) wrote:
>
>> > How would the hash chain matching work for a server handling
>> > multiple
>> > clients?
>> Sorry, I'm no
Hi Nikos,
On 08/07/2016 09:44, "Nikos Mavrogiannopoulos" wrote:
>On Fri, 2016-07-08 at 08:34 +0000, Fossati, Thomas (Nokia - GB) wrote:
>> Hi Nikos, Stephen,
>>
>> It seems to me that both your views (high resistance to traceability
>> and
>> low
Hi Nikos, Stephen,
It seems to me that both your views (high resistance to traceability and
low resource investment on server side) can be accommodated in a single
scheme.
Going back to the hash chain proposal that Stephen did a few emails ago on
this same thread. If:
1. the length of the hash c
On 04/03/2016 07:58, "EXT Yuhong Bao" wrote:
>
>> From: thomas.foss...@nokia.com
>> To: a...@imperialviolet.org; tls@ietf.org
>> Date: Fri, 4 Mar 2016 07:10:06 +
>> Subject: Re: [TLS] Accepting that other SNI name types will never work.
>>
>> Trying agai
On 04/03/2016 08:42, "TLS on behalf of Martin Thomson"
wrote:
>On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB)
> wrote:
>> In CoRE we might need to allocate a new SNI NameType for non-DNS host
>> names [1].
>>
>> Removing SNI extensibility woul
Trying again...
> Hi Adam,
In CoRE we might need to allocate a new SNI NameType for non-DNS host
names [1].
Removing SNI extensibility would make it unfeasible.
Cheers, t
[1]
https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#section
-3.3
>On 03/03/2016 18:49, "TLS on beha
Hi Adam,
On 03/03/2016 18:49, "TLS on behalf of Adam Langley" wrote:
>The Server Name Indication (SNI) extension in TLS has a provision to
>provide names other than host names[1]. None have even been defined to
>my knowledge, but it's there.
>
>OpenSSL (and possibly others) have had a long-stand
40 matches
Mail list logo
