I've finally gotten to uploading
https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully
resolves the procedural issues (thanks again!). I've also revised the text
slightly after some off-list feedback about the risks of non-deterministic
failures.
I didn't add text about what mid
o,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
> *From:* David Benjamin [mailto
you receive this e-mail in error, please notify
the sender by
phone or email immediately and delete it!
From: David Benjamin [mailto:david...@chromium.org]
Sent: 02 August 2016 19:30
To: Steven Valdez; Raja ashok; tls@ietf.org
Subject: Re: [TLS] Keeping TLS extension points working
To expand on
>> [image: Company_logo]
>>
>> Phone:
>> Fax:
>> Mobile:
>> Email:
>> Huawei Technologies Co., Ltd.
>> Bangalore, India
>>
>> http://www.huawei.com
>> --
>>
>> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人
etf.org] On Behalf Of David Benjamin
Sent: 26 July 2016 04:02
To: tls@ietf.org
Subject: [TLS] Keeping TLS extension points working
Hi folks,
I'm not sure how this process usually works, but I would like to reserve a
bunch of values in the TLS registries to as part of an idea to keep our
Hubert Kario writes:
> On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> > On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario wrote:
> > > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> > >> Another source of interop failures is the firewall devices that do
> > >> anomaly
On Thursday, 28 July 2016 06:12:48 CEST Watson Ladd wrote:
> On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario wrote:
> > On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> >> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin
> >
> > wrote:
> >> > Hi folks,
> >> >
> >> > I'm not sure how
On Thu, Jul 28, 2016 at 3:28 AM, Hubert Kario wrote:
> On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
>> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin
> wrote:
>> > Hi folks,
>> >
>> > I'm not sure how this process usually works, but I would like to reserve a
>> > bunch of values
On Wednesday, 27 July 2016 09:50:18 CEST Wan-Teh Chang wrote:
> On Mon, Jul 25, 2016 at 3:32 PM, David Benjamin
wrote:
> > Hi folks,
> >
> > I'm not sure how this process usually works, but I would like to reserve a
> > bunch of values in the TLS registries to as part of an idea to keep our
> >
> On Jul 26, 2016, at 11:11, David Benjamin wrote:
>
> 1) “Updates: 5246 (if approved)” because typically extension documents don’t
> “update” the base specification. If you are suggesting that all
> implementations must support these values then an updates header makes sense.
> Note I’m su
On Wed, Jul 27, 2016 at 9:50 AM, Wan-Teh Chang wrote:
> Another source of interop failures is the firewall devices that do
> anomaly detection. Some of them will abort TLS handshakes if they see
> unknown TLS protocol versions or extensions in ClientHello. (They all
> seem to allow unknown cipher
On Tue, Jul 26, 2016 at 10:52 AM Sean Turner wrote:
> David,
>
> Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to
> make via the IANA considerations section. They enforce the registry policy
> established when we (the IETF/TLS WG) originally established the registry;
> th
David,
Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to make
via the IANA considerations section. They enforce the registry policy
established when we (the IETF/TLS WG) originally established the registry; the
available policies are found in RFC 5226 (and there’s some m
On Monday, 25 July 2016 23:32:41 CEST David Benjamin wrote:
> On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni
>
> wrote:
> > On Mon, Jul 25, 2016 at 10:32:29PM +, David Benjamin wrote:
> > > I'm not sure how this process usually works, but I would like to reserve
> >
> > a
> >
> > > bunch o
On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario wrote:
> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> > I would like to fix this by reserving a few values in our registries so
> > that clients may advertise random ones and regularly exercise these
> > codepaths in servers. If enough
On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn a
> large class of
On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni
wrote:
> On Mon, Jul 25, 2016 at 10:32:29PM +, David Benjamin wrote:
>
> > I'm not sure how this process usually works, but I would like to reserve
> a
> > bunch of values in the TLS registries to as part of an idea to keep our
> > extension poi
On Mon, Jul 25, 2016 at 10:32:29PM +, David Benjamin wrote:
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
>
> https://tools.ietf.org/html/draft-da
On Mon, Jul 25, 2016 at 6:32 PM David Benjamin
wrote:
> Hi folks,
>
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> https://tools.ietf.org/html/draft
Hi folks,
I'm not sure how this process usually works, but I would like to reserve a
bunch of values in the TLS registries to as part of an idea to keep our
extension points working. Here's an I-D:
https://tools.ietf.org/html/draft-davidben-tls-grease-00
(The name GREASE is in honor of AGL's rust
20 matches
Mail list logo
