Re: [Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Eric Rescorla]

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,
I don't think this would help that much to justify making a change.
-Ekr


On Tue, Mar 6, 2018 at 2:35 PM, Colm MacCárthaigh  wrote:

>
>
> 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".  I would like to see an "alert
>>   extension value" which assigns a distinct "minor" code to each
>>   statement in the text that requires an error response (with
>>   implementations being allowed to be a bit sloppy in providing the
>>   correct minor code).
>>
>
> Your review is incredibly deep, comprehensive and I learned a lot from it.
> I want to pick out just one small piece, but don't mean that to diminish
> how thorough it was!
>
> 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.
>
> 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 as few as one big error code. There is a trade-off against
> debugability, but I've only seen a handful of people have the skills to
> debug low level TLS issues and it doesn't seem worth the risk. Others
> disagree, which is valid, but it's at least an area of reasonable
> contention.
>
> --
> Colm
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Dale R. Worley]

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.
>
> 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 as few as one big error code. There is a trade-off against
> debugability, but I've only seen a handful of people have the skills to
> debug low level TLS issues and it doesn't seem worth the risk. Others
> disagree, which is valid, but it's at least an area of reasonable
> contention.

I believe I've heard that position stated before, and I give it
credibility.  I retreat to the statement I made at the top of my review,
that I'm not experienced in security.  OTOH, I've spent a lot of the
previous couple of decades debugging SIP call flows, so I've learned to
appreciate any aid to debuggability that exists.

I'm tempted to consider this a classic case of conflicting requirements,
and ask if our cryptographic experience can help us square this circle.

Dale

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Call review of draft-ietf-bier-mvpn-10

[Meral Shirazipour]

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, please see the FAQ at 
.

Document: draft-ietf-bier-mvpn-10
Reviewer: Meral Shirazipour
Review Date: 2018-03-06
IETF LC End Date: 2018-01-30
IESG Telechat date: 2018-03-08

Summary: This draft is ready to be published as Experimental RFC.


Major issues:
Minor issues:
Nits/editorial comments:


Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Call review of draft-ietf-trill-multilevel-unique-nickname-06

[Meral Shirazipour]

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, please see the FAQ at 
.

Document: draft-ietf-trill-multilevel-unique-nickname-06
Reviewer: Meral Shirazipour
Review Date: 2018-03-06
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary: This draft is ready to be published as Proposed Standard  RFC .

Major issues:
Minor issues:
Nits/editorial comments:


Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Ted Lemon]

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 as few as one big error code. There is a trade-off against 
> debugability, but I've only seen a handful of people have the skills to debug 
> low level TLS issues and it doesn't seem worth the risk. Others disagree, 
> which is valid, but it's at least an area of reasonable contention.  

This makes perfect sense.   Stuart Cheshire and I were having the same 
discussion a while back about DNS Session Signaling, and he pointed out (I was 
playing Dale's role) that there's an important distinction to be made between 
"buggy implementation" and "actionable notification where no bug exists."   Any 
alert that signals "buggy implementation" is bad, for the reason you've stated, 
and also because such signals are not actionable—if you've run into a bug you 
should probably just give up, and not try to somehow guess in your 
implementation what might work when the bug happens.   The only reason to send 
a signal is if there is a known and clear action to take upon receiving the 
signal, other than "we're borked, give up."

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Colm MacCárthaigh]

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".  I would like to see an "alert
>   extension value" which assigns a distinct "minor" code to each
>   statement in the text that requires an error response (with
>   implementations being allowed to be a bit sloppy in providing the
>   correct minor code).
>

Your review is incredibly deep, comprehensive and I learned a lot from it.
I want to pick out just one small piece, but don't mean that to diminish
how thorough it was!

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.

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 as few as one big error code. There is a trade-off against
debugability, but I've only seen a handful of people have the skills to
debug low level TLS issues and it doesn't seem worth the risk. Others
disagree, which is valid, but it's at least an area of reasonable
contention.

-- 
Colm
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-trill-vendor-channel-00

[Alissa Cooper]

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  > wrote:
> Reviewer: Joel Halpern
> Review result: Ready
> 
> 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, please see the FAQ at
> 
>  >.
> 
> Document: draft-ietf-trill-vendor-channel-00
> Reviewer: Joel Halpern
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: This document is ready for publication as a Proposed Standard
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments:
> Why does the acknowledgements say:
> "The document was prepared in raw nroff. All macros used were defined
> within the source file."
> ?
> 
> Why not? It's true. I've seen a number of draft with credit in them for MS 
> Word templates and the like. Shouldn't people know their are still drafts 
> being prepared with nroff?

> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com  
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-trill-multi-topology-05

[Alissa Cooper]

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
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-trill-multi-topology-05.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-03-02
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: Ready
> 
> 
> Comment:
> 
> 
> This is a rushed review for reasons outside my control. Also, only
> a TRILL expert could review it effectively. As far as I can tell,
> it's a well written document.
> 
> This is a case where I wish RFC1264 still applied. I'm disappointed
> not to see an RFC 7942 Implementation Status section.
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-tls-tls13-24

[Alissa Cooper]

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.

Alissa

> On Mar 2, 2018, at 11:00 PM, Dale Worley  wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document:  draft-ietf-tls-tls13-24
> Reviewer:  Dale R. Worley
> Review Date:  2018-03-02
> IETF LC End Date:  2018-03-02
> IESG Telechat date:  2018-03-08
> 
> Summary:
> 
>   This draft is basically ready for publication, but has nits
>   that should be fixed before publication.
> 
> This review only covers the general properties of the proposed
> protocol and the exposition, as I am unqualified to assess its
> security properties.
> 
> There are various places where the exposition could be made clearer,
> especially to readers not immersed in security matters.  In many
> places, it is mostly a matter of making clearer the connections
> between different points in the exposition.
> 
> In a few places, there seems to be ambiguity regarding the
> specification that has technical significance.  In particular:
> 
> - There is inexactness about "transcript", "handshake context", and
>  "context".
> 
> - When a server receives ClientHello, is it obligated to promptly send
>  not just the ServerHello, but all first-flight messages from
>  ServerHello through Finished?  (section 4.2.11.3)  I ask this
>  because the client is only obligated/permitted to send
>  EndOfEarlyData when it receives the server's Finished.
> 
> - It seems inconsistent that the client can send an empty Certificate
>  message, but the server cannot, even though the server can omit
>  sending the Certificate message.  (section 4.4.2.4)
> 
> - Comparing sections 4.2.10 and 4.6.1, when a PSK was established in
>  an earlier connection, exactly what are the limitations on the
>  cryptographic parameters that can be used when the PSK is used in a
>  resumption connection?  4.2.10 suggests that the following must be
>  the same in both connections:  TLS version, cipher suite, ALPN.  But
>  4.6.1 suggests that different cipher suites can be used, as long as
>  they use the same hash algorithm.
> 
> - In regard to section 4.6.1, it seems to require that a client MAY
>  NOT resume a connection using a ticket issued during a connection in
>  which the server did not present a certificate for itself, because
>  in the handshake of the resumption connection, the client is required
>  to verify that the SNI is compatible with the certificate the server
>  presented in the original connection.  But that constraint isn't
>  stated in section 2.2, despite being a global constraint on the
>  structure of sessions.
> 
> - Presumably implementations MUST NOT send zero-length fragments of alert
>  messages for the same reasons that they cannot send zero-length
>  fragments of handshake messages (whatever those reasons are).
> 
> - 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".  I would like to see an "alert
>  extension value" which assigns a distinct "minor" code to each
>  statement in the text that requires an error response (with
>  implementations being allowed to be a bit sloppy in providing the
>  correct minor code).
> 
> - I take it that there is no "close read side" operation.  (If that
>  existed, TLS could generate the "broken pipe" error.)
> 
> There are a number of issues which span the whole text:
> 
> The interaction of this draft with extensions defined for previous
> versions of TLS is not laid out clearly.  It seems safe enough for
> this draft to import data structures from earlier extensions with only
> a reference to the earlier RFC, but if an extension defines behavior
> (e.g., a negotiation process), exactly what is the specification of
> that behavior in TLS 1.3, given that the referenced RFC only defines
> its use in TLS 1.2 or earlier?  At the least, there should be an
> explicit statement that the behaviors are carried forward in the
> "obvious way".
> 
> It's also not clear exactly which previously defined extensions are
> brought forward into TLS 1.3.  I suspect that they are all listed in
> section 4.2, but is it clearly stated that those, and only those, are
> grandfathered in?
> 
> Presumably, for any referenced extension, the placement of values in

Re: [Gen-art] [6tisch] Genart telechat review of draft-ietf-6tisch-6top-protocol-09

[Qin Wang]

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 notifying you in advance, and 
thank you for your review again.
ThanksQin 

On Monday, March 5, 2018 8:21 PM, Brian E Carpenter 
 wrote:
 

 Hi,
On 27/02/2018 05:31, Qin Wang wrote:
...
> [Qin] Add following textin both section 3.1.1 and 3.1.2
> In case a race conditionhappens during the communication, the TSCH schedule 
> of node A may becomeinconsistent with the TSCH schedule of node B. 6top 
> handles the schedule inconsistency in the way described in Section3.4.6.2

I don't think that made it into the -10 version.

    Brian


   ___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art