As a co-author, I do support adoption, as this will help optimize client
connection racing.
Tommy
> On Nov 8, 2018, at 8:07 AM, Martin Thomson wrote:
>
> Adopt it. It's a small, useful feature.
> On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote:
>>
>> At TLS@IETF103, there was consensus in
Hi all,
Last week, we shipped the first developer seed of iOS 12.2. Among other
features, TLS 1.3 is now enabled by default for the entire system. All users of
Network.framework and NSURLSession APIs will now negotiate TLS 1.3. The number
of TLS 1.3 capable clients on the Internet should take q
The QUIC and TLS drafts were written together, and are quite similar as you
note. The intention is to use the TLS extension over TLS/TCP connections, and
the QUIC extension for QUIC/UDP.
I agree that QUIC as a protocol benefits more from the extension than TLS does,
but applications on top of b
> On Sep 24, 2019, at 7:32 AM, Stephen Farrell
> wrote:
>
>
> Hi Erik,
>
> FWIW, if browsers preferred this to an ESNI RR and
> we could forget the ESNI RR then I'd be ok with that.
> I'm not clear if they do or not though.
Regarding the status of which RR we use, I think the main goal for
I'm also supportive of this change, and in general of using HTTPSSVC for the
transmission of ESNI keys, speaking as an implementer at Apple.
With regards to the per-version structure, I agree with Steven that the
structure of the configuration should be able to change between versions. I
think
> On Nov 19, 2019, at 5:20 PM, Daniel Migault
> wrote:
>
> Hi,
>
> Just to followup the discussion. I support Viktor,'s proposal as it provides
> the ability to the client to specify what it wants rather than let the server
> guess. What I am wondering is whether we are catching all possib
> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni wrote:
>
> On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote:
>
>>>- 0x01-0xfe => client wants single-use tickets:
>>>+ send up to that many tickets on full handshake,
>>>
I support adoption of this work.
Best,
Tommy
> On Nov 21, 2019, at 1:36 PM, Sean Turner wrote:
>
> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG
> and the LAKE BOF, which is now a chartered WG [3]. After some discussions,
> the ADs suggested [4] that the TLS WG c
First off, thanks for the lively discussion on ticket reuse! I think it's a
valid use case and something that should continue to be discussed.
However, for the purposes of the WGLC for this draft,
draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It
seems that the nego
Hi Viktor,
> On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni wrote:
>
>> On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote:
>>
>> If the scope of a document can be continually expanded during last call, it
>> can be indefinitely postponed.
>
> I'm not proposing a change of scope. The document speci
Hi Nico,
As a point on the process, I don't think anyone is proposing rubber-stamping.
We are instead only suggesting that a set of work that has consensus does not
need to be held up by adding new work that does not have consensus.
The outcome of points raised during a WGLC does not need to be
> On Jan 31, 2020, at 6:14 PM, Stephen Farrell
> wrote:
>
>
> Hiya,
>
> I have no particular position about this draft but
> am curious about 2 things:
>
> #1 I don't get why it's not possible for postfix to
> determine the best way to manage tickets based on the
> destination port to whic
> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni wrote:
>
> On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote:
>
>>> Sorry, no idea what that above means. And is it simpler than the
>>> proposal under discussion (which got some fine-tuning in early
>>> feedback)?
>>
>> So one proposa
> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni wrote:
>
> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote:
>
>> If you did need a sentinel to indicate that you wanted to try to reuse
>> a ticket (which you can always try if you want), it would make more
&g
but potentially run
out.
Thanks,
Tommy
> On Feb 2, 2020, at 11:05 AM, Tommy Pauly
> wrote:
>
>
>
>> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni wrote:
>>
>> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote:
>>
>>> If you did need
ECHO is more fun to say, but I do see how it can be confusing (sounding like
some sort of ping) when out of the context of TLS.
To that end, I’d have a minor preference for “ETCH”.
Thanks,
Tommy
> On May 7, 2020, at 3:52 PM, Christopher Wood wrote:
>
> Erik raises some compelling reasons to c
ECH is good. Go for it!
Tommy
> On May 20, 2020, at 11:34 AM, Erik Nygren wrote:
>
>
>
> ECH works for me. (I really don't care between ECH and ETCH and thing both
> are fine.)
>
> Erik
>
>
>> On Wed, May 20, 2020 at 2:20 PM Christopher Wood
>> wrote:
>> On Tue, May 19, 2020, at 8
I support moving both drafts to standards track.
For ECH, there is a definite need to encrypt the SNI and other fields as a
complement to using encrypted DNS. We have implemented draft versions, and will
implement and use the final certain of ECH + HTTPSSVC.
For cTLS, this is a prime candidat
I've gone through my review of the draft as well, and I think this version
looks good!
Thanks,
Tommy
> On Apr 3, 2017, at 11:25 AM, David Schinazi wrote:
>
> Thanks for the update!
>
> I've reviewed -04 and I think the draft is ready to move forward.
>
> Regards,
> David Schinazi
>
>
>> On
Reviewer: Tommy Pauly
Review result: Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to
20 matches
Mail list logo
