Hi Chris,
Thank you for writing down the PRs describing possible designs that we
might adopt. I think it helps a lot in understanding the details and
making accurate comparisons.
My comments inline.
2019年2月27日(水) 8:19 Christopher Wood :
>
> Hi folks,
>
> Below are two PRs that seek to address
The following errata report has been submitted for RFC8448,
"Example Handshake Traces for TLS 1.3".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5645
--
Type: Technical
Reported by: Anthony
On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 28/02/2019 01:41, Eric Rescorla wrote:
> > I think you're misunderstanding the scenario here: we have two CDNs A and
> > B, and some switching service in front, so that when you lookup
> example.com,
> > you get a CNAME to A
Hiya,
On 28/02/2019 01:41, Eric Rescorla wrote:
> I think you're misunderstanding the scenario here: we have two CDNs A and
> B, and some switching service in front, so that when you lookup example.com,
> you get a CNAME to A or B, and then you get the ESNIKeySet
(ESNIKeySet is a type you've
On Wed, Feb 27, 2019 at 5:24 PM Stephen Farrell
wrote:
>
> Hiya,
>
> First, I think both are wrong:-)
>
> If there are really different ESNI private value holders,
> then each of those should provide separate ESNIKeys RR value
> instances
Yes, this is the idea
and the set of all of those
Despite the additional complexity of #137, I think it's probably the better
approach (and I would be fine with the simplification, if that makes it more
palatable). Particularly when multi-CDN is used, there's a lot of logic
involved in generating the "right" A/ record in response to a
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : Connection Identifiers for DTLS 1.2
Authors : Eric Rescorla
Hannes
Hi Eric,
Our goal is to have an RFC published as Informational and with the Not
Recommended status. We felt having this approved through the IETF process vs
just ISE would be beneficial to those wishing to adopt, and getting community
review is also helpful to us and those we represent.
I
Hi Hanno,
No, the tests have not been published. I can look at trying to make this data
publicly available but I cannot guarantee that.
Tests were generally done with AES and SHA hashing. One reason for this is
that many in this industry have incorporated some hardware-based crypto
Hi folks,
Below are two PRs that seek to address the multi-CDN issue discussed
on this list and in meetings:
1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136
2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137
#136 implements the combined or stapled record approach discussed
On Wednesday, 27 February 2019 13:52:57 CET Stephen Farrell wrote:
> On 27/02/2019 12:30, Hubert Kario wrote:
> > I'm not sure which part for the key_share extension you mean as being
> > empty, but the key_exchange in the KeyShareEntry can't be empty, per RFC
> > 8446,>
> > Section 4.2.8:
> >
On 27/02/2019 12:30, Hubert Kario wrote:
> I'm not sure which part for the key_share extension you mean as being empty,
> but the key_exchange in the KeyShareEntry can't be empty, per RFC 8446,
> Section 4.2.8:
>
> struct {
> NamedGroup group;
> opaque
Hi,
The document repeats the requirement of low latency several times. It would be
interesting to know which platforms/networks/deployments you have in mind. My
understanding is that HMAC-SHA-256 only have better latency than AES on a
little bit longer messages where the larger block size
On Wednesday, 27 February 2019 09:54:17 CET Stephen Farrell wrote:
> Hiya,
>
> On 27/02/2019 01:57, Sean Turner wrote:
> > This messages closes the WGLC for draft-ietf-tls-grease. The draft
> > will progress as is because we received no WGLC comments.
>
> Apologies for missing the WGLC. I've
I take no position on whether this is a good idea or not. Regarding the draft
itself, I was expecting to see a clear definition of the integrity check
computation in terms of an AEAD-Encrypt computation. Something along the lines
of:
AEAD-Encrypt-HMAC(write_key, nonce, additional_data,
Hi,
On Tue, 26 Feb 2019 21:26:45 +
Jack Visoky wrote:
> We have done tests on this and it there is a difference.
Have these tests in any way been published? Because otherwise it's a
very weak argument.
There are some obvious questions, e.g.:
* What algorithm implementation was tested, was
Hiya,
On 27/02/2019 01:57, Sean Turner wrote:
> This messages closes the WGLC for draft-ietf-tls-grease. The draft
> will progress as is because we received no WGLC comments.
Apologies for missing the WGLC. I've just read this and fully
support it progressing. I have one question though:
The
17 matches
Mail list logo
