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
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
For more information,
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF
Chair. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
For more information,
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
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
Joel, thanks for your review. I agree with your comment. I entered a DISCUSS
ballot as I’m a bit unclear what this spec is achieving.
Alissa
> On Feb 26, 2018, at 6:01 PM, Donald Eastlake wrote:
>
> Hi Joel,
>
> On Mon, Feb 26, 2018 at 1:24 PM, Joel Halpern
Brian, thanks for your review. I have entered a No Objection ballot.
Alissa
> On Mar 2, 2018, at 5:08 PM, Brian Carpenter
> wrote:
>
> Reviewer: Brian Carpenter
> Review result: Ready
>
> Gen-ART Last Call + Telechat review of draft-ietf-trill-multi-topology-05
>
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.
Hi Brian,
Section 3.4.6.2 describes the method to deal with schedule inconsistency, which
could happen in various conditions, including the race condition you mentioned.
The sentence added in 3.1.1 and 3.1.2 looks redundant in that sense. Thus, we
remove them at the last minute. Sorry for not
10 matches
Mail list logo