Terry Manderson has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes
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 https://www.i
Without taking a position on the security matter: this has been part of the
TLS design for 20+ years, and therefore has had multiple LCs and WG and
IETF consensus, so it would take a pretty strong set of arguments to change
now. I've debugged a lot of TLS interop issues, and as a practical matter,
Colm MacCárthaigh writes:
> On the specific suggestion of having more granular error codes, I think
> this is a dangerous direction to take lightly; there's at least one
> instance where granular TLS alert messages have directly led to security
> issues by acting as oracles that aided the attacker
Thanks for putting this together! I’m in favor of the mechanism and look
forward to discussing it. Negotiating with signature_algorithms is a simple way
to roll this out, it fits in cleanly with the key schedule, and the benefits
outlined in the introduction (PRNG hardening, plausible deniabilit
> On Mar 6, 2018, at 17:28, Benjamin Kaduk wrote:
>
> On 03/05/2018 05:41 AM, Tony Putman wrote:
>> Should the TLS 1.3 draft request a new registry for psk_key_exchange_modes?
>> Initially, I thought that there was no way to extend it, but the email below
>> from
>> Martin Thomson suggests a
On Mar 6, 2018, at 5:35 PM, Colm MacCárthaigh wrote:
> There's a general conjecture that the more information that is provided to
> attackers, the more easily they can leverage into a compromise. Personally I
> believe that conjecture, and would actually prefer to see fewer signals,
> ideally a
On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley wrote:
> - There are about 28 error codes but nearly 150 places where the text
> require the connection to be aborted with an error -- and hence,
> nearly 150 distinct constraints that can be violated. There are 19
> alone for "illegal_parameter"
On 03/05/2018 05:41 AM, Tony Putman wrote:
> Should the TLS 1.3 draft request a new registry for psk_key_exchange_modes?
> Initially, I thought that there was no way to extend it, but the email below
> from
> Martin Thomson suggests adding a new codepoint, so I thought it best to check
> that th
[incoming AD ramping up on draft review; please consider this as a
Yes ballot with COMMENT]
I was a contributor for this work, so it is unsurprising that I
support its publication. I have some editorial fixes that I sent
separately as a pull request
(https://github.com/tlswg/tls13-spec/pull/1166)
Dale, thanks for your review. I have entered a Yes ballot and encouraged the
author/WG to take a look at your comments. I suspect a lot of the
stylistic/linguistic items derive from the WG participants having deep
experience with the protocol and its previous versions and existing extensions.
A
Alissa Cooper has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes
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 https://www.iet
Warren Kumari has entered the following ballot position for
draft-ietf-tls-tls13-26: 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 https:
Ben Campbell has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes
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 https://www.ietf
13 matches
Mail list logo
