ady been countered effectively - "repeating
points already countered is just disruptive noise."
On 10/24/2017 10:13 PM, Stephen Farrell wrote:
David,
I'll go back over your mails tomorrow but was struck by this...
On 24/10/17 23:39, David A. Cooper wrote:
I haven't even gotte
This question is based on your that belief that this protocol will
"escape" onto the public Internet, that browsers and other clients used
by individuals will feel forced to implement it, and that clients will
then be forced to enable the extension in order to get through
middleboxes that
I've already responded to this! Why are you wasting everyone's time by
asking the same questions over and over, even though I've already
clearly answered them?
An airplane/wifi provider might say "download our free browser," but it
won't rely on draft-rhrd-tls-tls13-visibility to snoop on its
No, they would not prevent those other
mechanisms. Where is your evidence that they would?
If the "attacker" controls the software that the client is using,
then it would set up the software to not check public-key pinning
or CT, if necessary. As Richard
With this extension, any middlebox anywhere
can drop traffic that is not tappable. Regardless of who controls
the clients and servers, we are now enabling entities to block
traffic unless you acquiesce. For example, an inflight wifi could
use this. Maybe,
Why would these schools settle for a half measure that only allows them
to snoop on traffic between their students and servers provide the keys
to their Internet traffic to the schools? If a school wants to snoop on
its students' traffic, it would do so in a much easier way than using
.
On 10/24/2017 04:01 PM, Ted Lemon wrote:
On Oct 24, 2017, at 3:59 PM, Ted Lemon <mel...@fugue.com>
wrote:
On Oct 24, 2017, at 3:54 PM,
David A. Cooper <david.coo...@nist.g
On 10/24/2017 04:24 PM, Ted Lemon
wrote:
On Oct 24, 2017, at 4:21 PM, David A. Cooper <david.coo...@nist.gov> wrote:
I'm not suggesting that cash strapped schools
would use one of these devices. I'm simply
PM, Yoav Nir wrote:
On 24 Oct 2017, at 22:54, David A. Cooper <david.coo...@nist.gov> wrote:
Why would these schools settle for a half measure that only allows them to snoop on traffic between their students and servers provide the keys to their Internet traffic to the scho
On 10/24/2017 05:18 PM, Salz, Rich
wrote:
And, I don't
buy the idea that if this extension is standardized that it
will be implemented in commonly-used browsers.
I would like to suggest that one additional value be added to the list
of GREASE values for named groups.
Section 2 of RFC 7919 says:
Codepoints in the "Supported Groups Registry" with a high byte of
0x01 (that is, between 256 and 511, inclusive) are set aside for
FFDHE groups.
I believe you are misinterpreting the text, but agree that it could be
made more clear.
Suppose that the ClientHello includes a supported_versions extensions
that contains two values, TLS 1.4 and TLS 1.0, and the server supports
TLS 1.3 and below. My interpretation of the current draft is
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
to get
the problematic implementation fixed.
David
On Wed, Sep 12, 2018 at 9:24 AM David A.
Cooper <david.coo...@nist.
I do not believe that "decode_error" would be the correct alert. As the
text currently says:
*Failures* Some post-quantum key exchange algorithms, including
ML-KEM, have non-zero probability of failure, meaning two honest
parties may derive different shared secrets. This would cause a
15 matches
Mail list logo
