[要約] RFC 7687は、Strengthening the Internet (STRINT) Workshopの報告書であり、インターネットの強化に関する議論と提案をまとめています。このRFCの目的は、インターネットのセキュリティと信頼性の向上を促進するための具体的なアクションを提案することです。
Internet Architecture Board (IAB) S. Farrell
Request for Comments: 7687 Trinity College, Dublin
Category: Informational R. Wenning
ISSN: 2070-1721 B. Bos
W3C
M. Blanchet
Viagenie
H. Tschofenig
ARM Ltd.
December 2015
Report from the Strengthening the Internet (STRINT) Workshop
インターネットの強化（STRINT）ワークショップからのレポート
Abstract
概要
The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.
インターネットの強化（STRINT）ワークショップでは、2014年の初めにロンドンで100名の参加者が2日間集まり、技術コミュニティ、特にIETFとW3Cが普及モニタリングにどのように対応すべきか、より一般的にはインターネットを強化する方法について話し合ったそのような攻撃の顔。ディスカッションでは、用語の問題、ユーザーインターフェイスの役割、緩和策のクラス、特定の使用例、移行戦略（日和見暗号化を含む）などについて取り上げました。ワークショップは、実装可能であり、インターネットの強化に役立つと考えられる、いくつかの高レベルの推奨事項で終了しました。これがそのワークショップの報告です。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7687.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7687で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Workshop Goals . . . . . . . . . . . . . . . . . . . . . . . 4
4. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5
5. Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. After the Workshop . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Logistics . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Agenda . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix C. Workshop Chairs and Program Committee . . . . . . . 29
Appendix D. Participants . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
The technical plenary session at IETF 88 [vancouverplenary] concluded that Pervasive Monitoring (PM) represents an attack on the Internet, and the IETF has begun to carry out the more obvious actions required to try to handle this attack. However, there are much more complex questions arising that need further consideration before any additional concrete plans can be made.
IETF 88 [vancouverplenary]での技術本会議では、Pervasive Monitoring（PM）はインターネットへの攻撃であり、IETFはこの攻撃を処理するために必要な、より明白なアクションの実行を開始しました。ただし、追加の具体的な計画を作成する前にさらに検討する必要のある、はるかに複雑な問題が発生しています。
The W3C (<https://www.w3.org>) and IAB (<https://www.iab.org>) therefore decided to host a workshop on the topic of "Strengthening the Internet Against Pervasive Monitoring" [STRINT] before IETF 89 in London in March 2014. The FP7-funded STREWS project (<https://www.strews.eu/>) organised the STRINT workshop on behalf of the IAB and W3C.
したがって、W3C（<https://www.w3.org>）とIAB（<https://www.iab.org>）は、「広範にわたる監視に対するインターネットの強化」というトピックに関するワークショップを主催することを決定しました[STRINT ] 2014年3月にロンドンでIETF 89が開催される前。FP7が資金を提供するSTREWSプロジェクト（<https://www.strews.eu/>）は、IABおよびW3Cに代わってSTRINTワークショップを開催しました。
The main workshop goal was to discuss what can be done, especially by the two standards organisations IETF and W3C, against PM, both for existing Internet protocols (HTTP/1, SMTP, etc.) and for new ones (WebRTC, HTTP/2, etc.).
ワークショップの主な目標は、既存のインターネットプロトコル（HTTP / 1、SMTPなど）と新しいプロトコル（WebRTC、HTTP / 2）の両方に対して、PMに対して、特にIETFとW3Cの2つの標準化組織によって何ができるかを議論することでした。など）。
The starting point for the workshop was the existing IETF consensus that PM is an attack [RFC7258] (the text of which had achieved IETF consensus at the time of the workshop, even though the RFC had yet to be published).
ワークショップの出発点は、PMが攻撃であるという既存のIETFコンセンサス[RFC7258]でした（RFCはまだ公開されていませんが、そのテキストはワークショップの時点でIETFコンセンサスを達成しています）。
The workshop was well attended (registration closed when the maximum capacity of 100 was reached, but more than 150 expressed a desire to register) and several people (about 165 at the maximum) listened to the streaming audio. The submitted papers (67 in total) were generally of good quality and all were published, except for a few where authors who couldn't take part in the workshop preferred not to publish.
ワークショップには多くの参加者があり（最大収容人数100人に達した時点で登録は終了しましたが、150人以上が登録を希望しました）、数人（最大で約165人）がストリーミングオーディオを聴きました。提出された論文（全体で67）は、一般的に質の高いものであり、ワークショップに参加できなかった執筆者が出版しないことを好んだ少数の論文を除いて、すべて出版されました。
The chairs of the workshop summarised the workshop in the final session in the form of the following recommendations:
ワークショップの議長は、最終セッションでワークショップを次の推奨事項の形式で要約しました。
1. Well-implemented cryptography can be effective against PM and will benefit the Internet if used more, despite its cost, which is steadily decreasing anyway.
1. 十分に実装された暗号化はPMに対して効果的であり、コストがかかりますが、それでも着実に減少しているにもかかわらず、より多く使用されればインターネットに利益をもたらします。
2. Traffic analysis also needs to be considered, but is less well understood in the Internet community: relevant research and protocol mitigations such as data minimisation need to be better understood.
2. トラフィック分析も考慮する必要がありますが、インターネットコミュニティではあまり理解されていません。データの最小化など、関連する調査やプロトコルの緩和策をよりよく理解する必要があります。
3. Work should continue on progressing the PM threat model document [Barnes] discussed in the workshop. Subsequent work on this topic resulted in the publication of [RFC7624].
3. ワークショップで議論されたPM脅威モデルドキュメント[Barnes]の進行に向けて作業を続ける必要があります。このトピックに関するその後の作業の結果、[RFC7624]が発行されました。
4. Later, the IETF may be in a position to start to develop an update to BCP 72 [RFC3552], most likely as a new RFC enhancing that BCP and dealing with recommendations on how to mitigate PM and how to reflect that in IETF work.
4. その後、IETFはBCP 72 [RFC3552]へのアップデートを開発し始める可能性があります。おそらく、そのBCPを強化し、PMを軽減する方法とそれをIETFの作業に反映する方法に関する推奨事項を扱う新しいRFCです。
5. The term "opportunistic" has been widely used to refer to a possible mitigation strategy for PM. The community needs to document definition(s) for this term, as it is being used differently by different people and in different contexts. We may also be able to develop a cookbook-like set of related protocol techniques for developers. Since the workshop, the IETF's Security area has taken up this work, most recently favouring the generic term "Opportunistic Security" (OS) [Kent]. Subsequent work on this topic resulted in the publication of a definition of OS in [RFC7435].
5. 「日和見的」という用語は、PMの可能な緩和戦略を指すために広く使用されています。コミュニティは、この用語の定義を文書化する必要があります。この用語は、人によって、またコンテキストによって使用方法が異なるためです。開発者向けのクックブックのような関連プロトコルテクニックのセットを開発することもできます。ワークショップ以来、IETFのセキュリティ領域がこの作業を取り上げており、最近では「Opportunistic Security」（OS）[ケント]という総称を支持しています。このトピックに関するその後の作業の結果、[RFC7435]でOSの定義が公開されました。
6. The technical community could do better in explaining the real technical downsides related to PM in terms that policy makers can understand.
6. 技術コミュニティは、政策立案者が理解できる観点から、PMに関連する実際の技術的な欠点をよりよく説明することができます。
7. Many user interfaces (UIs) could be better in terms of how they present security state, though this is a significantly hard problem. There may be benefits if certain dangerous choices were simply not offered anymore. But that could require significant coordination among competing software makers; otherwise, some will be considered "broken" by users.
7. 多くのユーザーインターフェイス（UI）は、セキュリティ状態の表示方法の点で優れている可能性がありますが、これは非常に難しい問題です。特定の危険な選択肢が提供されなくなっただけでメリットがある場合があります。しかし、そのためには、競合するソフトウェアメーカー間の大幅な調整が必要になる可能性があります。それ以外の場合、一部はユーザーによって「壊れている」と見なされます。
8. Further discussion is needed on ways to better integrate UI issues into the processes of IETF and W3C.
8. UIの問題をIETFおよびW3Cのプロセスに適切に統合する方法については、さらなる議論が必要です。
9. Examples of good software configurations that can be cut-and-pasted for popular software, etc., can help. This is not necessarily standards work, but maybe the standards organisations can help and can work with those developing such package-specific documentation.
9. 人気のあるソフトウェアなどにカットアンドペーストできる優れたソフトウェア構成の例が役立ちます。これは必ずしも標準で機能するわけではありませんが、標準化団体がそのようなパッケージ固有のドキュメントを開発している人々を支援し、協力できる可能性があります。
10. The IETF and W3C can do more so that default ("out-of-the-box") settings for protocols better protect security and privacy.
10. IETFとW3Cはさらに多くのことができるので、プロトコルのデフォルト（「そのまま」）の設定はセキュリティとプライバシーをよりよく保護します。
11. Captive portals [Captive] and some firewalls, too, can and should be distinguished from real man-in-the-middle attacks. This might mean establishing common conventions with makers of such middleboxes, but might also mean developing new protocols. However, the incentives for deploying such new middlebox features might not align.
11. キャプティブポータル[キャプティブ]と一部のファイアウォールも、実際の中間者攻撃と区別できます。これは、そのようなミドルボックスのメーカーと共通の規約を確立することを意味するかもしれませんが、新しいプロトコルを開発することを意味するかもしれません。ただし、そのような新しいミドルボックス機能をデプロイするインセンティブは一致しない場合があります。
As stated, the STRINT workshop started from the position [RFC7258] that PM is an attack. While some dissenting voices are expected and need to be heard, that was the baseline assumption for the workshop, and the high-level goal was to provide more consideration of that and how it ought to affect future work within the IETF and W3C.
述べたように、STRINTワークショップはPMが攻撃であるという立場[RFC7258]から始まりました。一部の反対意見が予想され、意見を聞く必要がありますが、それはワークショップの基本的な想定であり、高レベルの目標は、それと、それがIETFおよびW3C内の将来の作業にどのように影響するかをさらに検討することでした。
At the next level down, the goals of the STRINT workshop were to:
次のレベルでは、STRINGワークショップの目標は次のとおりです。
o Discuss and hopefully come to agreement among the participants on concepts in PM for both threats and mitigation, e.g., "opportunistic" as the term applies to cryptography.
o 脅威と軽減の両方についてPMの概念について参加者間で話し合い、うまくいけば合意します。たとえば、「日和見」という用語は暗号に適用されるためです。
o Discuss the PM threat model, and how that might be usefully documented for the IETF at least, e.g., via an update to BCP 72. [RFC3552]
o PM脅威モデルについて、および少なくともBCP 72への更新などにより、IETFにどのように文書化することが有益であるかについて話し合います。[RFC3552]
o Discuss and progress common understanding in the trade-offs between mitigating and suffering PM.
o PMの軽減と苦しみの間のトレードオフについて、共通の理解について話し合い、進展させます。
o Identify weak links in the chain of Web security architecture with respect to PM.
o PMに関するWebセキュリティアーキテクチャのチェーンの弱いリンクを特定します。
o Identify potential work items for the IETF, IAB, IRTF, and W3C that would help mitigate PM.
o PMの軽減に役立つIETF、IAB、IRTF、およびW3Cの潜在的な作業項目を特定します。
o Discuss the kinds of action outside the IETF/W3C context that might help those done within the IETF/W3C.
o IETF / W3C内で実行されるアクションに役立つ可能性のある、IETF / W3Cコンテキスト外のアクションの種類について話し合います。
The workshop structure was designed to maximise discussion time. There were no direct presentations of submitted papers. Instead, the moderators of each session summarised topics that the Technical Programme Committee (TPC) had agreed based on the submitted papers. These summary presentations took at most 50% of the session and usually less.
ワークショップの構造は、議論の時間を最大化するように設計されました。提出された論文の直接の発表はありませんでした。代わりに、各セッションのモデレーターは、提出された論文に基づいて技術プログラム委員会（TPC）が合意したトピックを要約しました。これらの要約プレゼンテーションは、セッションの最大50％を占め、通常は少なかった。
Because the papers would not be presented during the workshop, participants were asked to read and discuss the papers beforehand, at least those relevant to their fields of interest. (To help people choose papers to read, authors were asked to provide short abstracts.)
ワークショップ中に論文は発表されないため、参加者は、少なくとも関心分野に関連する論文を事前に読んで話し合うよう求められました。 （読者が読む論文を選ぶのを助けるために、著者は短い要約を提供するように求められました。）
Most of the sessions had two moderators, one to lead the discussion, while the other managed the queue of people who wanted to speak. This worked well: everybody got a chance to speak and each session still ended on time.
ほとんどのセッションには2人のモデレーターがおり、1人はディスカッションを主導し、もう1人は発言したい人の列を管理しました。これはうまくいきました：全員が話す機会を得て、各セッションは時間通りに終了しました。
The penultimate session consisted of break-outs (which turned out to be the most productive sessions of all, most likely simply due to the smaller numbers of people involved). The subjects for the break-outs were agreed during the earlier sessions, and just before the break-out session the participants collectively determined who would attend which.
最後から2番目のセッションはブレイクアウトで構成されていました（これは、最も生産性の高いセッションであることがわかりました。おそらく、関係する人数が少ないためです）。ブレイクアウトの主題は、前のセッション中に合意され、ブレイクアウトセッションの直前に、参加者は集合的に誰が参加するかを決定しました。
The following sections contain summaries of the various sessions. See the minutes (see Appendix B) for more details.
以下のセクションには、さまざまなセッションの要約が含まれています。詳細については、議事録（付録Bを参照）を参照してください。
The first session discussed the goals of the workshop. Possible approaches to improving security in the light of pervasive monitoring include a critical look at what metadata is actually required, whether old (less secure) devices can be replaced with new ones, what are "low-hanging fruit" (issues that can be handled quickly and easily), and what level of security is "good enough": a good solution may be one that is good for 90% of people or 90% of organisations.
最初のセッションでは、ワークショップの目標について議論しました。広範な監視に照らしてセキュリティを向上させるための可能なアプローチには、実際に必要なメタデータ、古い（安全性の低い）デバイスを新しいデバイスに置き換えることができるかどうか、「ぶら下がっている果物」（処理できる問題）を批判的に検討することが含まれます。迅速かつ簡単に）、そしてどのレベルのセキュリティで「十分」であるか：90％の人や90％の組織に適したソリューションが良いでしょう。
Some participants felt that standards are needed so that people can see if their systems conform to a certain level of security, and easy to remember names are needed for those standards, so that a buyer can immediately see that a product "conforms to the named intended standard."
一部の参加者は、システムが特定のレベルのセキュリティに準拠しているかどうかを確認できるように標準が必要であり、購入者が製品が「意図した名前に準拠している」ことをすぐに確認できるように、それらの標準に覚えやすい名前が必要であると感じました標準。"
One difference between "traditional" attacks and pervasive monitoring is modus operandi of the attacker: typically, one determines what resources an attacker might want to target and at what cost and then one defends against that threat. But a pervasive attacker has no specific targets, other than to collect everything he can. The calculation of the cost of losing resources vs. the cost of protecting them is thus different. And unlike someone motivated to make money, a PM attacker may not be concerned at the cost of the attack (or may even prefer a higher cost, for "empire building" reasons).
「従来の」攻撃と広汎な監視の違いの1つは、攻撃者の手口です。通常、攻撃者がどのリソースをどのようなコストで標的にしたいかを決定し、その脅威から防御します。しかし、蔓延している攻撃者は、できる限りすべてを収集することを除いて、特定の標的を持ちません。したがって、リソースを失うコストとリソースを保護するコストの計算は異なります。そして、金儲けをする動機を持つ人とは異なり、PM攻撃者は攻撃のコストを気にしないかもしれません（または「帝国建設」の理由で、より高いコストを好むかもしれません）。
The terminology used to talk about threats has to be chosen carefully (this was a common theme in several sessions), because we need to explain to people outside the technical community what they need to do or not do. For example, authentication of endpoints doesn't so much "protect against" man-in-the-middle (MITM) attacks as make them visible. The attacker can still mount an attack but does not remain invisible while he does so. Somebody on either end of the conversation needs to react to the alert from the system: stop the conversation or find a different channel.
脅威について話すために使用される用語は慎重に選択する必要があります（これはいくつかのセッションで共通のテーマでした）。技術コミュニティの外部の人々に、何をすべきか、何をすべきでないかを説明する必要があるためです。たとえば、エンドポイントの認証は、中間者（MITM）攻撃に対する "保護"攻撃を目に見えるほどにはしません。攻撃者はまだ攻撃を仕掛けることはできますが、そうしている間は見えなくなりません。会話のどちらかの側にいる誰かが、システムからのアラートに反応する必要があります。会話を停止するか、別のチャネルを見つけてください。
Paradoxically, while larger sites such as Facebook, Yahoo, and Google supervise the security of their respective services more than other smaller sites, such large sites offer a much more attractive target to attack. Avoiding overuse of such repositories for private or sensitive information may be a useful measure that increases the cost of collecting for a pervasive attacker. This is sometimes called the target-dispersal approach.
逆説的に言えば、Facebook、Yahoo、Googleなどの大規模なサイトは、他の小規模なサイトよりもそれぞれのサービスのセキュリティを監視しますが、そのような大規模なサイトは攻撃に対してはるかに魅力的なターゲットを提供します。個人情報や機密情報のためにそのようなリポジトリを使いすぎないようにすることは、広範囲にわたる攻撃者のために収集するコストを増加させる有効な手段になる場合があります。これは、ターゲット分散方式と呼ばれることもあります。
Lack of interoperability between systems can lead to poorly thought out work-arounds and compromises that may themselves introduce vulnerabilities. Thus, improving interoperability needs to be high on the list of priorities of standards makers and even more for implementers. Of course, testing (such as interop testing) is, at some level, part of the process of the IETF and W3C; and the W3C is currently increasing its testing efforts.
システム間の相互運用性の欠如は、十分に考え抜かれた回避策や妥協策につながり、それ自体が脆弱性をもたらす可能性があります。したがって、相互運用性の向上は、標準メーカーの優先順位のリストで高く、さらには実装者にとってさらに高くする必要があります。もちろん、テスト（相互運用テストなど）は、あるレベルでは、IETFとW3Cのプロセスの一部です。 W3Cは現在、テストの取り組みを増やしています。
The first session on Communication Security (COMSEC) tools looked at the question why existing security tools aren't used more.
通信セキュリティ（COMSEC）ツールに関する最初のセッションでは、既存のセキュリティツールがこれ以上使用されない理由を検討しました。
The example of the public key infrastructure used to secure HTTP is informative. One problem is that certification authorities (CAs) may issue a certificate for any domain. Thus, a single compromised CA can be used in combination with a MITM to impersonate any server. Moreover, ongoing administration, including requesting, paying for, and installing new certificates, has proven over time to be an insurmountable barrier for many web site administrators, leading them not to bother to secure their systems.
HTTPを保護するために使用される公開鍵インフラストラクチャの例は参考情報です。 1つの問題は、証明機関（CA）が任意のドメインの証明書を発行する可能性があることです。したがって、単一の侵害されたCAをMITMと組み合わせて使用して、任意のサーバーを偽装することができます。さらに、新しい証明書の要求、支払い、インストールなどの継続的な管理は、時間の経過とともに多くのWebサイト管理者にとって乗り越えられない障壁であることが証明されており、システムを保護する手間を省くことができます。
Some ideas were discussed for improving the CA system, e.g., via cross-certification of CAs and by means of "certificate transparency" -- a public, permanent log of who issued which certificate [RFC6962].
たとえば、CAの相互認証や「証明書の透明性」-誰がどの証明書を発行したかを示す永続的な公開ログ[RFC6962]によって、CAシステムを改善するためのいくつかのアイデアが議論されました。
Using other models than the hierarchical certificate model (as alternative or in combination) may also help. Pretty Good Privacy (PGP) demonstrates a model known as a "web of trust" where people verify the public key of the people they meet. Because there is no innate transitive trust in PGP, it is appropriate only for small-scale uses; an example is a team of people working on a project.
階層的な証明書モデル以外のモデルを（代替として、または組み合わせて）使用することも役立つ場合があります。 Pretty Good Privacy（PGP）は、人々が出会った人々の公開鍵を検証する「信頼の網」として知られるモデルを示しています。 PGPには生来の推移的な信頼がないため、小規模な使用にのみ適しています。例は、プロジェクトに取り組んでいる人々のチームです。
Yet another model is "trust on first use" (TOFU). This is used quite effectively by SSH [RFC4252]. On the first connection, one has no way to verify that the received public key belongs to the server one is contacting, therefore, the key is accepted without further verification. But on the subsequent connections, one can verify that the received key is the same key as the first time. So, a MITM has to be there on all connections, including the first; otherwise, it will be detected by a key mismatch.
さらに別のモデルは、「最初の使用に対する信頼」（TOFU）です。これは、SSH [RFC4252]によって非常に効果的に使用されます。最初の接続では、受信した公開鍵が接続先のサーバーに属していることを確認する方法がないため、鍵はそれ以上の検証なしに受け入れられます。しかし、その後の接続では、受信したキーが最初のキーと同じであることを確認できます。したがって、MITMは最初の接続を含むすべての接続に存在する必要があります。それ以外の場合は、キーの不一致によって検出されます。
This works well for SSH, because people typically use SSH to communicate with a small number of servers over and over again. And, if they want, they may find a separate channel to get the public key (or its fingerprint). It may also work for web servers used by small groups (the server of a sports club, a department of a company, etc.), but probably works less well for public servers that are visited once or a few times or for large services where many servers may be used.
これはSSHでうまく機能します。通常、人々はSSHを使用して少数のサーバーと何度も何度も通信するためです。また、必要に応じて、公開鍵（またはそのフィンガープリント）を取得するための別のチャネルを見つける場合もあります。また、小規模なグループ（スポーツクラブのサーバー、会社の部署など）が使用するWebサーバーでも機能する可能性がありますが、おそらく1回または数回アクセスされるパブリックサーバーや、多くのサーバーを使用できます。
A similar proposal [RFC7469] for an HTTP header introduces an aspect of TOFU into HTTP: Key pinning tells HTTP clients that for a certain time after receiving this certificate, they should not expect the certificate to change. If it does, even if the new certificate looks valid, the client should assume a security breach.
HTTPヘッダーに関する同様の提案[RFC7469]は、TOFUの側面をHTTPに導入します。キーの固定は、この証明書を受け取った後、しばらくの間、証明書の変更を期待してはいけないことをHTTPクライアントに伝えます。その場合、新しい証明書が有効に見えても、クライアントはセキュリティ違反を想定する必要があります。
The Session Initiation Protocol (SIP) [RFC3261] can require several different intermediaries in different stages of the communication to deal with NAT traversal and to handle policy. While both hop-by-hop and end-to-end encryption are specified, in practice, many SIP providers disable these functions. The reasons for disabling end-to-end security here are understandable: to overcome lack of interoperability they often need to change protocol headers and modify protocol data. Some workshop participants argued that SIP would never have taken off if it hadn't been possible for providers to monitor and interfere in communications in this way. Of course, that means an attacker can listen in just as easily.
セッション開始プロトコル（SIP）[RFC3261]は、NATトラバーサルを処理し、ポリシーを処理するために、通信のさまざまな段階でいくつかの異なる仲介者を必要とする場合があります。ホップバイホップとエンドツーエンドの両方の暗号化が指定されていますが、実際には、多くのSIPプロバイダーがこれらの機能を無効にしています。ここでエンドツーエンドのセキュリティを無効にする理由は理解できます。相互運用性の欠如を克服するには、プロトコルヘッダーの変更とプロトコルデータの変更が必要になることがよくあります。一部のワークショップ参加者は、プロバイダーがこの方法で通信を監視して干渉することができなければ、SIPは離陸しないだろうと主張しました。もちろん、これは攻撃者が簡単に傍受できることを意味します。
A new protocol for peer-to-peer communication of video and audio (and potentially other data) is WebRTC. WebRTC reuses many of the same architectural concepts as SIP, but there is a reasonable chance that it can do better in terms of protecting users: The people implementing the protocols and offering the service have different goals and interests. In particular, the first implementers are browser makers, who may have different business models from other more traditional Voice over IP providers.
ビデオとオーディオ（および場合によっては他のデータ）のピアツーピア通信の新しいプロトコルは、WebRTCです。 WebRTCはSIPと同じアーキテクチャの概念の多くを再利用しますが、ユーザーの保護という点でそれがより良い結果をもたらす可能性があります。プロトコルを実装し、サービスを提供する人々は、異なる目標と関心を持っています。特に、最初の実装者はブラウザメーカーであり、他の従来のボイスオーバーIPプロバイダーとは異なるビジネスモデルを持っている可能性があります。
XMPP [RFC6120] suffers from yet a different kind of problem. It has encryption and authentication, and the OTR ("off the record") extension even provides what is called Perfect Forward Secrecy (PFS), i.e., compromising the current communication never gives an attacker enough information to decrypt past communications that he may have recorded. But, in practice, many people don't use XMPP at all, but rather Skype, WhatsApp, or other instant-messaging tools with unknown or no security. The problem here seems to be one of user awareness. And though OTR does provide security, it is not well integrated with XMPP, nor is it available as a core feature of XMPP clients.
XMPP [RFC6120]には、さらに別の種類の問題があります。暗号化と認証があり、OTR（「オフレコ」）拡張機能は、いわゆるPerfect Forward Secrecy（PFS）を提供します。つまり、現在の通信を危険にさらすことで、攻撃者が記録した可能性のある過去の通信を解読するのに十分な情報を与えることはありません。 。しかし実際には、多くの人はXMPPをまったく使用せず、Skype、WhatsApp、またはセキュリティが不明またはまったくない他のインスタントメッセージングツールを使用しています。ここでの問題は、ユーザーの意識の問題のようです。また、OTRはセキュリティを提供しますが、XMPPと十分に統合されておらず、XMPPクライアントのコア機能としても利用できません。
To increase usage of existing solutions, some tasks can be identified; though how those map to actions for, e.g., IETF/W3C is not clear:
既存のソリューションの使用を増やすために、いくつかのタスクを特定できます。これらがIETF / W3Cなどのアクションにどのようにマッピングされるかは不明ですが、
o Improvements to the certificate system, such as certificate transparency (CT).
o 証明書の透過性（CT）など、証明書システムの改善。
o Making it easier (cheaper, quicker) for system administrators to deploy secure solutions.
o システム管理者が安全なソリューションを展開するのを簡単（安価、迅速）にします。
o Improve awareness of the risks. Identify which communities influence which decisions and what is the appropriate message for each.
o リスクの認識を向上させます。どのコミュニティがどの決定に影響を与え、それぞれに適切なメッセージは何かを特定します。
o Provide an upgrade path that doesn't break existing systems or require that everybody upgrade at the same time. Opportunistic Security may be one model for that.
o 既存のシステムに影響を与えない、または全員が同時にアップグレードする必要のないアップグレードパスを提供します。日和見セキュリティはそのためのモデルの1つかもしれません。
Previous sessions already concluded that the problem isn't just technical, such as getting the right algorithms in the standards, fixing interoperability, or educating implementers and systems administrators. There are user interface issues and education issues too. And there are also legal issues and policy issues for governments.
以前のセッションでは、問題は技術的なものではなく、標準で適切なアルゴリズムを取得したり、相互運用性を修正したり、実装者やシステム管理者を教育したりするものではないと既に結論付けています。ユーザーインターフェイスの問題と教育の問題もあります。また、政府には法的な問題や政策的な問題もあります。
It appears that the public, in general, demands more privacy and security (e.g., for their children) but are also pessimistic about getting that. They trust that somebody assures that nothing bad happens to them, but they also expect to be spied on all the time.
一般の人々は、一般に、プライバシーとセキュリティを（たとえば、子供のために）より多く要求しているようですが、それを得ることに悲観的でもあります。彼らは誰かが彼らに悪いことが起こらないことを保証するが、彼らはまた常にスパイされることを期待していると信じています。
(Perceived) threats of terrorism gave governments a reason to allow widespread surveillance, far beyond what may previously have been considered dangerous for freedom.
（知覚された）テロの脅威は、以前は自由のために危険であると考えられていたものをはるかに超えて、政府に広範な監視を許可する理由を与えました。
In this environment, the technical community will have a hard time developing and deploying technologies that fully counter PM, which means there has to be action in the social and political spheres, too.
この環境では、技術コミュニティはPMに完全に対抗する技術の開発と展開に苦労するでしょう。つまり、社会的および政治的領域でも行動が起こらなければなりません。
Technology isn't the only thing that can make life harder for attackers. Government-sponsored PM is indirectly affected by trade agreements and treaties, and thus it makes sense to lobby for those to be as privacy-friendly as possible.
攻撃者の生活を困難にする可能性があるのはテクノロジーだけではありません。政府が後援する首相は、貿易協定や条約の影響を間接的に受けているため、可能な限りプライバシーに配慮するようロビー活動を行うことは理にかなっています。
Court cases on the grounds of human rights can also influence policy, especially if they reach, for example, the European Court of Human Rights.
人権を理由とする訴訟も、特に欧州人権裁判所などに到達した場合は、政策に影響を与える可能性があります。
In medicine and law, it is common to have ethics committees, not so in software. Should standards bodies such as the IETF and W3C have an ethics committee? Standards such as the Geolocation API [w3c-geo-api] have gotten scrutiny from privacy experts, but only in an ad hoc manner. (W3C has permanent groups to review standards for accessibility and internationalisation. It also has a Privacy group, but that currently doesn't do the same kind of systematic reviews.)
医学と法律では、ソフトウェアではなく倫理委員会を設けるのが一般的です。 IETFやW3Cなどの標準化団体は、倫理委員会を持つべきですか？ Geolocation API [w3c-geo-api]などの標準は、プライバシー専門家から精査されていますが、その場しのぎの方法でしかありません。 （W3Cには、アクセシビリティと国際化の基準をレビューする永続的なグループがあります。プライバシーグループもありますが、現在、同じ種類の体系的なレビューは行っていません。）
As the Internet-Draft draft-barnes-pervasive-problem-00 [Barnes] (which was included as paper 44) explains, PM doesn't just monitor the networks, but also attacks at the endpoints, turning organisations or people into (willing, unwilling, or unwitting) collaborators. Note: that document later evolved into [RFC7624]. One technical means of protection is thus to design protocols such that there are fewer potential collaborators, e.g., a provider of cloud storage cannot hand over plaintext for content that is encrypted with a key he doesn't have, and cannot hand over names if his client is anonymous.
Internet-Draft draft-barnes-pervasive-problem-00 [Barnes]（ペーパー44として含まれている）が説明するように、PMはネットワークを監視するだけでなく、エンドポイントでの攻撃も行い、組織や人々を（意欲的な、望まない、または知らない）の共同編集者。注：そのドキュメントは後で[RFC7624]に発展しました。したがって、保護の1つの技術的手段は、潜在的な協力者が少なくなるようにプロトコルを設計することです。たとえば、クラウドストレージのプロバイダーは、所有していないキーで暗号化されたコンテンツのプレーンテキストを引き渡すことができず、名前を引き渡すことができません。クライアントは匿名です。
It is important to distinguish between PM and fighting crime. PM is an attack, but a judge ordering the surveillance of a suspected criminal is not. The latter, often abbreviated in this context as LI (for Lawful Intercept) is outside the scope of this workshop.
首相と闘う犯罪を区別することが重要です。 PMは攻撃ですが、裁判官は犯罪容疑者の監視を命じます。後者は、このコンテキストではLI（合法的傍受用）と呼ばれることが多いため、このワークショップの範囲外です。
An earlier session discussed why existing COMSEC tools weren't used more. This second session on COMSEC therefore discussed what improvements and/or new tools were needed.
以前のセッションでは、既存のCOMSECツールがこれ以上使用されなかった理由について説明しました。したがって、COMSECに関するこの2番目のセッションでは、必要な改善や新しいツール、あるいはその両方について説明しました。
Discussion at the workshop indicated that an important meta-tool for improving existing security technology could be Opportunistic Security (OS) [Kent]. The idea is that software is enhanced with a module that tries to encrypt communications when it detects that the other end also has the same capability, but otherwise it lets the communication continue in the old way. The detailed definition of OS was being discussed by the IETF Security Area Advisory Group at the time of this workshop [SAAG_list].
ワークショップでの議論は、既存のセキュリティ技術を改善するための重要なメタツールが日和見セキュリティ（OS）[ケント]である可能性があることを示しました。アイデアは、相手側にも同じ機能があることを検出したときに通信を暗号化しようとするモジュールでソフトウェアが強化されているということですが、それ以外の場合は、古い方法で通信を継続できます。 OSの詳細な定義は、このワークショップ[SAAG_list]の時点でIETF Security Area Advisory Groupによって議論されていました。
OS would protect against a passive eavesdropper but should also allow for endpoint authentication to protect against an active attacker (a MITM). As OS spreads, more and more communications would be encrypted (and hopefully authenticated), and thus there is less and less for an eavesdropper to collect.
OSはパッシブ盗聴から保護しますが、アクティブな攻撃者（MITM）から保護するためにエンドポイント認証も許可する必要があります。 OSが拡散するにつれて、暗号化された（そしてうまくいけば認証された）通信がますます増えるため、盗聴者が収集する情報はますます少なくなります。
Of course, an implementation of OS could give a false sense of security as well: some connections are encrypted, some are not. A user might see something like a padlock icon in browsers, but there was agreement at the workshop that such user interface features ought not be changed because OS is being used.
もちろん、OSの実装は誤った安心感を与えることもあります。暗号化されている接続と暗号化されていない接続があります。ユーザーはブラウザに南京錠のアイコンのようなものを表示する可能性がありますが、OSが使用されているため、このようなユーザーインターフェイス機能は変更しないでくださいというワークショップでの合意がありました。
There is also the possibility that a MITM intercepts the reply from a server that says "yes, I can do encryption" and removes it, causing the client to fall back to an unencrypted protocol. Mitigations against this can be to have other channels of finding out a server's capabilities and remembering that a server could do encryption previously.
MITMが「はい、私は暗号化を行うことができます」というサーバーからの応答を傍受して削除する可能性もあります。これにより、クライアントは暗号化されていないプロトコルにフォールバックします。これに対する緩和策は、サーバーの機能を見つけ、サーバーが以前に暗号化を実行できることを覚えておく他のチャネルを持つことです。
There is also, again, a terminology problem. The technical descriptions of OS talk about "silent fail" when a connection couldn't be encrypted and has to fall back to the old, unencrypted protocol. Actually, it's not a fail; it's no worse than it was before. A successful encryption would rather be a "silent improvement."
また、用語の問題もあります。 OSの技術的な説明では、接続を暗号化できず、暗号化されていない古いプロトコルにフォールバックする必要がある場合の「サイレントフェイル」について説明しています。実際、それは失敗ではありません。それは以前よりも悪くはありません。暗号化の成功はむしろ「サイレントな改善」となるでしょう。
That raises the question of the UI: How do you explain to a user what their security options are, and, in case an error occurs, how do you explain the implications of the various responses?
これは、UIの問題を提起します。ユーザーにセキュリティオプションとは何かをどのように説明しますか。また、エラーが発生した場合、さまざまな応答の影響をどのように説明しますか。
The people working on encryption are mathematicians and engineers, and typically not the same people who know about UI. We need to involve the experts. We also need to distinguish between usability of the UI, user understanding, and user experience. For an e-commerce site, e.g., it is not just important that the user's data is technically safe, but also that he feels secure. Otherwise, he still won't buy anything.
暗号化に取り組んでいる人々は数学者とエンジニアであり、通常、UIについて知っている人々と同じではありません。私たちは専門家を関与させる必要があります。また、UIの使いやすさ、ユーザーの理解、ユーザーエクスペリエンスを区別する必要があります。たとえばeコマースサイトの場合、ユーザーのデータが技術的に安全であるだけでなく、ユーザーが安全であると感じることも重要です。そうでなければ、彼はまだ何も購入しません。
When talking about users, we also need to distinguish the end user (who we typically think about when we talk about UI) from the server administrators and other technical people involved in enabling a connection. When something goes wrong (e.g., the user's software detects an invalid certificate), the message usually goes to the end user. But, he isn't necessarily the person who can do something about it. For example, if the problem is a certificate that expired yesterday, the options for the user are to break the connection (the safe choice, but it means he can't get his work done) or continue anyway (there could be a MITM). The server administrator, on the other hand, could actually solve the problem.
ユーザーについて話すときは、エンドユーザー（UIについて話すときによく考えるユーザー）を、サーバー管理者や接続の有効化に関わる他の技術者と区別する必要もあります。問題が発生した場合（ユーザーのソフトウェアが無効な証明書を検出した場合など）、メッセージは通常エンドユーザーに送信されます。しかし、彼はそれについて何かをすることができる人である必要はありません。たとえば、問題が昨日期限切れになった証明書である場合、ユーザーのオプションは、接続を切断する（安全な選択ですが、作業を完了できないことを意味します）か、とにかく続行します（MITMが存在する可能性があります）。 。一方、サーバー管理者は実際に問題を解決できます。
Encryption and authentication have a cost, in terms of setting them up, but also in terms of the time it takes for software to do the calculations. The setup cost can be reduced with sensible defaults, predefined profiles, and cut-and-paste configurations. And for some connections, authentication without encryption could be enough, in the case that the data doesn't need to be kept secret, but it is important to know that it is the real data. Most mail user agents (UA) already provide independent options for encryption and signing, but web servers only support authentication if the connection is also encrypted.
暗号化と認証には、セットアップの点だけでなく、ソフトウェアが計算を行うのにかかる時間の点でもコストがかかります。賢明なデフォルト、事前定義されたプロファイル、カットアンドペースト構成により、セットアップコストを削減できます。また、一部の接続では、データを秘密にしておく必要がない場合は、暗号化なしの認証で十分ですが、それが実際のデータであることを知っておくことが重要です。ほとんどのメールユーザーエージェント（UA）は、暗号化と署名の独立したオプションを既に提供していますが、Webサーバーは、接続も暗号化されている場合にのみ認証をサポートします。
On the other hand, as email also shows, it is difficult for users to understand what encryption and authentication do separately.
一方、電子メールでもわかるように、暗号化と認証を別々に行うことをユーザーが理解することは困難です。
It also has to be kept in mind that encrypting only the "sensitive" data and not the rest decreases the cost for an attacker, too: It becomes easy to know which connections are worth attacking. Selective field confidentiality is also more prone to lead to developer error, as not all developers will know the provenance of values to be processed.
また、「機密」データのみを暗号化し、残りは暗号化しないことで、攻撃者のコストも削減されることにも注意してください。どの接続が攻撃に値するかを簡単に知ることができます。すべての開発者が処理される値の出所を知っているわけではないため、選択的なフィールド機密性は開発者のエラーにつながる傾向があります。
One problem with the TOFU model as used by SSH (see explanation above) is that it lacks a solution for key continuity: When a key is changed (which can happen, e.g., when a server is replaced or the software upgraded), there is no way to inform the client. (In practice, people use other means, such as calling people on the phone or asking their colleagues in the office, but that doesn't scale and doesn't always happen either.) An improvement in the SSH protocol could thus be a way to transfer a new key to a client in a safe way.
SSHで使用されるTOFUモデルの問題の1つ（上記の説明を参照）には、キーの連続性のソリューションがないことです。キーが変更された場合（サーバーが交換された場合やソフトウェアがアップグレードされた場合など）、クライアントに通知する方法はありません。 （実際には、電話で電話をかけたり、オフィスの同僚に尋ねたりするなど、他の手段を使用しますが、これはスケーリングされず、常に発生するとは限りません。）したがって、SSHプロトコルの改善が1つの方法になる可能性があります。安全な方法で新しいキーをクライアントに転送します。
Encryption and authentication help protect the content of messages. Correctly implemented encryption is very hard to crack. (To get the content, an attacker would rather attempt to steal the keys, corrupt the encoding software, or get the content via a collaborator. See [RFC7624] for more information on "collaborator".) But encrypting the content doesn't hide the fact that you are communicating. This metadata (who talks to whom, when, and for how long) is often as interesting as the content itself, and in some cases the size and timing of messages is even an accurate predictor of the content. So how to stop an attacker from collecting metadata, given that much of that data is actually needed by routers and other services to deliver the message to the right place?
暗号化と認証は、メッセージの内容を保護するのに役立ちます。正しく実装された暗号化は解読が非常に困難です。 （コンテンツを取得するために、攻撃者はキーを盗むか、エンコードソフトウェアを破損させるか、コラボレーターを介してコンテンツを取得しようとします。「コラボレーター」の詳細については、[RFC7624]を参照してください。）ただし、コンテンツを暗号化しても非表示にはなりません。あなたがコミュニケーションしているという事実。このメタデータ（だれが、だれと、いつ、どのくらいの時間会話するか）は、コンテンツ自体と同じくらい興味深い場合が多く、場合によっては、メッセージのサイズとタイミングがコンテンツの正確な予測子でさえあります。では、ルーターやその他のサービスがメッセージを適切な場所に配信するために実際に大量のデータが必要であることを踏まえて、攻撃者がメタデータを収集しないようにするにはどうすればよいでしょうか。
It is useful to distinguish different kinds of metadata: explicit (or metadata proper) and implicit (sometimes called traffic data). Implicit metadata is things that can be derived from a message or are necessary for its delivery, such as the destination address, the size, the time, or the frequency with which messages pass. Explicit metadata is things like quality ratings, provenance, or copyright data: data about the data, useful for an application, but not required to deliver the data to its endpoint.
明示的（または適切なメタデータ）と暗黙的（トラフィックデータと呼ばれることもある）の異なる種類のメタデータを区別すると便利です。暗黙的なメタデータとは、宛先アドレス、サイズ、時間、メッセージが通過する頻度など、メッセージから派生したり、メッセージの配信に必要なものです。明示的なメタデータとは、品質評価、来歴、著作権データなどのデータです。データに関するデータで、アプリケーションには役立ちますが、エンドポイントにデータを配信する必要はありません。
A system such as Tor hides much of the metadata by passing through several servers, encrypting all the data except that which a particular server needs to see. Each server thus knows which server a message came from and where it has to send it to, but cannot know where the previous server got it from or where the next server is instructed to send it. However, deliberately passing through multiple servers makes the communication slower than taking the most direct route and increases the amount of traffic the network as a whole has to process.
Torなどのシステムは、複数のサーバーを通過することでメタデータの大部分を隠し、特定のサーバーが参照する必要があるデータ以外のすべてのデータを暗号化します。したがって、各サーバーは、メッセージがどのサーバーから送信され、どこにメッセージを送信する必要があるかを認識しますが、前のサーバーがメッセージをどこから取得したか、または次のサーバーがメッセージを送信するように指示されています。ただし、意図的に複数のサーバーを通過させると、通信が最も直接的なルートを取るよりも遅くなり、ネットワーク全体が処理する必要のあるトラフィックの量が増加します。
There are three kinds of measures that can be taken to make metadata harder to get: aggregation, contraflow, and multipath (see "Flows and Pervasive Monitoring" [Paper4]). New protocols should be designed such that these measures are not inadvertently disallowed, e.g., because the design assumes that the whole of a conversation passes through the same route.
メタデータを取得するのを困難にするために取ることができる3種類の対策があります：集約、コントラフロー、およびマルチパス（「フローとパーベイシブモニタリング」[Paper4]を参照）。たとえば、設計では会話全体が同じルートを通過すると想定されているため、これらの措置が不注意で許可されないように、新しいプロトコルを設計する必要があります。
"Aggregation" means collecting conversations from multiple sources into one stream. For example, if HTTP connections pass through a proxy, all the conversations appear to come from the proxy instead of from their original sources. (This assumes that telltale information in the headers is stripped by the proxy or that the connection is encrypted.) It also works in the other direction: if multiple web sites are hosted on the same server, an attacker cannot see which of those web sites a user is reading. (This assumes that the name of the site is in the path info of the URL and not in the domain name; otherwise, watching DNS queries can still reveal the name.)
「集約」とは、複数のソースからの会話を1つのストリームに収集することを意味します。たとえば、HTTP接続がプロキシを通過する場合、すべての会話は元のソースからではなく、プロキシからのものであるように見えます。 （これは、ヘッダー内のテルテール情報がプロキシによって取り除かれているか、接続が暗号化されていることを前提としています。）それは逆方向にも機能します。複数のWebサイトが同じサーバーでホストされている場合、攻撃者はそれらのWebサイトを確認できませんユーザーが読んでいます。 （これは、サイトの名前がドメイン名ではなく、URLのパス情報に含まれていることを前提としています。それ以外の場合、DNSクエリを監視しても名前が明らかになる可能性があります。）
"Contraflow" means routing a conversation via one or more other servers than the normal route, e.g., by using a tunnel (e.g., with SSH or a VPN) to another server. Tor is an example of this. An attacker must watch more routes and do more effort to correlate conversations. (Again, this assumes that there is no telltale information left in the messages that leave the tunnel.)
「コントラフロー」とは、通常のルート以外の1つ以上のサーバーを介して、別のサーバーへのトンネル（SSHまたはVPNなど）を使用して、会話をルーティングすることを意味します。 Torはその一例です。攻撃者はより多くのルートを監視し、会話を関連付けるためにより多くの努力をする必要があります。 （繰り返しますが、これは、トンネルを出るメッセージにわかりにくい情報が残っていないことを前提としています。）
"Multipath" splits up a single conversation (or a set of related conversations) and routes the parts in different ways, e.g., sending a request via a satellite link and receiving the response via a land line, or starting a conversation on a cellular link and continuing it via Wi-Fi. This again increases the cost for an attacker, who has to monitor and correlate data traversing multiple networks.
「マルチパス」は、単一の会話（または関連する会話のセット）を分割し、さまざまな方法でパーツをルーティングします。たとえば、衛星リンクを介して要求を送信し、固定電話を介して応答を受信する、またはセルラーリンクで会話を開始します。 Wi-Fi経由で続行します。これにより、複数のネットワークを通過するデータを監視して相関させる必要のある攻撃者のコストも増加します。
Protecting metadata automatically with technology at a lower layer than the application layer is difficult. The applications themselves need to pass less data, e.g., use anonymous temporary handles instead of permanent identifiers. There is often no real need for people to use the same identifier on different computers (smartphone, desktop, etc.) other than that the application they use was designed that way.
アプリケーションレイヤーよりも下位のレイヤーでテクノロジーを使用してメタデータを自動的に保護することは困難です。アプリケーション自体が渡すデータは少なくて済みます。たとえば、永続的な識別子の代わりに匿名の一時ハンドルを使用します。多くの場合、使用するアプリケーションがそのように設計されている場合を除いて、人々が異なるコンピューター（スマートフォン、デスクトップなど）で同じ識別子を使用する必要はありません。
One thing that can be done relatively easily in the short term is to go through existing protocols to check what data they send that isn't really necessary. One candidate mentioned for such a study was XMPP.
短期間に比較的簡単に実行できることの1つは、既存のプロトコルを調べて、実際に必要ではないデータを送信するかどうかを確認することです。このような研究で言及された候補の1つはXMPPでした。
"Fingerprinting" is the process of distinguishing different senders of messages based on metadata [RFC6973]: Clients can be recognised (or at least grouped) because their messages always have a combination of features that other clients' messages do not have. Reducing redundant metadata and reducing the number of optional features in a protocol reduces the variation between clients and thus makes fingerprinting harder.
「フィンガープリント」は、メタデータ[RFC6973]に基づいてメッセージの異なる送信者を区別するプロセスです。クライアントのメッセージは常に他のクライアントのメッセージにはない機能の組み合わせを持っているため、クライアントを認識（または少なくともグループ化）できます。冗長なメタデータを減らし、プロトコルのオプション機能の数を減らすと、クライアント間のばらつきが減り、フィンガープリントの作成が難しくなります。
Traffic analysis is a research discipline that produces sometimes surprising findings that are little known among protocol developers. Some collections of results are
トラフィック分析は、プロトコル開発者の間でほとんど知られていない驚くべき発見を時々生み出す研究分野です。結果のいくつかのコレクションは
o a selected bibliography on anonymity by the Free Haven Project <http://freehaven.net/anonbib/>,
o Free Haven Project <http://freehaven.net/anonbib/>による匿名性に関する選択された参考文献、
o the yearly Symposium on Privacy Enhancing Technologies (PETS) <http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>, and
o プライバシー強化テクノロジ（PETS）に関する毎年のシンポジウム<http://www.informatik.uni-trier.de/~Ley/db/conf/pet/index.html>、および
o the yearly Workshop on Privacy in the Electronic Society (WPES) <http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html>.
o 電子社会におけるプライバシーに関する毎年のワークショップ（WPES）<http://www.informatik.uni-trier.de/~Ley/db/conf/wpes/index.html>。
Techniques that deliberately change the timing or size of messages, such as padding, can also help reduce traffic analysis. Obviously, they make conversations slower and/or use more bandwidth, but in some cases that is not an issue, e.g., if the conversation is limited by the speed of a human user anyway. HTTP/2, for example, has a built-in padding mechanism. However, it is not easy to use these techniques well and make messages harder to recognise (as intended) rather than easier.
パディングなど、メッセージのタイミングやサイズを意図的に変更する手法も、トラフィック分析の削減に役立ちます。明らかに、それらは会話を遅くしたり、より多くの帯域幅を使用したりします。ただし、会話が人間のユーザーの速度によって制限されている場合など、場合によってはそれは問題ではありません。たとえば、HTTP / 2には組み込みの埋め込みメカニズムがあります。ただし、これらの手法をうまく使用してメッセージを（意図したとおりに）認識するのは容易ではなく、難しくなります。
Different users in different contexts may have different security needs, so maybe the priority can be a user choice (if that can be done without making high-security users stand out from other users). Although many people would not understand what their choices are, some do, such as political activists or journalists.
異なるコンテキストの異なるユーザーは異なるセキュリティニーズを持っている可能性があるため、優先度はユーザーの選択である可能性があります（高セキュリティユーザーを他のユーザーから際立たせることなく実行できる場合）。多くの人は自分の選択が何であるかを理解していませんが、政治活動家やジャーナリストなど、一部の人は理解しています。
Secure protocols have often been designed in the past for end-to-end security: Intermediaries cannot read or modify the messages. This is the model behind TLS, for example.
安全なプロトコルは、多くの場合、エンドツーエンドのセキュリティのために過去に設計されてきました。中間者はメッセージを読み取ったり変更したりできません。これは、たとえばTLSの背後にあるモデルです。
In practice, however, people have more or less valid reasons to insist on intermediaries: companies filtering incoming and outgoing traffic for viruses, inspecting content to give priority to certain applications, or caching content to reduce bandwidth.
ただし、実際には、中間者を主張する正当な理由があります。企業は、着信トラフィックと発信トラフィックのウイルスをフィルタリングし、コンテンツを検査して特定のアプリケーションを優先するか、コンテンツをキャッシュして帯域幅を減らします。
In the presence of end-to-end encryption and authentication, these intermediaries have two choices: use fake certificates to impersonate the endpoints or have access to the private keys of the endpoints. The former is a MITM attack that is difficult to distinguish from a more malicious one, and the latter obviously decreases the security of the endpoints by copying supposedly confidential information and concentrating credentials in a single place.
エンドツーエンドの暗号化と認証が存在する場合、これらの仲介者には2つの選択肢があります。偽の証明書を使用してエンドポイントを偽装するか、エンドポイントの秘密鍵にアクセスします。前者はより悪意のある攻撃と区別が難しいMITM攻撃であり、後者は明らかに機密情報と思われる情報をコピーして資格情報を1か所に集中させることにより、エンドポイントのセキュリティを明らかに低下させます。
As mentioned in Section 5.2 above, aggregation of data in a single place makes that place an attractive target. And in the case of PM, even if the data is not concentrated physically in one place, it is under control of a single legal entity that can be made into a collaborator.
上記のセクション5.2で述べたように、単一の場所でのデータの集約は、その場所を魅力的なターゲットにします。 PMの場合、データが物理的に1か所に集中していなくても、単一の法人の管理下にあり、共同作業者にすることができます。
The way Web communication with TLS typically works is that the client authenticates the server, but the server does not authenticate the client at the TLS layer. (If the user needs to be identified, that is mainly done at the application layer via username and password.) Thus, the presence of a MITM (middlebox) could be detected by the client (because of the incorrect certificate), but not by the server. If the client doesn't immediately close the connection (which they do not in many cases), the server may thus disclose information that the user would rather not have disclosed.
TLSを使用したWeb通信は通常、クライアントがサーバーを認証しますが、サーバーはTLS層でクライアントを認証しません。 （ユーザーを特定する必要がある場合は、主にアプリケーション層でユーザー名とパスワードを使用して行われます。）したがって、MITM（ミドルボックス）の存在はクライアントによって検出されます（証明書が正しくないため）。サーバー。クライアントが接続をすぐに閉じない場合（多くの場合そうではありません）、サーバーは、ユーザーが公開したくない情報を公開する可能性があります。
One widespread example of middleboxes is captive portals, as found on the Wi-Fi hotspots in hotels, airports, etc. Even the hotspots offering free access often intercept communications to redirect the user to a login or policy page.
ホテルや空港などのWi-Fiホットスポットにあるように、ミドルボックスの普及例の1つはキャプティブポータルです。無料アクセスを提供するホットスポットでさえ、通信を傍受してユーザーをログインページまたはポリシーページにリダイレクトすることがよくあります。
When the communication they intercept is, e.g., the automatic update of your calendar program or a chat session, the redirect obviously doesn't work: these applications don't know how to display a web page. With the increasing use of applications, it may be a while before the user actually opens a browser. The flood of error messages may also have as a result that the user no longer reads the errors, allowing an actual malicious attack to go unnoticed.
彼らが傍受する通信が、たとえばカレンダープログラムやチャットセッションの自動更新である場合、リダイレクトは明らかに機能しません。これらのアプリケーションはWebページの表示方法を認識していません。アプリケーションの使用の増加に伴い、ユーザーが実際にブラウザーを開くまでに時間がかかる場合があります。エラーメッセージの洪水により、ユーザーがエラーを読み取ることができなくなり、実際の悪意のある攻撃に気付かれない可能性もあります。
Some operating systems now come with heuristics that try to recognise captive portals and either automatically login or show their login page in a separate application. (But, some hotspot providers apparently don't want automatic logins and actually reverse-engineered the heuristics to try and fool them.)
一部のオペレーティングシステムには、キャプティブポータルを認識し、自動的にログインするか、別のアプリケーションでログインページを表示するヒューリスティックが搭載されています。 （しかし、一部のホットスポットプロバイダーは、自動ログインを望まないようであり、実際にヒューリスティックをリバースエンジニアリングして、それらを試行錯誤します。）
It seems some protocol is missing in this case. Captive portals shouldn't have to do MITM attacks to be noticed. A mechanism at the link layer or an extension to DHCP that tells a connecting device about the login page may help, although that still doesn't solve the problem for devices that do not have a web browser, such as voice over IP phones. HTTP response code 511 (defined in [RFC6585]) is another attempt at a partial solution. (It's partial because it can only work at the moment the user uses a browser to connect to a web site and doesn't use HTTPS.)
この場合、一部のプロトコルが欠落しているようです。キャプティブポータルは、MITM攻撃を行う必要はありません。ログインページについて接続デバイスに通知するリンク層のメカニズムまたはDHCPの拡張機能が役立つ場合がありますが、Voice over IP PhoneなどのWebブラウザーを備えていないデバイスの問題は解決されません。 HTTP応答コード511（[RFC6585]で定義）は、部分的な解決策のもう1つの試みです。 （ユーザーがブラウザを使用してWebサイトに接続し、HTTPSを使用していないときにのみ機能するため、部分的です。）
A practical problem with deployment of such a protocol may be that many such captive portals are very old and never updated. The hotel staff only knows how to reboot the system, and, as long as it works, the hotel has no incentive to buy a new one. As evidence of this: how many such systems require you to get a password and the ticket shows the price as zero? This is typically because the owner doesn't know how to reconfigure the hotspot, but he does know how to change the price in his cash register.
このようなプロトコルの展開に関する実際的な問題は、そのようなキャプティブポータルの多くが非常に古く、更新されないことです。ホテルのスタッフはシステムを再起動する方法しか知りません。システムが機能する限り、ホテルには新しいシステムを購入する動機はありません。これを証明するものとして：パスワードを取得する必要のあるシステムがいくつあり、チケットには価格がゼロと表示されていますか？これは通常、所有者がホットスポットを再構成する方法を知らないが、レジの価格を変更する方法を知っているためです。
Despite some requests earlier in the workshop, the research break-out did not discuss clean-slate approaches. The challenge was rather that the relationship between security research and standardisation needs improvement. Research on linkability is not yet well known in the IETF. But, the other side of the coin needs improvement too: While doing protocol design, standardisation organisations should indicate what specific problems are in need of more research.
ワークショップの早い段階でいくつかの要求があったにもかかわらず、研究の分科会では白紙のアプローチについては議論されませんでした。問題は、セキュリティの研究と標準化の関係を改善する必要があるということでした。リンクに関する研究は、IETFではまだよく知られていません。しかし、コインの反対側にも改善が必要です。プロトコルの設計を行っている間、標準化組織は、特定の問題がさらに調査を必要としていることを示す必要があります。
The break-out then made a nonexhaustive list of topics that are in need of further research:
その後、分科会は、さらなる研究を必要とするトピックの非網羅的なリストを作成しました：
o The interaction of compression and encryption as demonstrated by the CRIME ("Compression Ratio Info-leak Made Easy") SSL/TLS vulnerability [Ristic]
o CRIME（ "Compression Ratio Info-leak Made Easy"）のSSL / TLSの脆弱性[Ristic]で実証されている、圧縮と暗号化の相互作用
o A more proactive deprecation of algorithms based on research results
o 研究結果に基づく、より積極的なアルゴリズムの廃止
o Mitigation for return-oriented programming attacks
o リターン指向のプログラミング攻撃の軽減策
o How to better obfuscate so-called "metadata" o How to make the existence of traffic and their endpoints stealthy
oいわゆる「メタデータ」をより難読化する方法oトラフィックとそのエンドポイントの存在を隠蔽する方法
Browsers are the first clients one thinks of when talking about encrypted connections, authentication, and certificates, but there are many others.
ブラウザは、暗号化された接続、認証、および証明書について話すときに最初に思いつくクライアントですが、他にもたくさんあります。
Other common cases of "false" alarms for MITM (after captive portals) include expired and misconfigured certificates. This is quite common in intranets, when the sysadmin hasn't bothered updating a certificate and rather tells his handful of users to just "click continue." The problem is on the one hand that users may not understand the difference between this case and the same error message when they connect to a server outside the company, and on the other hand that the incorrect certificate installed by the sysadmin is not easily distinguishable from an incorrect certificate from a MITM. The error message is almost the same, and the user may just click continue again.
MITM（キャプティブポータル後）の「誤」アラームの他の一般的なケースには、期限切れの証明書や誤って設定された証明書が含まれます。これは、イントラネットでは非常に一般的です。システム管理者が証明書の更新を気にせず、少数のユーザーに「クリックして続行」するように指示する場合です。問題の1つは、ユーザーが社外のサーバーに接続したときに、このケースと同じエラーメッセージの違いを理解できないことであり、もう1つは、sysadminによってインストールされた不正な証明書と簡単に区別できないことです。 MITMからの誤った証明書。エラーメッセージはほとんど同じで、ユーザーはもう一度[続行]をクリックするだけです。
One way to get rid of such certificates is if client software no longer offers the option to continue after a certificate error. That requires that all major clients (such as browsers) change their behaviour at the same time; otherwise, the first one to do so will be considered broken by users, because the others still work. Also, it requires a period in which that software gives increasingly strong warnings about the cut-off date after which the connection will fail with this certificate.
そのような証明書を取り除く1つの方法は、クライアントソフトウェアが証明書エラーの後に続行するオプションを提供しない場合です。そのためには、すべての主要なクライアント（ブラウザなど）がその動作を同時に変更する必要があります。それ以外の場合、他のユーザーが引き続き機能するため、最初にそうしたユーザーはユーザーによって破損したと見なされます。また、この証明書を使用して接続が失敗するまでに、ソフトウェアが締切日についてますます強い警告を出す期間が必要です。
Yet another source of error messages is self-signed certificates. Such certificates are actually only errors for sites that are not expected to have them. If a message about a self-signed certificate appears when connecting to Facebook or Google, you're clearly not connected to the real Facebook or Google. But, for a personal web site, it shouldn't cause such scary warnings. There may be ways to improve the explanations in the error message and provide an easy way to verify the certificate (by email, phone, or some other channel) and trust it.
エラーメッセージのさらに別の原因は、自己署名証明書です。このような証明書は、実際には、それらが存在することが予期されていないサイトの単なるエラーです。 FacebookまたはGoogleに接続するときに自己署名証明書に関するメッセージが表示される場合は、実際のFacebookまたはGoogleに接続していないことは明らかです。しかし、個人のWebサイトの場合、そのような恐ろしい警告を引き起こすべきではありません。エラーメッセージの説明を改善し、証明書を（電子メール、電話、またはその他のチャネルで）確認して信頼する簡単な方法を提供する方法がある場合があります。
One step in improving security is to require the relevant features (in particular, encryption and authentication) to be implemented in compliant products: The features are labelled as "MUST" in the standard rather than "MAY". This is sometimes referred to as Mandatory To Implement (MTI) and is the current practice for IETF protocols [RFC3365].
セキュリティを向上させるための1つの手順は、関連する機能（特に、暗号化と認証）を準拠製品に実装することを要求することです。これらの機能には、「MAY」ではなく「MUST」というラベルが付けられています。これは実装が必須（MTI）と呼ばれることもあり、IETFプロトコル[RFC3365]の現在の慣例です。
But, that may not be enough to counter PM. It may be that the features are there, but not used, because only very knowledgeable users or sysadmins turn them on. Or, it may be that implementations do not actually follow the MTI parts of specifications. Or, it may be that some security features are implemented, but interoperability for those doesn't really work. Or, even worse, it may be that protocol designers have only followed the letter of the MTI best practice and not its spirit, with the result that security features are hard to use or make deployment harder. One can thus argue that such features should be defined to be on by default.
しかし、それだけではPMに対抗するには不十分かもしれません。非常に知識のあるユーザーまたはシステム管理者だけが機能をオンにしているため、機能はあるが使用されていない可能性があります。または、実装が実際に仕様のMTI部分に従っていない可能性があります。または、一部のセキュリティ機能が実装されている可能性がありますが、それらの相互運用性は実際には機能しません。または、さらに悪いことに、プロトコル設計者がMTIのベストプラクティスに準拠しているだけで、その精神に従っていないために、セキュリティ機能が使いづらい、または展開が難しくなっている可能性があります。したがって、このような機能はデフォルトでオンになるように定義する必要があると主張できます。
Going further, one might argue that these features should not even be options, i.e., there should be no way to turn them off. This is sometimes called Mandatory To Use (MTU).
さらに進んで、これらの機能はオプションであってはならない、つまり、それらをオフにする方法はないはずだと主張する人もいるかもしれません。これは、Mandatory To Use（MTU）と呼ばれることもあります。
The questions raised at this session were for what protocols is on-by-default appropriate, and how can one explain to the developers of such protocols that it is needed?
このセッションで出された質問は、どのプロトコルがデフォルトで適切であるか、そしてそのようなプロトコルの開発者にそれが必要であることをどのように説明できるかということでした
Of course, there would be resistance to MTU security from implementers and deployments that practice deep packet inspection (DPI) and also perhaps from some governments. On the other hand, there may also be governments that outlaw protocols without proper encryption.
もちろん、ディープパケットインスペクション（DPI）を実践する実装者や展開、さらにはおそらく一部の政府からのMTUセキュリティへの抵抗があります。一方、適切な暗号化なしにプロトコルを非合法にする政府も存在する可能性があります。
This break-out concluded that there could be value in attempting to document a new Best Current Practice for the IETF that moves from the current MTI position to one where security features are on by default. Some of the workshop participants expressed interest in authoring a draft for such a new BCP and progressing it through the IETF consensus process (where it would no doubt be controversial).
このブレイクアウトは、現在のMTIの位置からデフォルトでセキュリティ機能がオンになっている位置に移動するIETFの新しいベストプラクティスを文書化しようとする価値があると結論付けました。ワークショップ参加者の一部は、そのような新しいBCPのドラフトを作成し、IETFの合意プロセス（間違いなく論争の余地がある）を通じてそれを進めることに関心を示しました。
There was a small break-out on the idea of measurement as a way to encourage or gamify the increased use of security mechanisms.
セキュリティメカニズムの使用の増加を奨励または模倣する方法としての測定の考えには、小さなブレイクアウトがありました。
This break-out considered the use of the term "opportunistic" as it applies to cryptographic security and attempted to progress the work towards arriving at an agreed-upon definition for use of that term, at it applies to IETF and W3C work.
このブレイクアウトでは、暗号化セキュリティに適用される「日和見」という用語の使用を検討し、IETFおよびW3Cの作業に適用される場合に、その用語の使用について合意された定義に到達するために作業を進めようとしました。
While various terms had been used, with many people talking about opportunistic encryption, that usage was felt to be problematic both because it conflicted with the use of the same term in [RFC4322] and because it was being used differently in different parts of the community.
さまざまな用語が使用されていましたが、多くの人が日和見暗号化について話していましたが、その使用は、[RFC4322]での同じ用語の使用と競合し、コミュニティのさまざまな部分で異なって使用されていたため、問題があると感じられました。
At the session, it was felt that the term "opportunistic keying" was better, but, as explained above, subsequent list discussion resulted in a move to the term "Opportunistic Security" (OS).
セッションでは、「日和見キーイング」という言葉の方がいいと感じましたが、前述のように、その後のリストの議論の結果、「日和見セキュリティ」（OS）という言葉に移動しました。
Aside from terminology, discussion focused on the use of Diffie-Hellman (D-H) key exchange as the preferred mechanism of OS, with fall back to cleartext if D-H doesn't succeed as a counter for passive attacks.
用語の他に、OSの優先メカニズムとしてDiffie-Hellman（D-H）鍵交換の使用に焦点を当て、D-Hがパッシブ攻撃のカウンターとして成功しない場合は平文にフォールバックします。
There was also, of course, the desire to be able to easily escalate from countering passive attacks to also handling endpoint authentication and thereby also countering MITM attacks.
もちろん、パッシブ攻撃への対応からエンドポイント認証の処理へと簡単にエスカレートし、それによりMITM攻撃への対応も可能にしたいという要望もありました。
Making OS visible to users was again considered to be undesirable, as users could not be expected to distinguish between cleartext, OS, and (one-sided or mutual) endpoint authentication.
ユーザーがクリアテキスト、OS、および（片側または相互）エンドポイント認証を区別することは期待できないため、OSをユーザーに表示することは望ましくないと見なされていました。
Finally, it was noted that it may take some effort to establish how middleboxes might affect OS at different layers and that OS really is not suitable as the only mitigation to use for high-sensitivity sessions such as financial transactions.
最後に、ミドルボックスが異なるレイヤーのOSにどのように影響するかを確立するために多少の労力が必要であり、金融取引などの機密性の高いセッションに使用する唯一の緩和策としてOSは実際には適していないことが指摘されました。
Some routing and transport Area Directors felt a little left out by all the application-layer break-outs, so they had their own brainstorm about what could be done at the transport and routing layers from which these notes resulted.
一部のルーティングおよびトランスポートのエリアディレクターは、すべてのアプリケーションレイヤーのブレイクアウトによって少し取り残されていると感じたため、これらのメモの元となったトランスポートおよびルーティングレイヤーで何ができるかについて独自のブレインストーミングを行いました。
The LEDBAT [RFC6817] protocol was targeted towards a bulk-transfer service that is reordering- and delay-insensitive. Use of LEDBAT could offer the following benefits for an application:
LEDBAT [RFC6817]プロトコルは、並べ替えや遅延の影響を受けないバルク転送サービスを対象としていました。 LEDBATを使用すると、アプリケーションに次のような利点があります。
a. Because it is reordering-insensitive, traffic can be sprayed across a large number of forwarding paths. Assuming such different paths exist, this would make it more challenging to capture and analyze a full interaction.
a. 並べ替えの影響を受けないため、トラフィックは多数の転送パスに散布される可能性があります。このような異なるパスが存在すると想定すると、完全な相互作用をキャプチャして分析することがより困難になります。
b. The application can vary the paths by indicating per packet a different flow. In IPv6, this can be done via different IPv6 flow labels. For IPv4, this can be done by encapsulating the IP packet into UDP and varying the UDP source port.
b. アプリケーションは、パケットごとに異なるフローを示すことにより、パスを変更できます。 IPv6では、これは異なるIPv6フローラベルを介して行うことができます。 IPv4の場合、これはIPパケットをUDPにカプセル化し、UDP送信元ポートを変更することで実行できます。
c. Since LEDBAT is delay-insensitive and applications using it would need to be as well, it would be possible to obfuscate the application signatures by varying the packet lengths and frequency.
c. LEDBATは遅延の影響を受けず、それを使用するアプリケーションも同様に必要であるので、パケットの長さと頻度を変えることによってアプリケーションの署名を難読化することが可能です。
d. This can also hide the transport header (for IP in UDP).
d. これにより、トランスポートヘッダーを非表示にすることもできます（UDPのIPの場合）。
e. If the Reverse Path Forwarding (RPF) [RFC3704] check problem can be fixed, perhaps the source could be hidden; however, such fixes assume the traffic is within trusted perimeters.
e. リバースパスフォワーディング（RPF）[RFC3704]チェックの問題を修正できる場合、ソースが隠されている可能性があります。ただし、このような修正では、トラフィックが信頼できる境界内にあると想定しています。
f. The use of LEDBAT is orthogonal to the use of encryption and provides different benefits (harder to intercept the whole conversation, ability to obfuscate the traffic analysis), and it has different costs (longer latency, new transport protocol usage) to its users.
f. LEDBATの使用は暗号化の使用と直交しており、さまざまな利点（会話全体を傍受することが困難、トラフィック分析を難読化する機能）を提供し、ユーザーにはさまざまなコスト（長い待ち時間、新しいトランスポートプロトコルの使用）があります。
The idea of encrypting traffic from Customer Edge (CE) to CE as part of an L3VPN or such was also discussed. This could allow hiding of addresses, including source, and headers. From conversation with Ron Bonica, it's clear that some customers already do encryption (though without hiding the source address). So, rather than an enhancement, this is an existing mechanism for which deployment and use can be encouraged.
L3VPNなどの一部として、カスタマーエッジ（CE）からCEへのトラフィックを暗号化するアイデアについても説明しました。これにより、ソースやヘッダーを含むアドレスを隠すことができます。 Ron Bonicaとの会話から、一部の顧客が既に暗号化を行っていることは明らかです（ただし、送信元アドレスを非表示にしないでください）。したがって、これは拡張ではなく、既存のメカニズムであり、展開と使用を促進できます。
Finally, it was discussed whether it would be useful to have a means of communicating where and what layers are doing encryption on an application's traffic path. The initial idea of augmenting ICMP has some issues (not visible to application, ICMP packets frequently filtered) as well as potential work (determining how to trust the report of encryption). It would be interesting to understand if such communication is actually needed and what the requirements would be.
最後に、アプリケーションのトラフィックパスのどこでどのレイヤーが暗号化を行っているかを伝達する手段が役立つかどうかについても議論されました。 ICMPを拡張するという最初のアイデアには、潜在的な作業（暗号化のレポートを信頼する方法を決定する）だけでなく、いくつかの問題（アプリケーションからは見えない、ICMPパケットが頻繁にフィルターされる）があります。そのようなコミュニケーションが実際に必要かどうか、および要件は何かを理解することは興味深いでしょう。
Holding the workshop just before the IETF had the intended effect: a number of people went to both the workshop and the IETF, and they took the opportunity of being together at the IETF to continue the discussions.
IETFが意図した効果が出る直前にワークショップを開催した。多くの人々がワークショップとIETFの両方に行き、IETFに集まる機会を得て議論を続けた。
IETF working groups meeting in London took the recommendations from the workshop into account. It was even the first item in the report about the IETF meeting by the IETF chair, Jari Arkko:
ロンドンで開催されたIETFワーキンググループは、ワークショップの提案を考慮に入れました。それは、IETF議長のJari ArkkoによるIETF会議に関する報告書の最初の項目でさえありました。
Strengthening the security and privacy of the Internet continued to draw a lot of attention. The STRINT workshop organised by the IAB and W3C just before the IETF attracted 100 participants and over 60 papers. Even more people would have joined us, but there was no space. During the IETF meeting, we continued discussing the topic at various working groups. A while ago we created the first working group specifically aimed at addressing some of the issues surrounding pervasive monitoring. The Using TLS for Applications (UTA) working group had its first meeting in London. But many other working groups also address these issues in their own work. The TCPM working group discussed a proposal to add opportunistic keying mechanisms directly onto the TCP protocol. And the DNSE BOF considered the possibility of adding confidentiality support to DNS queries. Finally, there is an ongoing effort to review old specifications to search for areas that might benefit from taking privacy and data minimisation better into account. [Arkko1]
インターネットのセキュリティとプライバシーを強化することは引き続き多くの注目を集めました。 IETFの直前にIABとW3Cが主催したSTRINTワークショップには、100人の参加者と60を超える論文が集まりました。もっと多くの人が加わったでしょうが、スペースはありませんでした。 IETFミーティングの間、私たちはさまざまなワーキンググループでこのトピックについて議論を続けました。少し前に、広範囲にわたる監視を取り巻くいくつかの問題に対処することを特に目的とした最初のワーキンググループを作成しました。アプリケーションでのTLSの使用（UTA）ワーキンググループは、ロンドンで最初の会議を行いました。しかし、他の多くのワーキンググループも、自分たちの仕事でこれらの問題に取り組んでいます。 TCPMワーキンググループは、日和見キーイングメカニズムをTCPプロトコルに直接追加する提案について議論しました。 DNSE BOFは、DNSクエリに機密性サポートを追加する可能性を検討しました。最後に、古い仕様を確認して、プライバシーとデータの最小化をより適切に考慮することでメリットが得られる可能性のある領域を探すための継続的な取り組みがあります。 [Arkko1]
Two papers that were written for the workshop, but not finished in time, are worth mentioning, too: One by the same Jari Arkko, titled "Privacy and Networking Functions" [Arkko2]; and one by Johan Pouwelse, "The Shadow Internet: liberation from Surveillance, Censorship and Servers" [Pouwelse].
ワークショップ用に作成されたが、間に合わなかった2つの論文についても言及する価値があります。1つは同じJari Arkkoによる「プライバシーとネットワーク機能」[Arkko2]というタイトルの論文です。 1つはJohan Pouwelseによるもので、「The Shadow Internet：Surveillance、Censorship and Serversからの解放」[Pouwelse]。
This document is all about security and privacy.
このドキュメントは、セキュリティとプライバシーに関するものです。
[Arkko1] Arkko, J., "IETF-89 Summary", March 2014, <http://www.ietf.org/blog/2014/03/ietf-89-summary/>.
[Arkko1] Arkko、J。、「IETF-89 Summary」、2014年3月、<http://www.ietf.org/blog/2014/03/ietf-89-summary/>。
[Arkko2] Arkko, J., "Privacy and Networking Functions", March 2014, <http://www.arkko.com/ietf/strint/ draft-arkko-strint-networking-functions.txt>.
[Arkko2] Arkko、J.、「プライバシーとネットワーク機能」、2014年3月、<http://www.arkko.com/ietf/strint/draft-arkko-strint-networking-functions.txt>。
[Barnes] Barnes, R., Schneier, B., Jennings, C., and T. Hardie, "Pervasive Attack: A Threat Model and Problem Statement", Work in Progress, draft-barnes-pervasive-problem-00, January 2014.
[Barnes] Barnes、R.、Schneier、B.、Jennings、C。、およびT. Hardie、「Pervasive Attack：A Threat Model and Problem Statement」、Work in Progress、draft-barnes-pervasive-problem-00、1月2014。
[Captive] Wikipedia, "Captive portal", October 2015, <https://en.wikipedia.org/w/ index.php?title=Captive_portal&oldid=685621201>.
[キャプティブ] Wikipedia、「キャプティブポータル」、2015年10月、<https://en.wikipedia.org/w/ index.php？title = Captive_portal＆oldid = 685621201>。
[Kent] Kent, S., "Opportunistic Security as a Countermeasure to Pervasive Monitoring", Work in Progress, draft-kent-opportunistic-security-01, April 2014.
[ケント]ケントS.、「広範監視への対策としての日和見セキュリティ」、進行中の作業、draft-kent-opportunistic-security-01、2014年4月。
[Paper4] Hardie, T., "Flows and Pervasive Monitoring", STRINT Workshop, 2014, <https://www.w3.org/2014/strint/papers/4.pdf>.
[Paper4] Hardie、T。、「Flows and Pervasive Monitoring」、STRINT Workshop、2014、<https://www.w3.org/2014/strint/papers/4.pdf>。
[Pouwelse] Pouwelse, J., "The Shadow Internet: liberation from Surveillance, Censorship and Servers", Work in Progress, draft-pouwelse-perpass-shadow-internet-00, February 2014.
[Pouwelse] Pouwelse、J。、「シャドウインターネット：監視、検閲、サーバーからの解放」、作業中、draft-pouwelse-perpass-shadow-internet-00、2014年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365] Schiller、J。、「インターネット技術特別調査委員会標準プロトコルの強力なセキュリティ要件」、BCP 61、RFC 3365、DOI 10.17487 / RFC3365、2002年8月、<http://www.rfc-editor.org/info/ rfc3365>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの記述に関するガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<http://www.rfc-editor.org/ info / rfc3552>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704 >。
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <http://www.rfc-editor.org/info/rfc4252>.
[RFC4252] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Authentication Protocol」、RFC 4252、DOI 10.17487 / RFC4252、2006年1月、<http://www.rfc-editor.org/ info / rfc4252>。
[RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, DOI 10.17487/RFC4322, December 2005, <http://www.rfc-editor.org/info/rfc4322>.
[RFC4322] Richardson、M。およびD. Redelmeier、「インターネットキーエクスチェンジ（IKE）を使用した日和見暗号化」、RFC 4322、DOI 10.17487 / RFC4322、2005年12月、<http://www.rfc-editor.org/info / rfc4322>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120 >。
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC6585]ノッティンガム、M。およびR.フィールディング、「追加のHTTPステータスコード」、RFC 6585、DOI 10.17487 / RFC6585、2012年4月、<http://www.rfc-editor.org/info/rfc6585>。
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.
[RFC6817] Shalunov、S.、Hazel、G.、Iyengar、J。、およびM. Kuehlewind、「Low Extra Delay Background Transport（LEDBAT）」、RFC 6817、DOI 10.17487 / RFC6817、2012年12月、<http：// www.rfc-editor.org/info/rfc6817>。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <http://www.rfc-editor.org/info/rfc6962>.
[RFC6962]ローリーB.、ラングレーA.、およびE.キャスパー、「証明書の透明性」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<http://www.rfc-editor.org/info/rfc6962 >。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<http://www.rfc-editor.org / info / rfc7469>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、RFC 7624、DOI 10.17487 / RFC7624、2015年8月、<http://www.rfc-editor.org/info/rfc7624>。
[Ristic] Ristic, I., "CRIME: Information Leakage Attack against SSL/TLS", Qualys Blog, <https://community.qualys.com/blogs/securitylabs/2012/ 09/14/crime-information-leakage-attack-against-ssltls>.
[Ristic] Ristic、I。、「CRIME：SSL / TLSに対する情報漏洩攻撃」、Qualysブログ、<https://community.qualys.com/blogs/securitylabs/2012/ 09/14 / crime-information-leakage- attack-against-ssltls>。
[SAAG_list] IETF, "saag Discussion Archive", <https://www.ietf.org/ mail-archive/web/saag/current/maillist.html>.
[SAAG_list] IETF、「saagディスカッションアーカイブ」、<https://www.ietf.org/ mail-archive / web / saag / current / maillist.html>。
[STRINT] W3C/IAB, "STRINT Workshop", <https://www.w3.org/2014/strint/Overview.html>.
[STRINT] W3C / IAB、「STRINT Workshop」、<https://www.w3.org/2014/strint/Overview.html>。
[vancouverplenary] IETF, "IETF 88 Technical Plenary Minutes", <https://www.ietf.org/proceedings/88/minutes/ minutes-88-iab-techplenary>.
[vancouverplenary] IETF、「IETF 88 Technical Plenary Minutes」、<https://www.ietf.org/proceedings/88/minutes/ minutes-88-iab-techplenary>。
[w3c-geo-api] Popescu, A., "Geolocation API Specification", W3C Recommendation, October 2013, <http://www.w3.org/TR/geolocation-API/>.
[w3c-geo-api] Popescu、A。、「Geolocation API仕様」、W3C勧告、2013年10月、<http://www.w3.org/TR/geolocation-API/>。
The workshop was organised by the STREWS project (<https://www.strews.eu/>), which is a research project funded under the European Union's 7th Framework Programme (<http://cordis.europa.eu/fp7/ict/>). It was the first of two workshops in its work plan. The organisers were supported by the IAB and W3C, and, for the local organisation, by Telefonica Digital (<http://blog.digital.telefonica.com/>).
ワークショップは、EUの第7次フレームワークプログラム（<http://cordis.europa.eu/fp7/ ict />）。これは、作業計画における2つのワークショップの最初のものでした。主催者はIABとW3Cによってサポートされ、地域の組織ではTelefonica Digital（<http://blog.digital.telefonica.com/>）によってサポートされました。
One of the suggestions in the project description of the STREWS project was to attach the first workshop to an IETF meeting. The best opportunity was IETF 89 in London, which began on Sunday 2 March 2014; see <https://www.ietf.org/meeting/89/> for more information. Telefonica Digital offered meeting rooms at its offices in central London for the preceding Friday and Saturday, just minutes away from the IETF's location.
STREWSプロジェクトのプロジェクトの説明における提案の1つは、IETFミーティングに最初のワークショップを添付することでした。最高の機会は、2014年3月2日（日）にロンドンで開催されたIETF 89でした。詳細については、<https://www.ietf.org/meeting/89/>を参照してください。 Telefonica Digitalは、ロンドン中心部のオフィスに、前の金曜日と土曜日にIETFの場所からわずか数分の場所に会議室を提供しました。
The room held 100 people, which was thought to be sufficient. There turned out to be more interest than expected and we could have filled a larger room, but 100 people is probably an upper limit for good discussions anyway.
部屋は100人を収容し、それで十分だと思われた。予想以上に興味があり、より大きな部屋を埋めることができたかもしれませんが、とにかく良い議論の上限はおそらく100人です。
Apart from the usual equipment in the room (projector, white boards, microphones, coffee), we also set up some extra communication channels:
部屋の通常の設備（プロジェクター、ホワイトボード、マイク、コーヒー）の他に、追加の通信チャネルもいくつかセットアップします。
o A mailing list where participants could discuss the agenda and the published papers about three weeks in advance of the workshop itself.
o ワークショップ自体の約3週間前に、参加者が議題と公開された論文について話し合うことができるメーリングリスト。
o Publicly advertised streaming audio (one-way only). At some point, no less than 165 people were listening.
o 公に宣伝されたストリーミングオーディオ（一方向のみ）。ある時点で、少なくとも165人が聞いていました。
o An IRC channel for live minute-taking, passing links and other information, and helping remote participants to follow the proceedings.
o ライブの議事録、リンクやその他の情報を渡すためのIRCチャネル。リモートの参加者が議事録を追跡するのを支援します。
o An Etherpad, where the authors of papers could provide an abstract of their submissions, to help participants who could not read all 66 papers in full in advance of the workshop. The abstracts were also used on the workshop's web site: <https://www.w3.org/2014/strint/>.
o ワークショップの前に66の論文すべてを完全に読むことができなかった参加者を支援するために、論文の著者が提出物の要約を提供できるEtherpad。アブストラクトはワークショップのWebサイト<https://www.w3.org/2014/strint/>でも使用されました。
o A Twitter hashtag (#strint). Four weeks after the workshop, there were still a few new messages about events related to workshop topics; see <https://twitter.com/search?q=%23strint>.
o Twitterハッシュタグ（#strint）。ワークショップの4週間後、ワークショップのトピックに関連するイベントに関する新しいメッセージがまだいくつかありました。 <https://twitter.com/search?q=%23strint>を参照してください。
This was the final agenda of the workshop, as determined by the TPC and participants on the mailing list prior to the workshop. The included links are to the slides that the moderators used to introduce each discussion topic and to the minutes.
これはワークショップの最終議題であり、ワークショップの前にTPCとメーリングリストの参加者によって決定されました。含まれているリンクは、モデレーターが各ディスカッショントピックを紹介するために使用したスライドと議事録です。
Minutes: <http://www.w3.org/2014/02/28-strint-minutes.html>
Workshop starts, welcome, logistics, opening/overview
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf>
o Goal is to plan how we respond to PM threats
o 目標は、PMの脅威への対応方法を計画することです
o Specific questions to be discussed in sessions
o セッションで議論される特定の質問
o Outcomes are actions for IETF, W3C, IRTF, etc.
o 結果は、IETF、W3C、IRTFなどのアクションです。
I. Threats - What problem are we trying to solve?
(Presenter: Richard Barnes; Moderator: Cullen Jennings)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf>
* What attacks have been described? (Attack taxonomy)
* どのような攻撃が説明されていますか？ （攻撃分類）
* What should we assume the attackers' capabilities are?
* 攻撃者の能力は何だと思いますか？
* When is it really "pervasive monitoring" and when is it not?
* それは本当に「広範囲の監視」であり、いつそうではないのですか？
* Scoping - what's in and what's out? (for IETF/W3C)
* スコーピング-何が入って何が出ますか？ （IETF / W3Cの場合）
II. COMSEC 1 - How can we increase usage of current COMSEC tools?
(Presenter: Hannes Tschofenig; Moderator: Leif Johansson)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf>
* Whirlwind catalog of current tools
* 現在のツールの旋風カタログ
* Why aren't people using them? In what situations are / aren't they used?
* なぜ人々はそれらを使わないのですか？彼らはどのような状況で/使用されていませんか？
* Securing AAA and management protocols - why not?
* AAAおよび管理プロトコルの保護-なぜそうしないのですか？
* How can we (IETF/W3C/community) encourage more/better use?
* どのようにして（IETF / W3C /コミュニティ）より多くの/より良い使用を奨励できますか？
III. Policy - What policy/legal/other issues need to be taken into
account? (Presenter: Christine Runnegar; Moderator: Rigo
Wenning)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf>
* What non-technical activities do we need to be aware of?
* 知っておく必要のある非技術的な活動は何ですか？
* How might such non-technical activities impact on IETF/W3C?
* そのような非技術的な活動はIETF / W3Cにどのような影響を与える可能性がありますか？
* How might IETF/W3C activities impact those non-technical activities?
* IETF / W3Cアクティビティは、これらの非技術的なアクティビティにどのように影響しますか？
Saturday plan, open mic, wrap-up of the day
サタデープラン、オープンマイク、当日のまとめ
Minutes: <http://www.w3.org/2014/03/01-strint-minutes.html>
IV. COMSEC 2 - What improvements to COMSEC tools are needed?
(Presenter: Mark Nottingham; Moderator: Steve Bellovin)
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf>
* Opportunistic encryption - what is it and where it might apply
* 日和見暗号化-それは何であり、どこに適用されるか
* Mitigations aiming to block PM vs. detect PM - when to try which?
* PMをブロックすることとPMを検出することを目的とする緩和策-いつどちらを試すか？
V. Metadata - How can we reduce the metadata that protocols expose? (Presenters: Alfredo Pironti, Ted Hardie; Moderator: Alissa Cooper)
V.メタデータ-プロトコルが公開するメタデータをどのように削減できますか？ （プレゼンター：Alfredo Pironti、Ted Hardie、モデレーター：Alissa Cooper）
Slides:
<https://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf>
<https://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf>
* Metadata, fingerprinting, minimisation
* メタデータ、フィンガープリント、最小化
* What's out there?
* 何があるの？
* How can we do better?
* どうすればもっとうまくできるでしょうか？
VI. Deployment - How can we address PM in deployment / operations?
(Presenter: Eliot Lear; Moderator: Barry Leiba)
Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf>
* "Mega"-commercial services (clouds, large-scale email and Online Social Networks, SIP, WebRTC)
* 「メガ」商用サービス（クラウド、大規模メール、オンラインソーシャルネットワーク、SIP、WebRTC）
* Target dispersal - good goal or wishful thinking?
* ターゲットの分散-良い目標または希望的な考え？
* Middleboxes: when a help and when a hindrance?
* ミドルボックス：いつ助け、いつ妨げ？
VII. Break-out Sessions (x 3) / Bar-Camp style (Hannes Tschofenig)
VII。ブレークアウトセッション（x 3）/バーキャンプスタイル（Hannes Tschofenig）
* Content to be defined during meeting, as topics come up
* トピックが出てきたときに会議中に定義されるコンテンツ
* Sum up at the end to gather conclusions for report
* レポートの結論を収集するために最後に要約します
Break-outs:
ブレークアウト：
1. Research Questions (Moderator: Kenny Paterson)
1. 調査の質問（モデレーター：ケニーパターソン）
+ Do we need more/different crypto tools?
+ より多くの/異なる暗号化ツールが必要ですか？
+ How can applications make better use of COMSEC tools?
+ アプリケーションはどのようにしてCOMSECツールをより有効に活用できますか？
+ What research topics could be handled in IRTF?
+ IRTFで処理できる研究トピックは何ですか？
+ What other research would help?
+ 他にどんな研究が役立つでしょうか？
2. Clients
2. クライアント
3. On by default
3. デフォルトでオン
4. Measurement
4. 測定
5. Opportunistic
5. 日和見
VIII. Break-out Reports, Open Mic & Conclusions - What are we going
to do to address PM?
Slides: <https://www.w3.org/2014/strint/slides/summary.pdf>
* Gather conclusions / recommendations / goals from earlier sessions
* 以前のセッションからの結論/推奨事項/目標を収集する
The workshop chairs were three: Stephen Farrell (TCD) and Rigo Wenning (W3C) from the STREWS project, and Hannes Tschofenig (ARM) from the STREWS Interest Group.
ワークショップの議長は3名でした：STREWSプロジェクトのスティーブンファレル（TCD）とリゴウェニング（W3C）、およびSTREWSインタレストグループのハネスツコフェニグ（ARM）。
The Technical Programme Committee (TPC) was charged with evaluating the submitted papers. It was made up of the members of the STREWS project, the members of the STREWS Interest Group, plus invited experts: Bernard Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP), Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler (Microsoft), and Sean Turner (IECA).
テクニカルプログラム委員会（TPC）は、提出された論文の評価を担当しました。これは、STREWSプロジェクトのメンバー、STREWS Interest Groupのメンバー、および招待されたエキスパートであるBernard Aboba（Microsoft）、Dan Appelquist（Telefonica＆W3C TAG）、Richard Barnes（Mozilla）、Bert Bos（W3C）で構成されました。 、Lieven Desmet（KUルーベン）、Karen O'Donoghue（ISOC）、Russ Housley（Vigil Security）、Martin Johns（SAP）、Ben Laurie（Google）、Eliot Lear（Cisco）、Kenny Paterson（Royal Holloway）、Eric Rescorla （RTFM）、Wendy Seltzer（W3C）、Dave Thaler（Microsoft）、およびSean Turner（IECA）。
The participants to the workshop were:
ワークショップの参加者は次のとおりです。
o Bernard Aboba (Microsoft Corporation)
o Thijs Alkemade (Adium)
o Daniel Appelquist (Telefonica Digital)
o Jari Arkko (Ericsson)
o Alia Atlas (Juniper Networks)
o Emmanuel Baccelli (INRIA)
o Mary Barnes
o Richard Barnes (Mozilla)
o Steve Bellovin (Columbia University)
o Andrea Bittau (Stanford University)
o Marc Blanchet (Viagenie)
o Carsten Bormann (Uni Bremen TZI)
o Bert Bos (W3C)
o Ian Brown (Oxford University)
o Stewart Bryant (Cisco Systems)
o Randy Bush (IIJ / Dragon Research Labs)
o Kelsey Cairns (Washington State University)
o Stuart Cheshire (Apple)
o Vincent Cheval (University of Birmingham)
o Benoit Claise (Cisco)
o Alissa Cooper (Cisco)
o Dave Crocker (Brandenburg InternetWorking)
o Leslie Daigle (Internet Society)
o George Danezis (University College London)
o Spencer Dawkins (Huawei)
o Mark Donnelly (Painless Security)
o Nick Doty (W3C)
o Dan Druta (AT&T)
o Peter Eckersley (Electronic Frontier Foundation)
o Lars Eggert (NetApp)
o Kai Engert (Red Hat)
o Monika Ermert
o Stephen Farrell (Trinity College Dublin)
o Barbara Fraser (Cisco)
o Virginie Galindo (gemalto)
o Stefanie Gerdes (Uni Bremen TZI)
o Daniel Kahn Gillmor (ACLU)
o Wendy M. Grossman
o Christian Grothoff (The GNUnet Project)
o Oliver Hahm (INRIA)
o Joseph Lorenzo Hall (Center for Democracy & Technology)
o Phillip Hallam-Baker
o Harry Halpin (W3C/MIT and IRI)
o Ted Hardie (Google)
o Joe Hildebrand (Cisco Systems)
o Russ Housley (Vigil Security, LLC)
o Cullen Jennings (CISCO)
o Leif Johansson (SUNET)
o Harold Johnson (Irdeto)
o Alan Johnston (Avaya)
o L. Aaron Kaplan (CERT.at)
o Steve Kent (BBN Technologies)
o Achim Klabunde (European Data Protection Supervisor)
o Hans Kuhn (NOC)
o Christian de Larrinaga
o Ben Laurie (Google)
o Eliot Lear (Cisco Ssytems)
o Barry Leiba (Huawei Technologies)
o Sebastian Lekies (SAP AG)
o Orit Levin (Microsoft Corporation)
o Carlo Von LynX (#youbroketheinternet)
o Xavier Marjou (Orange)
o Larry Masinter (Adobe)
o John Mattsson (Ericsson)
o Patrick McManus (Mozilla)
o Doug Montgomery (NIST)
o Kathleen Moriarty (EMC)
o Alec Muffett (Facebook)
o Suhas Nandakumar (Cisco Systems)
o Linh Nguyen (ERCIM/W3C)
o Linus Nordberg (NORDUnet)
o Mark Nottingham
o Karen O'Donoghue (Internet Society)
o Piers O'Hanlon (Oxford Internet Institute)
o Kenny Paterson (Royal Holloway, University of London)
o Jon Peterson (Neustar)
o Joshua Phillips (University of Birmingham)
o Alfredo Pironti (INRIA)
o Dana Polatin-Reuben (University of Oxford)
o Prof. Johan Pouwelse (Delft University of Technology)
o Max Pritikin (Cisco)
o Eric Rescorla (Mozilla)
o Pete Resnick (Qualcomm Technologies, Inc.)
o Tom Ristenpart (University of Wisconsin)
o Andrei Robachevsky (Internet Society)
o David Rogers (Copper Horse)
o Scott Rose (NIST)
o Christine Runnegar (Internet Society)
o Philippe De Ryck (DistriNet - KU Leuven)
o Peter Saint-Andre (&yet)
o Runa A. Sandvik (Center for Democracy and Technology)
o Jakob Schlyter
o Dr. Jan Seedorf (NEC Laboratories Europe)
o Wendy Seltzer (W3C)
o Melinda Shore (No Mountain Software)
o Dave Thaler (Microsoft)
o Brian Trammell (ETH Zurich)
o Hannes Tschofenig (ARM Limited)
o Sean Turner (IECA, Inc.)
o Matthias Waehlisch (Freie Universitaet Berlin)
o Greg Walton (Oxford University)
o Rigo Wenning (W3C)
o Tara Whalen (Apple Inc.)
o Greg Wood (Internet Society)
o Jiangshan Yu (University of Birmingham)
o Aaron Zauner
o Dacheng Zhang (Huawei)
o Phil Zimmermann (Silent Circle LLC)
o Juan-Carlos Zuniga (InterDigital)
Authors' Addresses
著者のアドレス
Stephen Farrell
Trinity College, Dublin
Email: stephen.farrell@cs.tcd.ie
URI: https://www.cs.tcd.ie/Stephen.Farrell/
Rigo Wenning World Wide Web Consortium 2004, route des Lucioles B.P. 93 Sophia-Antipolis 06902 France Email: rigo@w3.org URI: http://www.w3.org/People/Rigo/
Rigo Wenning World Wide Web Consortium 2004、route des Lucioles B.P. 93 Sophia-Antipolis 06902 Franceメール：rigo@w3.org URI：http://www.w3.org/People/Rigo/
Bert Bos World Wide Web Consortium 2004, route des Lucioles B.P. 93 Sophia-Antipolis 06902 France Email: bert@w3.org
Bert Bos World Wide Web Consortium 2004、route des Lucioles B.P. 93 Sophia-Antipolis 06902 Franceメール：bert@w3.org
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Email: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca
Marc Blanchet Viagenie 246 Aberdeen Quebec、QC G1R 2E1 Canadaメール：Marc.Blanchet@viagenie.ca URI：http://viagenie.ca
Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at
Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ Great Britain Email：Hannes.tschofenig@gmx.net URI：http://www.tschofenig.priv.at