Subject: IAB report to the community for IETF 103

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Nov 2018 00:25:06 -0700

Dear colleagues,

Here is the IAB report to the community about our activities, submitted so
that you can prepare topics you might want to discuss during the upcoming
open mic time.  Of course, if you have issues you want to discuss by email,
feel free to send your comments to [email-masked] (our public
discussion list) or [email-masked] (to reach just the IAB).

The IAB has a few chartered roles. It confirms the appointments to the
IESG, performs standards process oversight, and handles appeals. It also
performs architectural oversight (including appointing the IRTF Chair),
appoints the RFC series editor and oversight committee, manages the IETF's
relationship with IANA, and handles liaisons and appointments both to ISOC
and to other organizations.

Here's what the IAB has been doing since our last report; more detail on
many of the topics is available at https://www.iab.org.

First, I’m happy to note that there were no appeals during this period.

Second, I wish to highlight  a couple of changes in IAB meeting practice.
The agendas for IAB teleconferences
<https://www.iab.org/wiki/index.php/Agenda> are now publicly posted in
advance of the meetings.  The teleconferences themselves are also now open
to observers, except for sections which deal with personnel matters or
similarly sensitive issues.  Call-in information is available as part of
the agenda.

As part of its appointments role, the IAB has filled a number of positions
since our last report.  Tim Wicinski was appointed to the Community
Coordination Group, which advises the IETF Trust. Ole Jacobsen was
re-appointed to the ICANN NomCom, which selects candidates for the ICANN
Board.  The IAB also updated the membership of the RFC Series Oversight
Committee; Sarah Banks, Tony Hansen, Adam Roach, and Peter Saint-Andre were
appointed to serve, along with IAB members Robert Sparks and Christian
Huitema.

There are also a number of positions  for which the IAB is either currently
seeking volunteers or for which calls will go out shortly.  The IAB is
currently soliciting volunteers for the ICANN TLG; you can see that call
for volunteers
<https://www.iab.org/2018/10/23/volunteer-needed-for-icann-technical-liaison-group-3/>on
the IAB web site.  The IAB is looking for new members for the the IAB
Plenary Planning Program
<https://www.iab.org/2018/10/24/iab-seeks-volunteers-for-plenary-planning-program/>.
The IAB is also seeking nominations for IRTF Chair
<https://www.iab.org/2018/10/29/call-for-nominations-irtf-chair-2/>;
Allison Mankin, the current Chair, has indicated that she will be stepping
down after completing this term.

We will also be issuing a call for volunteers to serve on the Internet
Society’s Board of Trustees.  As the Trustees are meeting in Bangkok after
IETF 103 there will be several members of the Board attending the IETF.  If
you are interested in the work of the board, please reach out to the IAB or
one of the current Trustees.
DOCUMENTS

You can always find the documents the IAB has adopted and is working on at
https://datatracker.ietf.org/stream/iab
<https://datatracker.ietf.org/stream/iab>.

Two RFCs have been published since the last report:

RFC 8477 <https://datatracker.ietf.org/doc/rfc8477/> Report from the
Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016

RFC 8462 <https://datatracker.ietf.org/doc/rfc8462/> Report from the IAB
Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)

Given both the time it takes to produce workshop reports in RFC form and
the occasional mismatch between the style of the workshop and the archival
format of the RFCs, the IAB is now considering whether it would be useful
to allow workshop organizers to consider other publication forms.  A web
page maintained by the IAB on its own site, linked to the original call for
participation, is one form under consideration. The IAB is interested in
feedback on this approach and would welcome any thoughts on it; we expect
discussion to take place on [email-masked].

The IAB also provided comments in response to Australia’s proposed
Assistance and Access Bill
<https://www.iab.org/wp-content/IAB-uploads/2018/09/IAB-Comments-on-Australian-Assistance-and-Access-Bill-2018.pdf>.
While it is unusual for the IAB to comment on legislation, the IAB chose to
do so in this case because of the potential impact on the Internet trust
model and the risk of fragmentation if multiple jurisdictions implemented
similar legislation.
 PROGRAMS

The IAB organizes its work, for the most part, into programs.  There are
basically two classes: management programs and architectural programs.  The
former are how we handle the oversight of various things, and the latter
are where we do architectural work.  The former are expected to last as
long as the IAB continues to have that oversight function; the latter last
until the IAB has come to a conclusion on the relevant group of topics or
has decided that the topic needs to be reframed.  Programs are listed at
https://www.iab.org/activities/programs/. As a general rule, each
architectural program has a public mailing list, as well as a
member-specific list.  For subscription instructions, see
https://www.iab.org/iab-mailing-lists/.

As noted above, the Plenary Planning Program is seeking volunteers; that
group will tackle not just identifying good topics and speakers but also
potentially re-thinking the technical plenary approach more generally.
WORKSHOPS

The IAB has two workshops in preparation, and we anticipate sending the
calls for participation for both at or shortly after IETF 103.  The first,
Exploring Synergy between Content Aggregation and the Publisher Ecosystem,
is a joint workshop with the W3C TAG focused on how web packaging
technologies change the distribution of content on the Internet and the
impact of that change on other parts of the ecosystem.  The second,
tentatively called Current Internet Perception and Evolution, explores the
relationship between consumer/user perceptions of the Internet and
concentration of providers or asymmetry. We are seeking to better
understand the nature of this asymmetry and what new technical standards
(if any) could do to mitigate the risks it represents.

Respectfully submitted,

Ted Hardie

for the IAB

---

From: S Moonesamy <[email-masked]>
Date: Sun, 11 Nov 2018 09:52:27 -0800

Dear IAB,
At 11:25 PM 31-10-2018, Ted Hardie wrote:
>The IAB also provided comments in response to Australia's proposed 
>Assistance and Access Bill.  While it is unusual for the IAB to 
>comment on legislation, the IAB chose to do so in this case because 
>of the potential impact on the Internet trust model and the risk of 
>fragmentation if multiple jurisdictions implemented similar legislation.

ETSI TS 103 523-3 V1.1.1 specifies some changes to RFC 8446.  Does 
the IAB have an opinion on its potential impact on the Internet trust 
model and the risk of fragmentation if multiple jurisdictions 
required it through regulation?

Regards,
S. Moonesamy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Nov 2018 11:07:45 +0100

> required it through regulation?
The IETF security ADs provided feedback to ETSI
<https://datatracker.ietf.org/liaison/1538/> on this ETSI work last year
and ETSI responded in liaison statement CYBER(17)011006r1.  The IAB
generally agreed with the IETF security Area Directors' analysis.

regards,

Ted Hardie

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 21:20:30 +1100

On Mon, Nov 12, 2018 at 9:08 PM Ted Hardie <[email-masked]> wrote:
> The IETF security ADs provided feedback to ETSI on this ETSI work last year and ETSI responded in liaison statement CYBER(17)011006r1.  The IAB generally agreed with the IETF security Area Directors' analysis.

ETSI seem to have ignored the request regarding the name (this is
called eTLS, the last one was called mcTLS).  They have also changed
to a different design, specifically the one in
draft-green-tls-static-dh-in-tls13.  That design is considerably
simpler than mcTLS, but it's a design that was abandoned even by its
proponents for several good reasons (lack of forward security and lack
of transparency being the ones I remember offhand).

---

From: S Moonesamy <[email-masked]>
Date: Mon, 12 Nov 2018 05:26:08 -0800

Hi Ted, Martin,
At 02:07 AM 12-11-2018, Ted Hardie wrote:
>on this ETSI work last year and ETSI responded 
>in liaison statement CYBER(17)011006r1.Â  The 
>IAB generally agreed with the IETF security Area Directors' analysis.

Thanks.

>of transparency being the ones I remember offhand).

I took a quick look at the "TLS for the 
enterprise" specification.  The per-session 
forward secrecy was removed to allow for "operational visibility".

Regards,
S. Moonesamy

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Nov 2018 12:19:57 +0900

> draft-green-tls-static-dh-in-tls13.

this is serious breakage.  draft-green is intentional privacy attack.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Nov 2018 18:42:25 +0900

tony arciery:

It takes an awful lot of doublethink to take TLS 1.3, remove forward
secrecy, introduce a deliberate self-MitM capability, and call the
result a “security protocol”. Call me crazy but TLS’s one job is
avoiding decryption by third parties

---

From: Christian de Larrinaga <[email-masked]>
Date: Wed, 14 Nov 2018 10:19:44 +0000

> avoiding decryption by third parties

That review should be written into the specification!

Christian

---

From: Keith Moore <[email-masked]>
Date: Sun, 18 Nov 2018 22:50:37 -0500

Would it be appropriate for IETF to issue an RFC that states that 
despite the similarity in names, use of such variants of TLS MUST NOT be 
used to claim compliance with IETF specifications requiring TLS, and 
generally warning the IETF community of deliberate efforts to weaken 
application security?

It seems like these efforts deserve wider public exposure.

Keith

On 11/12/18 5:07 AM, Ted Hardie wrote:
> On Sun, Nov 11, 2018 at 6:57 PM S Moonesamy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> <https://datatracker.ietf.org/liaison/1538/> on this ETSI work last 
> year and ETSI responded in liaison statement CYBER(17)011006r1. The

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Nov 2018 08:26:24 -0500

Keith Moore <[email-masked]> wrote:
    > despite the similarity in names, use of such variants of TLS MUST NOT
    > be used to claim compliance with IETF specifications requiring TLS,
    > and generally warning the IETF community of deliberate efforts to
    > weaken application security?

Can you give me an example of what you mean?
(i.e. "Use "TLS MUST NOT in a sentence" :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Nov 2018 09:20:15 -0800

> On Nov 19, 2018, at 5:26 AM, Michael Richardson <[email-masked]> wrote:
> 

Of course it can be done: 
"Clients SHOULD detect repeated use of the same [EC]DH key share by a server, and MAY terminate TLS connections with alert Repeated-key-share detected when detecting this form of server misbehavior."

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.

-- Christian Huitema

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Nov 2018 11:37:04 -0600

Separately from the question of whether to issue an RFC, we do intend to
provide a liaison statement regarding this matter.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Nov 2018 17:56:14 -0500

> generally warning the IETF community of deliberate efforts to weaken

I was having real difficulties with the above sentence.
Maybe it's missing punctuation (I don't see any missing as I look now), but I
suspect it was just ENOTENOUGHCAFFEINE on my part.

I thought that other entities were using RFC2119 language of the form:
  "TLS MUST NOT"

and I just couldn't figure out how that was going work in a sentence.

A day later and now I understand that other entites are using "varients of
TLS" to claim that they are in compliance with IETF specifications requiring
TLS.

Like, "Use TLS but, instead of encrypting the text, just send what you
you were gong to encrypt, over the wire as-is" :-)

And we should (should we?) write a document saying that they MUST NOT do so.
Or as Ben just asked, do a liason.

{Can someone write an April 1 RFC about Liasons between SDOs, involving Microfilm?}

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Nov 2018 23:10:02 +0000

> And we should (should we?) write a document saying that they MUST NOT do so.

If implementers consider such a document useful then we should
do it. The potential benefit I guess could be that when someone
says "hey, let's support ETSI's-broken-TLS" an implementer
could say "please read RFC<foo>" for why we don't."

I'm not sure if such a document would be useful as I don't
have to face such issues. (If TLS implementers said it were,
I'd be happy to help with one.)

> Or as Ben just asked, do a liason.

That's separately needed (and I'm told happening). There's
copyright and good neighbour issues there that the IETF and
ETSI could do with sorting out, over and above the specifics
of the ETSI TC that rubber-stamped the draft-green thing
that had been explicitly rejected in the IETF.

S.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 20 Nov 2018 00:40:12 +0000 (UTC)

Maybe a technical document is the wrong way to address this.

https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management

Perhaps a countering press release is needed, reminding everyone of

the IETF's stances on security and privacy.

(I don't see what could be leveraged here for copyright or
brand protection; internet drafts are copyrighted to the IETF Trust,
but asserting that copyright and claiming that republishing draft-green
violates it could have a chilling effect on future contributions.)

L.
Lloyd Wood [email-masked] http://about.me/lloydwood

________________________________
From: Stephen Farrell <[email-masked]>
To: Michael Richardson <[email-masked]>; [email-masked] 
Sent: Tuesday, 20 November 2018, 10:10
Subject: "Re: [IAB] IAB report to the community for IETF 103

S.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Nov 2018 08:58:19 +0700

> On Nov 20, 2018, at 00:20, Christian Huitema <[email-masked]> wrote:
> 
> 
> 

It will just use prf(secretseed) maybe with a prefix for random(number of rounds). How will you detect those ?

> 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.

I would like to see a discussion of this, even if we end up not writing one.

Paul

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Nov 2018 21:05:58 -0500

> (i.e. "Use "TLS MUST NOT in a sentence" :-)

One example I was thinking of was RFC 8314, which states (again, for 
example) that an MUA "SHOULD require negotiation of TLS version 1.1 or 
greater" to establish a minimum confidentiality level that's suitable 
for interaction with a mail server.   It needs to be clear that some TLS 
variant that's designed to compromise the user's privacy isn't ever 
suitable to establish a minimum confidentiality level, no matter what 
version number it claims to use.

More generally, while we try to make TLS version y more secure than TLS 
version x, for y > x, you can't really compare versions of real TLS with 
versions of compromised TLS and expect that comparison to be meaningful 
in terms of the level of confidentiality provided.

Keith

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 21 Nov 2018 00:44:50 +0000 (UTC)

>> 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.

L.

and that includes the IRTF.

________________________________
From: Paul Wouters <[email-masked]>
To: Christian Huitema <[email-masked]> 
Cc: Michael Richardson <[email-masked]>; Keith Moore <[email-masked]>; [email-masked]
Sent: Tuesday, 20 November 2018, 12:59
Subject: Re: [IAB] IAB report to the community for IETF 103

Paul

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Nov 2018 08:05:17 -0500

> 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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2018 08:47:40 -0500

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.

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Nov 2018 08:53:59 -0500

Facilitating “eavesdropping “ is NEVER a valid use case.

Sent from my iPhone

> On Nov 21, 2018, at 8:47 AM, Ted Lemon <[email-masked]> wrote:
> 
> 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.
> 
>> On Wed, Nov 21, 2018 at 8:05 AM Keith Moore <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2018 09:01:31 -0500

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.

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Nov 2018 09:17:31 -0500

I’m aware of course that such people exist.  But I think they have the burden of explaining for instance (a) even if there are legitimate reasons for third parties to access traffic, why having access to the physical media confers such legitimacy; and (b) why such access should not be engineered in such a way as to provide transparency and accountability.  

I also think it’s quite clear that some people who believe that there are legitimate use cases for eavesdropping are in fact the enemies of a free society and we do ourselves no credit to pretend otherwise.

Sent from my iPhone

> On Nov 21, 2018, at 9:01 AM, Ted Lemon <[email-masked]> 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.
> 
>> On Wed, Nov 21, 2018 at 8:56 AM Keith Moore <[email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Nov 2018 10:30:49 -0500

Ted Lemon <[email-masked]> wrote:
    > 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.

    > 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.

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

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