On Sun, Oct 30, 2016 at 2:13 PM, Martin Thomson
wrote:
> On 31 October 2016 at 06:58, Eric Rescorla wrote:
> > I'm ambivalent on this. OTOH, you're technically right, but OTOH it's
> just
> > one more conditional to save a few bytes (you need padding to exist
> anyway),
> > and if you're doing 0
On 31 October 2016 at 06:58, Eric Rescorla wrote:
> I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just
> one more conditional to save a few bytes (you need padding to exist anyway),
> and if you're doing 0-RTT, you're about to send a lot more bytes anyway.
0-RTT happens wh
I'm ambivalent on this. OTOH, you're technically right, but OTOH it's just
one more conditional to save a few bytes (you need padding to exist
anyway), and if you're doing 0-RTT, you're about to send a lot more bytes
anyway.
-Ekr
On Sun, Oct 30, 2016 at 12:52 PM, David Benjamin
wrote:
> Soun
Sounds reasonable.
One concern is the F5 bug's failure mode was a timeout rather than an
error, so, if you take away padding, the allowance in C.3 will not save
heterogenous deployments where some servers do 1.3 and some are old F5
servers. But given we're talking about a straight-up server bug no
(Trivial optimization warning)
Just perusing my draft and noticed that NSS pads a 0-RTT handshake,
which is not that surprising given that it's fairly beefy (it will get
even larger in -18). Since a 0-RTT handshake will break servers that
don't at least superficially understand TLS 1.3, maybe we
The IESG has approved the following document:
- 'A TLS ClientHello padding extension'
(draft-ietf-tls-padding-04.txt) as Proposed Standard
This document is the product of the Transport Layer Security Working
Group.
The IESG contact persons are Stephen Farrell and Kathleen Moriarty.
: draft-ietf-tls-padding-04.txt
Pages : 4
Date: 2015-09-08
Abstract:
This memo describes a TLS extension that can be used to pad
ClientHello messages to a desired size.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc
Benoit Claise has entered the following ballot position for
draft-ietf-tls-padding-03: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
for this? If so, it
> seems like the IANA section should still describe the code point being
> registered, or perhaps give a pointer to or description of the early
> allocation.
The OpenSSL tls1.h header file contains:
/*
* ExtensionType value for TLS padding extension.
*
Ben Campbell has entered the following ballot position for
draft-ietf-tls-padding-03: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
> On Sep 2, 2015, at 7:09 AM, Sean Turner wrote:
>
> On Sep 02, 2015, at 02:26, Yoav Nir wrote:
>
>>
>>> On Aug 31, 2015, at 11:36 PM, Alissa Cooper wrote:
>>>
>>> Alissa Cooper has entered the following ballot position fo
On Sep 02, 2015, at 02:26, Yoav Nir wrote:
>
>> On Aug 31, 2015, at 11:36 PM, Alissa Cooper wrote:
>>
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-t
On Sep 01, 2015, at 12:49, Eric Rescorla wrote:
>
> As Alissa, I was wondering why it wasn’t easier to fix the one
> implementation instead.
>
>
> Because it's widely fielded, and browsers don't know in advance what
> kind of server they are talking to.
The one thing I’ll add in addition to w
> On Aug 31, 2015, at 11:36 PM, Alissa Cooper wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-tls-padding-02: No Objection
>
> --
: draft-ietf-tls-padding-03.txt
Pages : 4
Date: 2015-09-01
Abstract:
This memo describes a TLS extension that can be used to pad
ClientHello messages to a desired size.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc
>
>
> As Alissa, I was wondering why it wasn’t easier to fix the one
> implementation instead.
>
>
Because it's widely fielded, and browsers don't know in advance what
kind of server they are talking to.
> The shepherd wrote: "Since then it has been found that this extension can
> server (sic)
Alvaro Retana has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Alissa Cooper has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
> On Aug 25, 2015, at 2:22 AM, Tom Ritter wrote:
>
> On 22 August 2015 at 19:28, Dave Garrett wrote:
>> Toggling solves the undesired bandwidth use concern stated by Tom by making
>> it fully optional on both sides. The even simpler route of just having to
>> check if there's bytes in the enc
On 24 August 2015 at 16:30, Stephen Farrell wrote:
>
>
> On 25/08/15 00:22, Tom Ritter wrote:
>> it would be _amazing_ if browser vendors enabled
>> browser extension authors to choose the padding strategy for
>> individual origins. Then we can crowdsource the effort.
>
> Excellent idea!
I belie
On 25/08/15 00:22, Tom Ritter wrote:
> it would be _amazing_ if browser vendors enabled
> browser extension authors to choose the padding strategy for
> individual origins. Then we can crowdsource the effort.
Excellent idea!
S.
___
TLS mailing list
On 22 August 2015 at 19:28, Dave Garrett wrote:
> Toggling solves the undesired bandwidth use concern stated by Tom by making
> it fully optional on both sides. The even simpler route of just having to
> check if there's bytes in the encrypted fragment other than the payload would
> avoid a lit
: draft-ietf-tls-padding-02.txt
Pages : 4
Date: 2015-08-24
Abstract:
This memo describes a TLS extension that can be used to pad
ClientHello messages to a desired size.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc
On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote:
> > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
> >> On 17 May 2015 at 14:32, Dave Garrett wrote:
> >>> Is it really necessary to have a separate application_data_padded content
> >>> type? It'd be simpler to just keep using e
Dave:
> On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
>> On 17 May 2015 at 14:32, Dave Garrett wrote:
>>> Is it really necessary to have a separate application_data_padded content
>>> type? It'd be simpler to just keep using existing types but amend it with a
>>> padding field and requi
On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
> On 17 May 2015 at 14:32, Dave Garrett wrote:
> > Is it really necessary to have a separate application_data_padded content
> > type? It'd be simpler to just keep using existing types but amend it with a
> > padding field and require it alwa
26 matches
Mail list logo
