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
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 t
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.
Sectio
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
er? It would be good to get
the problematic implementation fixed.
David
On Wed, Sep 12, 2018 at 9:24 AM David A.
Cooper &l
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, u
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
draft-rhr
e attacker.
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
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 si
#x27;s knowledge.
On 10/24/2017 04:38 PM, Yoav Nir wrote:
On 24 Oct 2017, at 22:54, David A. Cooper 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 Inter
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.
n,
even though they have already 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
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 would
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 no
I am also against adoption.
I would not be against a draft that made deployment recommendations, if
RFC 9325 was considered insufficient. (Although I don't like the idea of
suggesting that TLS 1.2 without support for quantum-resistant
cryptography is a recommended long-term solution.) However,
e document is profiling existing capabilities, not describing
bugs that can only be addressed by defining a new extension.
On 11/26/24 6:20 PM, Peter Gutmann wrote:
David A. Cooper writes:
what bugs would still remain that TLS-LTS fixes?
This is another thing that's already answered in
For me, the question of TLS-LTS or TLS 1.3. If TLS-LTS is a bug fix,
then what bugs does it fix that can not be fixed without defining a new
extension? If it were replaced with a guidance document that said
clients and servers MUST only support cipher suites X, Y, and Z, MUST
support encrypt-th
18 matches
Mail list logo
