Below is an agenda for Friday's virtual interim meeting, followed by
the meeting information. This information is also available online
[1]. We are looking for volunteers to lead each agenda item. Please
respond on list or to the chairs directly if you're willing to do so.
Best,
Chris, Joe, and Se
> On Sep 12, 2018, at 10:58 AM, Christopher Wood
> wrote:
>
> Below is an agenda for Friday's virtual interim meeting, followed by
> the meeting information. This information is also available online
> [1]. We are looking for volunteers to lead each agenda item. Please
> respond on list or to
According to RFC 7685 there was at least one TLS implementation that
would hang the connection if it received a ClientHello record with a
TLSCiphertext.length between 256 and 511 bytes.
During some recent testing I believe that I have come across a
similar length int
Wow! That's a bizarre one. I don't think we've run into this one before,
but, from your description, any given implementation would only have a
1/256 chance of hitting it on every ClientHello change.
10 is a newline, so perhaps some implementation is doing a terrible job
detecting TLS vs. some pla
It would be unlikely to hit this bug in
practice. I just tried a test with Chromium 65. In the default
configuration, with a 9-byte server name, the TLSCiphertext.length
was 192 bytes. So, in order to hit the bug it would seem that the
server's DNS name would have
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 : Encrypted Server Name Indication for TLS 1.3
Authors : Eric Rescorla
Kazuh
Hi,
We have made available what we believe is a good starting point for
further discussion regarding tls-dnssec-chain draft.
While I thought we had reached some additional consensus in a side
meeting at IETF 102 that every use case was per definition restrictive,
and that thus downgrade protec
I may have a conflict with the call, so I've gone ahead and put some
opinion inline below...
On Wed, Sep 12, 2018 at 5:40 PM Paul Wouters wrote:
>
> Hi,
>
> We have made available what we believe is a good starting point for
> further discussion regarding tls-dnssec-chain draft.
>
> While I thou
On Wed, 12 Sep 2018, Richard Barnes wrote:
Speaking as one of the attendees, I do not agree with that conclusion.
What came to light in that meeting is that the assertive cases of DANE require
that the certificate
That is not what came to light. What came to light was that the
assertive use
Your responses here reveal a lot of the assumptions that you're reading in
here that are not actually true, e.g., those noted below.
On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters wrote:
> On Wed, 12 Sep 2018, Richard Barnes wrote:
>
> > Speaking as one of the attendees, I do not agree with that c
On Wed, 12 Sep 2018, Richard Barnes wrote:
DNS records have caching semantics. Those are only relevant for DNS
resolution. This is the TLS WG, not the DNS.
You are resolving a TLSA record via a TLS transport.
A zone owner sent a TLSA record in a TLS handshake. This document says nothing
11 matches
Mail list logo
