Re: [IAB] IAB report to the community for IETF 103

[Michael Richardson <[e-mail]>]

Ted Lemon <[e-mail]> wrote:
    > With all due respect, Keith, whatever we may think of it, there are
    > certainly people who think eavesdropping is a valid use case, and it
    > doesn't actually serve our ability to talk about and possibly
    > influence people who are on the fence about it if we pretend
    > otherwise.

Yes, some of them think of themselves as providing an auditing function.
It would be good to know which argument is being used in each case.

    > On Wed, Nov 21, 2018 at 8:56 AM Keith Moore
    > <[e-mail]> wrote:

    > Facilitating “eavesdropping “ is NEVER a valid use case.


    > Sent from my iPhone

    > On Nov 21, 2018, at 8:47 AM, Ted Lemon <[e-mail]> wrote:




    > I would suggest being more explicit:


    > TLS 1.3 [RFC8446] is intended to address the following use
    > cases [cite use cases that do not include eavesdropping, and
    > do include preventing eavesdropping and providing forward
    > secrecy].


    > It has come to the attention of the IETF that ETSI has
    > published a TLS 1.3 specification which addresses a different
    > set of use cases [cite use cases]. We wish to point out that
    > some of the use cases addressed by RFC8446 are not addressed
    > by ETSI. The ETSI specification should not be used in cases
    > where addressing these use cases is required [give examples].
    > The IETF takes no position on whether the ETSI specification
    > successfully addresses these use cases. However, it definitely
    > does not address the complete set of use cases addressed in
    > RFC 8446.


    > Use of the TLS variant described in this ETSI specification
    > was considered by the IETF and did not gain consensus. As
    > such, use of this variant is not recommended by the IETF.


    > I think publishing this as a very brief RFC would be quite
    > appropriate.





    > On Wed, Nov 21, 2018 at 8:05 AM Keith Moore
    > <[e-mail]> wrote:

    > On 11/20/18 7:44 PM, Lloyd Wood wrote:

    >>>> That belongs in the to be written RFC "ETSI extensions
    > to TLS considered harmful".
    >>>> Of course, we may debate whether we want to publish
    > such RFC.
    >>
    >> Perhaps a more general 'Security protocols designed by
    > any other
    >> organisations considered harmful' is the way to go.

    > I doubt that such a direction would enhance our reputation
    > or that of
    > our documents. I'd much rather see us make specific
    > technical
    > arguments, e.g.

    > - If an IETF RFC cites TLS x.y, that citation only applies
    > to TLS x.y as
    > published by IETF, not some other *TLS published by some
    > other
    > organization. Just because something else is named *TLS
    > doesn't mean
    > it's secure or an acceptable substitute, especially when
    > some of them
    > have deliberately been made in such a way as to compromise
    > the users'
    > security.

    > - If one party to a connection discloses the information
    > in the
    > connection to a third party, whether by choice or to meet
    > some
    > organizational or legal requirement, that's their business
    > and IETF
    > isn't questioning that. But intercepting the traffic at
    > the IP layer is
    > not a good way to implement such disclosures for several
    > reasons - e.g.
    > it effectively constrains the applications to only work
    > over particular
    > network segments, which harms the flexibility of the
    > Internet as a
    > general-purpose communications fabric; it discourages
    > transparency and
    > accountability that such record-keeping should require;
    > etc. (It's not
    > the record-keeping that's being questioned; it's the very
    > notion that
    > packet interception is a suitable way to accomplish that.
    > Packet
    > interception is a poor architectural choice, and yes that
    > includes
    > deep-inspecting firewalls and monitors.)

    > - For similar transparency arguments a communications
    > protocol that is
    > designed to effectively appear as TLS to the endpoints
    > and/or its users,
    > but which lacks the end-to-end confidentiality properties
    > of TLS, should
    > be discouraged by every means available.

    > - The introduction of TLS variants that are designed to
    > leak private
    > information seems likely to introduce yet another
    > destructive tussle, as
    > privacy-conscious users try to determine whether their
    > hosts and
    > applications are leaking their information, while the
    > spooks try to
    > evade such detection. (Yes I'm aware that some such
    > proposals provide
    > explicit information to their endpoints.)

    > etc.

    > Keith






    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------