From nobody Mon Jun 1 09:18:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7151B2C9C for ; Mon, 1 Jun 2015 09:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB6JidH6bJqf for ; Mon, 1 Jun 2015 09:18:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977D61B2C68 for ; Mon, 1 Jun 2015 09:15:33 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so34516970wib.1 for ; Mon, 01 Jun 2015 09:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KS3bg8qHkQzTKHrar94+cHk5KX7g2u0LLbxgYiY/PNg=; b=WNtQkJliq8aQpSo0qxVeK2U/ot/JmHuOTEPsUSmZzdpIMMesXeEJSXCBu0kbjaSB0N 80vd9bPADhzNj3EAwtY7JlKei9gBE7qcE1sFI3Oli5uaXD50AtVlOsK8gxLLbrOgkbV7 zgNRkKf0zcIDHaUO2vzgGGPV/ke7YbVMsv9lMYjddVcYYYBUtDbszHayBpXFMhxoWJd/ OFvq7DjuOsGehYE9bbMS1uBEBXp+99x0/fK5+q3PI8ddNKuKr7odmwAR0XyCWpx6eFt7 Jzj5fWHWOTD26OCZ1s8hU5vQwuhvHwfQGE3seZmeo+c+jZ/Uj5LLKaqKq2RJ21fBJEl0 k++w== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr21832504wiz.78.1433175332360; Mon, 01 Jun 2015 09:15:32 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Mon, 1 Jun 2015 09:15:32 -0700 (PDT) In-Reply-To: <20150601155050.18659.68131.idtracker@ietfa.amsl.com> References: <20150601155050.18659.68131.idtracker@ietfa.amsl.com> Date: Mon, 1 Jun 2015 12:15:32 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=f46d0442806e96183705177722bd Archived-At: Cc: Jeff Hodges , Leif Johansson , Matt Baratta Subject: [saag] Fwd: New Non-WG Mailing List: GHOST -- GatHering and reOrganizing STandards information X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:18:29 -0000 --f46d0442806e96183705177722bd Content-Type: text/plain; charset=UTF-8 Hello, If you are interested to help structure how standards information is accessed by others (product team developers, those new to standards, security researchers, students, etc.), please join the GHOST list. We will be starting with a generic structure and determine the best starting points on the web (that are high in search results) for categories of interest, starting with authentication. The structure needs to be generic enough to cover any area of standards work and allow users to find the relevant set of standards for their use cases and device types. This will feed back out to WG wikis and other existing sources, but is aimed at providing better linkage between efforts. This problem became very apparent to me when seeing how product team find appropriate security solutions. Much of it relied upon their knowledge of standards. Essentially, tons of time is wasted and product teams are not aware of all of the existing options, what is on an uptrend (or down), and how to get the most reliable information to see if a solution suits their needs. Improved organization of standards information will hopefully prevent duplication of efforts in creating standards since they will be more accessible. I worked on a Google doc about a year ago with Jeff Hodges, Lief Johansson, and Wendy Seltzer. The link is included below, which provides more information on the project, including initial suggestions for the structure. I'd like to open this up as a team effort and take on authentication as a starting point. This may also require some efforts from WG participants to improve information available on their standards. Matt Baratta will be working with me for the summer to help make this happen. As such, I'd like input on the structure document and then to have the list work on a prototype for authentication. Matt will be able to pull materials together and edit the prototype content, but we will need experts to provide (may be on WG wikis or other pointers) and validate information. https://docs.google.com/document/d/1VR4eR0mZohJ1vWy3dpyHg-w56qm4KjQG06V9TyNqP70/edit#heading=h.83yegm6dqtsh We will give folks a little time to join the list. Thank you, Kathleen & Matt ---------- Forwarded message ---------- From: IETF Secretariat Date: Mon, Jun 1, 2015 at 11:50 AM Subject: New Non-WG Mailing List: GHOST -- GatHering and reOrganizing STandards information To: IETF Announcement List Cc: ghost@ietf.org, kathleen.moriarty.ietf@gmail.com, matt_baratta@comcast.net A new IETF non-working group email list has been created. List address: ghost at ietf.org Archive: http://www.ietf.org/mail-archive/web/ghost/ To subscribe: https://www.ietf.org/mailman/listinfo/ghost Purpose: Organizing information and security standards to better assist researchers in their efforts to obtain data. The primary goal is to bring information on standards to a central starting point, and thus reduce the amount of research that is needed when investigation solution options. This would allow individuals or groups to find the information needed to assist in the completion of their projects with information such as use case and device applicability. For additional information, please contact the list administrators. -- Best regards, Kathleen --f46d0442806e96183705177722bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

If you are interested to help st= ructure how standards information is accessed by others (product team devel= opers, those new to standards, security researchers, students, etc.), pleas= e join the GHOST list.

We will be starting with a = generic structure and determine the best starting points on the web (that a= re high in search results) for categories of interest, starting with authen= tication.=C2=A0 The structure needs to be generic enough to cover any area = of standards work and allow users to find the relevant set of standards for= their use cases and device types.=C2=A0 This will feed back out to WG wiki= s and other existing sources, but is aimed at providing better linkage betw= een efforts.=C2=A0 This problem became very apparent to me when seeing how = product team find appropriate security solutions.=C2=A0 Much of it relied u= pon their knowledge of standards.=C2=A0 Essentially, tons of time is wasted= and product teams are not aware of all of the existing options, what is on= an uptrend (or down), and how to get the most reliable information to see = if a solution suits their needs.

Improved organiza= tion of standards information will hopefully prevent duplication of efforts= in creating standards since they will be more accessible.

I worked on a Google doc about a year ago with Jeff Hodges, Lief J= ohansson, and Wendy Seltzer.=C2=A0 The link is included below, which provid= es more information on the project, including initial suggestions for the s= tructure.=C2=A0 I'd like to open this up as a team effort and take on a= uthentication as a starting point.=C2=A0 This may also require some efforts= from WG participants to improve information available on their standards.<= /div>

Matt Baratta will be working with me for the summe= r to help make this happen.=C2=A0 As such, I'd like input on the struct= ure document and then to have the list work on a prototype for authenticati= on.=C2=A0 Matt will be able to pull materials together and edit the prototy= pe content, but we will need experts to provide (may be on WG wikis or othe= r pointers) and validate information.


We will give folks a little time to join the li= st.

Thank you,
Kathleen & Matt
=

=C2=A0
---------- Forward= ed message ----------
From: IETF Secretari= at <i= etf-secretariat@ietf.org>
Date: Mon, Jun 1, 2015 at 11:50 = AM
Subject: New Non-WG Mailing List: GHOST -- GatHering and reOrganizing= STandards information
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ghost@ietf.org, kathleen.moriarty.ietf@gmail.com, matt_baratta@comcast.net


A new IETF= non-working group email list has been created.

List address: ghost at ietf.o= rg
Archive: http://www.ietf.org/mail-archive/web/ghost/
To subscribe: https://www.ietf.org/mailman/listinfo/ghost

Purpose: Organizing information and security standards to better assist res= earchers in their efforts to obtain data. The primary goal is to bring info= rmation on standards to a central starting point, and thus reduce the amoun= t of research that is needed when investigation solution options. This woul= d allow individuals or groups to find the information needed to assist in t= he completion of their projects with information such as use case and devic= e applicability.


For additional information, please contact the list administrators.



--

Best regards,
Kathleen
--f46d0442806e96183705177722bd-- From nobody Mon Jun 1 11:21:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DE1B2FE5 for ; Mon, 1 Jun 2015 11:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqNnEeWHPoJi for ; Mon, 1 Jun 2015 11:21:06 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EB7E91B30AB for ; Mon, 1 Jun 2015 11:20:40 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 43B619A403B; Mon, 1 Jun 2015 14:20:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id xxkidBuHBwNR; Mon, 1 Jun 2015 14:19:09 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 6258E9A4029; Mon, 1 Jun 2015 14:20:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5564D265.4030504@iang.org> Date: Mon, 1 Jun 2015 14:19:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie>, <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> To: ianG , Christian Huitema X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:21:08 -0000 Christian and Ian: > On 26/05/2015 19:15 pm, Christian Huitema wrote: >>>> Apart from an initial comment on the draft I've tried to avoid = getting >>>> involved in a debate over this since I think the issue is at least = as >>>> much (if not more) religious than technical. For example I can use >>>> Russ' WEP example to argue exactly the opposite of the point he's >>>> trying to make: The problem with WEP wasn't a 1TCS one, it was that = it >>>> was designed by non-cryptographers, and was badly broken. If they'd >>>> gone with four cipher suites instead of one, we'd just have four = badly >>>> broken ones instead of one, or, worse, three badly broken ones and = one >>>> not-quite-as-broken one so they could tell everyone to use the = not-quite-as- >>> bad one. >>>=20 >>> I see the history a bit differently. The original WEP had a 40-bit = key, and no one >>> looked at the protocol because the security was obviously weak. = When the key >>> size was increased to 128-bits, then people looked at the protocol = and saw all of >>> the major mistakes. It is hard to believe that so many mistakes can = be made in >>> one protocol. >>=20 >> WEP is certainly one of the worse examples out there. The initial key = length was ridiculous, the initialization vector was used incorrectly, = the linear CRC did not protect the data integrity, etc. It seems like a = textbook example against having just one cipher. But at the same time, = WEP issues could not be fixed by just changing the underlying encryption = algorithm. The fixes required changing the whole protocol, which is = actually an example of versioning. >=20 > "But at the same time..." :) >=20 >> The other "bad example" of security design is of course the use of A5 = in GSM. This one provides an interesting view on key and algorithm = negotiation. The standard was deliberately compromised to enable mass = surveillance. >=20 > It was deliberately compromised, yes. The MiB were in the design = room. >=20 > However, it is important to remember our security modelling. GSM = crypto was designed to protect against two things: paparazzi and = billing fraud. It did those very well. It was never designed to = protect against national security agencies, and didn't need to, given = that the GSM protocol was only secure on air. Both the European = agencies and every other agency could easily hack in and listen in the = clear. Both WEP and GSM A5 were only intended to protect one radio hop. The capabilities available to the non-nation-state attacker grew = considerably from the time of the design to the end-of-life for that = design. And, that is the thing that we need to consider for this = document. What guidance would allow a solid protocol design an the = transition to a stronger algorithm? Russ From nobody Mon Jun 1 11:28:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A501B30AB for ; Mon, 1 Jun 2015 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRsmLTBT_-Jz for ; Mon, 1 Jun 2015 11:28:42 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16C71B308B for ; Mon, 1 Jun 2015 11:28:41 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so121729695wgb.3 for ; Mon, 01 Jun 2015 11:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FHbdqWHMHqxgCvWAbaZVNSHVXAKQweDiGzT2ycUt7R4=; b=lGsNvEIuROhVNBfjbpXFBwCgMMbFaPEYuMHW5efC3SUJK36NjNCPkPCx2SO4Q83jv6 3BHY6izc5H8M+PNnuO+bCaqIEILY4avjXWf72rA78uJ6o4WMQspLbA9DxOvNVh90vPK7 Dw/hbovkETDIv+U+Z8AAdslHoQPdtXGUNfmViJFFfSBrJNwEiQjifuO2ee2UVu52Hbji 2lsWk03X2RU2Kgpdx8nkNndLsqXad50TA2/cxpc72+OIpxDcjLCp4CLuBmzZAaCYPirR FzyT5Jo3aq/A9lv9pjEa5AL88462YbLzMHt6mAdes/z8Lh+t2yF69cagQbekY/gcacmn EXuw== MIME-Version: 1.0 X-Received: by 10.180.187.203 with SMTP id fu11mr23535499wic.26.1433183320591; Mon, 01 Jun 2015 11:28:40 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 1 Jun 2015 11:28:40 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 1 Jun 2015 11:28:40 -0700 (PDT) In-Reply-To: <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> Date: Mon, 1 Jun 2015 11:28:40 -0700 Message-ID: From: Watson Ladd To: Russ Housley Content-Type: multipart/alternative; boundary=001a11c267d8b8d431051778fedb Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:28:45 -0000 --001a11c267d8b8d431051778fedb Content-Type: text/plain; charset=UTF-8 On Jun 1, 2015 11:21 AM, "Russ Housley" wrote: > > Christian and Ian: > > > On 26/05/2015 19:15 pm, Christian Huitema wrote: > >>>> Apart from an initial comment on the draft I've tried to avoid getting > >>>> involved in a debate over this since I think the issue is at least as > >>>> much (if not more) religious than technical. For example I can use > >>>> Russ' WEP example to argue exactly the opposite of the point he's > >>>> trying to make: The problem with WEP wasn't a 1TCS one, it was that it > >>>> was designed by non-cryptographers, and was badly broken. If they'd > >>>> gone with four cipher suites instead of one, we'd just have four badly > >>>> broken ones instead of one, or, worse, three badly broken ones and one > >>>> not-quite-as-broken one so they could tell everyone to use the not-quite-as- > >>> bad one. > >>> > >>> I see the history a bit differently. The original WEP had a 40-bit key, and no one > >>> looked at the protocol because the security was obviously weak. When the key > >>> size was increased to 128-bits, then people looked at the protocol and saw all of > >>> the major mistakes. It is hard to believe that so many mistakes can be made in > >>> one protocol. > >> > >> WEP is certainly one of the worse examples out there. The initial key length was ridiculous, the initialization vector was used incorrectly, the linear CRC did not protect the data integrity, etc. It seems like a textbook example against having just one cipher. But at the same time, WEP issues could not be fixed by just changing the underlying encryption algorithm. The fixes required changing the whole protocol, which is actually an example of versioning. > > > > "But at the same time..." :) > > > >> The other "bad example" of security design is of course the use of A5 in GSM. This one provides an interesting view on key and algorithm negotiation. The standard was deliberately compromised to enable mass surveillance. > > > > It was deliberately compromised, yes. The MiB were in the design room. > > > > However, it is important to remember our security modelling. GSM crypto was designed to protect against two things: paparazzi and billing fraud. It did those very well. It was never designed to protect against national security agencies, and didn't need to, given that the GSM protocol was only secure on air. Both the European agencies and every other agency could easily hack in and listen in the clear. > > Both WEP and GSM A5 were only intended to protect one radio hop. > > The capabilities available to the non-nation-state attacker grew considerably from the time of the design to the end-of-life for that design. And, that is the thing that we need to consider for this document. What guidance would allow a solid protocol design an the transition to a stronger algorithm? TLS has algorithm agility. Has TLS successfully transitioned algorithms in response to weaknesses? The data indicates not, and in fact algorithm agility has weakened TLS as shown by logjam. Version changes are a much easier mechanism to implement securely. Removing options from user control makes upgrades easier. We need to really think through how depreciation will work, before we know what is the solution and what is the problem. > > Russ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --001a11c267d8b8d431051778fedb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 1, 2015 11:21 AM, "Russ Housley" <housley@vigilsec.com> wrote:
>
> Christian and Ian:
>
> > On 26/05/2015 19:15 pm, Christian Huitema wrote:
> >>>> Apart from an initial comment on the draft I've t= ried to avoid getting
> >>>> involved in a debate over this since I think the issu= e is at least as
> >>>> much (if not more) religious than technical.=C2=A0 Fo= r example I can use
> >>>> Russ' WEP example to argue exactly the opposite o= f the point he's
> >>>> trying to make: The problem with WEP wasn't a 1TC= S one, it was that it
> >>>> was designed by non-cryptographers, and was badly bro= ken. If they'd
> >>>> gone with four cipher suites instead of one, we'd= just have four badly
> >>>> broken ones instead of one, or, worse, three badly br= oken ones and one
> >>>> not-quite-as-broken one so they could tell everyone t= o use the not-quite-as-
> >>> bad one.
> >>>
> >>> I see the history a bit differently.=C2=A0 The original W= EP had a 40-bit key, and no one
> >>> looked at the protocol because the security was obviously= weak.=C2=A0 When the key
> >>> size was increased to 128-bits, then people looked at the= protocol and saw all of
> >>> the major mistakes.=C2=A0 It is hard to believe that so m= any mistakes can be made in
> >>> one protocol.
> >>
> >> WEP is certainly one of the worse examples out there. The ini= tial key length was ridiculous, the initialization vector was used incorrec= tly, the linear CRC did not protect the data integrity, etc. It seems like = a textbook example against having just one cipher. But at the same time, WE= P issues could not be fixed by just changing the underlying encryption algo= rithm. The fixes required changing the whole protocol, which is actually an= example of versioning.
> >
> > "But at the same time..." :)
> >
> >> The other "bad example" of security design is of co= urse the use of A5 in GSM. This one provides an interesting view on key and= algorithm negotiation. The standard was deliberately compromised to enable= mass surveillance.
> >
> > It was deliberately compromised, yes.=C2=A0 The MiB were in the d= esign room.
> >
> > However, it is important to remember our security modelling.=C2= =A0 GSM crypto was designed to protect against two things:=C2=A0 paparazzi = and billing fraud.=C2=A0 It did those very well.=C2=A0 It was never designe= d to protect against national security agencies, and didn't need to, gi= ven that the GSM protocol was only secure on air.=C2=A0 Both the European a= gencies and every other agency could easily hack in and listen in the clear= .
>
> Both WEP and GSM A5 were only intended to protect one radio hop.
>
> The capabilities available to the non-nation-state attacker grew consi= derably from the time of the design to the end-of-life for that design.=C2= =A0 And, that is the thing that we need to consider for this document.=C2= =A0 What guidance would allow a solid protocol design an the transition to = a stronger algorithm?

TLS has algorithm agility. Has TLS successfully transitioned= algorithms in response to weaknesses? The data indicates not, and in fact = algorithm agility has weakened TLS as shown by logjam.

Version changes are a much easier mechanism to implement sec= urely. Removing options from user control makes upgrades easier. We need to= really think through how depreciation will work, before we know what is th= e solution and what is the problem.
>
> Russ
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag

--001a11c267d8b8d431051778fedb-- From nobody Mon Jun 1 11:52:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A21B3136 for ; Mon, 1 Jun 2015 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H10mxVpSVdMp for ; Mon, 1 Jun 2015 11:52:22 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 373671B3135 for ; Mon, 1 Jun 2015 11:52:07 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id C92399A403B; Mon, 1 Jun 2015 14:51:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id WiPaZ-aub5Zm; Mon, 1 Jun 2015 14:50:36 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A2BF09A4029; Mon, 1 Jun 2015 14:51:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <5568A9A6.6060407@iang.org> Date: Mon, 1 Jun 2015 14:51:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5AC8BBE5-09FD-45B5-B0F2-D9A5066EB9BC@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5568A9A6.6060407@iang.org> To: ianG X-Mailer: Apple Mail (2.1085) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility - 3.3, 4.1, 4.6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:52:24 -0000 Ian: > Section 3.3 said this: >=20 > 3.3. Preserving Interoperability >=20 > Cryptographic algorithm deprecation is very hard. People do not = like > to introduce interoperability problems, even to preserve security. > As a result, flawed algorithms are supported for far too long. The > impacts of legacy software an long support tails on security can be > reduced by making it easy to develop, deploy, and configure new > algorithms. >=20 > Suggest changing last two lines to this: >=20 > ... > reduced by making it easy to rollover old suites to new suites. >=20 >=20 > Elsewise, the text would be to suggest that "adding new algorithms" is = the solution when actually it's part of the problem. I suggest this minor rewording: Cryptographic algorithm deprecation is very hard. People do not like to = introduce interoperability problems, even to preserve security. As a = result, flawed algorithms are supported for far too long. The impacts = of legacy software an long support tails on security can be reduced by = making it easy to rollover from old algorithms and suites to new ones. [snip. removing part where there is agreement.] >> I suggest adding another paragraph: >>=20 >> In many ways preserving interoperability is a difficult social = problem. For example, consider web browsers. Dropping support for an = algorithm suite can break connectivity to some web sites because, and = the browser will lose users by doing so. This situation creates = incentives to support algorithm suites that would otherwise be = deprecated, but preserving interoperability. Coordinating the demise of = an algorithm suite is an important aspect of the answer to this social = problem. >=20 >=20 > Yep, that's good. >=20 > I don't like the "social problem" part. While this may sound good to = our ears, it gives the impression that the users are the problem, when = in fact they are simply responding to the hand we dealt them. I.e., we = created the protocol, and we created it in a way that it isn't easy to = deprecate old stuff. Now we're blaming them for acting precisely how = the protocol channels them. >=20 > How about this: >=20 > Without clear mechanisms for rollover, preserving > interoperability becomes a difficult social problem. > For example, consider web browsers....but preserving > interoperability. >=20 > Institutions, being large or dominating users within > a large user base, may find that coordinating the demise > of an algorithm suite is an important method to minimise > the trauma of rollover to the users. >=20 >=20 >=20 > Notes. 1. I'm using the term "institution" in its economic sense, = which is natural for me, but may be weird to others. I'm not sure what = term would be comfortable here, but recall NIST is another institution = (other than the browsers) that has coordinated demise in this fashion. >=20 > 2. Then, it would be grand if we could also expand on ways in which = the designer / WG / IANA / IETF could help by coordinating. But that's = beyond my ken to write. I have not seen anyone comment on your use of "institution" or offer any = suggestions on ways that the IETF can help with the coordination. So I suggest a minor editorial change that is intended to point out that = the coordination will help used in the institution and others too: Without clear mechanisms for algorithm and suite rollover, preserving = interoperability becomes a difficult social problem. For example, = consider web browsers. Dropping support for an algorithm suite can = break connectivity to some web sites because, and the browser will lose = users by doing so. This situation creates incentives to support = algorithm suites that would otherwise be deprecated, but preserving = interoperability. Institutions, being large or dominate users within a large user base, = can assist by coordinating the demise of an algorithm suite, making the = rollover easier for their own users as well as others. [snip. removing part where there is agreement.] >>> I find Section 4.6 baffling. >=20 > The para is disjoint. It starts out with a discussion of what might = happen, without clear point (to me). >=20 > Then switches dramatically to how to transition. I suspect the 'bits' = discussion belongs elsewhere. >=20 > Then, the meat: >=20 > Where possible, authors SHOULD provide > notice to implementers about expected algorithm transitions. One > approach is to use SHOULD+, SHOULD-, and MUST- in the specification > of algorithms. >=20 > ... >=20 > seems happy stand-alone, following on from the title. We often get a lot of notice for transitions like DES --> Triple-DES --> = AES. We should not surprise product planners. >>> We have words that we can use for these >>> things. They are MUST NOT, MUST and SHOULD. None of these attempt = to >>> presage the future. But generating new conventions for what might = or >>> might not happen in the future is much harder than waiting and just >>> making the change when the time comes. >>=20 >> This idea is not new. It was first used with IKEv1 when Jeff = Schiller was SEC AD. The idea is to give product planners a heads up. >=20 >=20 > So, could this be introduced with that explanation? Something like: >=20 > Where possible, authors SHOULD provide > notice to implementers about expected algorithm transitions. >=20 > IKEv1 introduced a mechanism to provide notice which this ID adopts > [REF]. This approach uses additional hints SHOULD+, SHOULD-, > and MUST- in the specification of algorithms. >=20 > SHOULD+... > SHOULD-... > MUST-... Does this work for the reference? Where possible, authors SHOULD provide notice to implementers about = expected algorithm transitions. One approach that was first used in RFC = 4307 [RFC4307] is to use SHOULD+, SHOULD-, and MUST- in the = specification of algorithms. Russ From nobody Mon Jun 1 23:18:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8451A701A for ; Mon, 1 Jun 2015 23:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWGZOm0dZreP for ; Mon, 1 Jun 2015 23:18:45 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667CE1A701E for ; Mon, 1 Jun 2015 23:18:45 -0700 (PDT) Received: by wgv5 with SMTP id 5so131296730wgv.1 for ; Mon, 01 Jun 2015 23:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vf7Z0Yy1dDDEBotO8ZMl+VI0I7fyYn1g2JqGyy04piQ=; b=hcy/qhiVphPK5qZKdvo2VyNpwUoINySQFB9NKgzuGY+eVyW9LzicZLt0Owmxrs6v49 BBaOzKR/0RrPFv3YbGmsYlw8cbgORBLA7NWuGm8x4Xx99Xd+02qSyeax31Qu771b8y0y GQLqu1vNpaiWjGFsXLk3USguzZB5bLPjMV0F0f9nNKpvh+RoQBsoPOoNbT6ZbFDsTlCR 7rrVlcUdgwcXhs/a/GUHzFkmbzcCG7mFqBKRiczs/oZJMpUln4cNrQqOY9WOScQS/IzE JyICpePrjSskPx+CLIU3sc3SKZ+w1pzaN/bsK6AI/tD7cbLjh+aZ9wsdXV257qta+6BE kSlw== MIME-Version: 1.0 X-Received: by 10.180.95.40 with SMTP id dh8mr27599833wib.35.1433225924127; Mon, 01 Jun 2015 23:18:44 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 1 Jun 2015 23:18:44 -0700 (PDT) In-Reply-To: <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> Date: Mon, 1 Jun 2015 23:18:44 -0700 Message-ID: From: Watson Ladd To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 06:18:47 -0000 On Mon, Jun 1, 2015 at 11:19 AM, Russ Housley wrote: > Christian and Ian: > >> On 26/05/2015 19:15 pm, Christian Huitema wrote: >>>>> Apart from an initial comment on the draft I've tried to avoid gettin= g >>>>> involved in a debate over this since I think the issue is at least as >>>>> much (if not more) religious than technical. For example I can use >>>>> Russ' WEP example to argue exactly the opposite of the point he's >>>>> trying to make: The problem with WEP wasn't a 1TCS one, it was that i= t >>>>> was designed by non-cryptographers, and was badly broken. If they'd >>>>> gone with four cipher suites instead of one, we'd just have four badl= y >>>>> broken ones instead of one, or, worse, three badly broken ones and on= e >>>>> not-quite-as-broken one so they could tell everyone to use the not-qu= ite-as- >>>> bad one. >>>> >>>> I see the history a bit differently. The original WEP had a 40-bit ke= y, and no one >>>> looked at the protocol because the security was obviously weak. When = the key >>>> size was increased to 128-bits, then people looked at the protocol and= saw all of >>>> the major mistakes. It is hard to believe that so many mistakes can b= e made in >>>> one protocol. >>> >>> WEP is certainly one of the worse examples out there. The initial key l= ength was ridiculous, the initialization vector was used incorrectly, the l= inear CRC did not protect the data integrity, etc. It seems like a textbook= example against having just one cipher. But at the same time, WEP issues c= ould not be fixed by just changing the underlying encryption algorithm. The= fixes required changing the whole protocol, which is actually an example o= f versioning. >> >> "But at the same time..." :) >> >>> The other "bad example" of security design is of course the use of A5 i= n GSM. This one provides an interesting view on key and algorithm negotiati= on. The standard was deliberately compromised to enable mass surveillance. >> >> It was deliberately compromised, yes. The MiB were in the design room. >> >> However, it is important to remember our security modelling. GSM crypto= was designed to protect against two things: paparazzi and billing fraud. = It did those very well. It was never designed to protect against national= security agencies, and didn't need to, given that the GSM protocol was onl= y secure on air. Both the European agencies and every other agency could e= asily hack in and listen in the clear. > > Both WEP and GSM A5 were only intended to protect one radio hop. > > The capabilities available to the non-nation-state attacker grew consider= ably from the time of the design to the end-of-life for that design. And, = that is the thing that we need to consider for this document. What guidanc= e would allow a solid protocol design an the transition to a stronger algor= ithm? Taking the opportunity to expand on my previous email: A Freudian slip much? Because we really do care about stopping nation state adversaries, and can afford to only use strong ciphers. When A5 designed the goal was 56 bit security. But the existence of Berkenlamp-Massey algorithm and the design of A5 ensures that a guess and determine attack is possible, as Ross Anderson noted in 1994, shortly after public description of the algorithm. That should have started the clock ticking on replacement, but didn't. DES would have been a better, more studied choice, but probably didn't fit the performance requirements. Fallback to A5/2 is one of the major issues: the same key is used with two ciphers, one weak and one strong. When GSM began to replace A5/1 and A5/2, they picked A5/3 as KATSUMI, a modified MISTY. But the modifications reduced security significantly in the related key mode, and were done concurrently with the AES, which produced a much better result. Likewise, WEP used a known-broken cipher. The first analysis results on RC4 date from a month after it was publicly presented, and are due to Andrew Roos, back in 1995. They should have immediately disqualified it from use, but didn't for unclear reasons. If we want to do better, we need to learn. I think this draft should provide the following guidance: -Key agreement schemes should produce keys that hash the entire transcript. -Signatures should indicate all data that affects the choice of what is being signed at the start to avoid cross-protocol attacks. -Replacement of algorithms needs to begin when results are discovered, not when attacks become practical. -In order to ensure algorithms aren't used, the code needs to be deleted by a certain date. If that cannot be achieved, ending use is only an illusion. -Protocol designers should be familiar with the cryptographic literature regarding constructions and ciphers used. Sincerely, Watson Ladd > > Russ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Jun 2 05:09:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7B1B2D86 for ; Tue, 2 Jun 2015 05:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECGDIBJl8AEx for ; Tue, 2 Jun 2015 05:09:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0891B2D81 for ; Tue, 2 Jun 2015 05:09:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4480BEE3; Tue, 2 Jun 2015 13:09:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9zFidIYQrha; Tue, 2 Jun 2015 13:09:36 +0100 (IST) Received: from [10.0.65.147] (unknown [31.216.236.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E550EBE97; Tue, 2 Jun 2015 13:09:35 +0100 (IST) Message-ID: <556D9CFF.7030803@cs.tcd.ie> Date: Tue, 02 Jun 2015 13:09:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Watson Ladd , Russ Housley References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 12:09:41 -0000 Hi Watson, On 02/06/15 07:18, Watson Ladd wrote: > -Replacement of algorithms needs to begin when results are discovered, > not when attacks become practical. Just on this point. Most IETF folks do not monitor the academic literature for crypto publications. And indeed, it's in the nature of academic publishing that all papers try to sound like they are world-changers (with a few honourable exceptions), so it's not clear to me that we should immediately start to deprecate as soon as a preprint hits arxiv.org in all cases. So there's a bit of skilled interpretation required here. I don't think it's part of Russ' draft, but if folks had any ideas of ways to better feed important academic results into the IETF process that'd be good. (And yes, we could ask CFRG, but I'm not sure that kind of ongoing maintenance type thing is so well suited for that group.) I wonder if some of the larger vendors have groups who do this internally and would be willing to share some of that analysis with the IETF from time to time? Anyway, ideas welcome. Cheers, S. From nobody Tue Jun 2 06:17:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8E1A1AAE for ; Tue, 2 Jun 2015 06:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQKjSNf6ifzm for ; Tue, 2 Jun 2015 06:17:17 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2211A1AAD for ; Tue, 2 Jun 2015 06:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433251037; x=1464787037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rOCtnBvWoTRqIyzAL3F6E3eFZYCoNspaWiMexXM8En4=; b=ttl52eMKr1w7RHpN9J2y//0hO0IXjWakptAWh3n52ReRZFo4bJEUc7Gf eK9uK3Y9AB00XIebQEKW0hHX/smGLUV7pcNP6zjXc7uc5PvY+563Kwspg sBVQ6jJAkUbJ7/20ArQzA8CyxmjIE79gXqP6sT+p+3gSb+ZYNc71pfZ81 XnJEjD3uG7wDjtjq2Liv65WVSaY1Zj/o7RRHYKi1KehVA8SfYtfBKy3qm P8mXqwOfgEh/UJ2bWudiCuqyU6kwVKaNDsKl/9i7oHr8Fh9xJM9cgc2Qi zsBfZ70t3aiDBGP4+9eVID9ikPJz3AfglXcmrQyymsEo3C65g3wZlHrLn w==; X-IronPort-AV: E=Sophos;i="5.13,539,1427713200"; d="scan'208";a="20262276" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 01:17:16 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 01:17:15 +1200 From: Peter Gutmann To: Stephen Farrell , Watson Ladd , Russ Housley Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9 Date: Tue, 2 Jun 2015 13:17:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> , <556D9CFF.7030803@cs.tcd.ie> In-Reply-To: <556D9CFF.7030803@cs.tcd.ie> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:17:22 -0000 Stephen Farrell writes:=0A= =0A= >And indeed, it's in the nature of academic publishing that all papers try = to=0A= >sound like they are world-changers (with a few honourable exceptions), so = it's=0A= >not clear to me that we should immediately start to deprecate as soo= n as=0A= >a preprint hits arxiv.org in all cases.=0A= =0A= +1 Insightful. On the one hand there are complaints that vendors won't do= =0A= anything until there's an active exploit in the wild, but then if they=0A= believed every arxiv.org (although I'd use eprint.iacr.org) article then=0A= nothing would be safe to use. Or, worse, there'd be ten conflicting ways t= hat=0A= we're supposed to use something safely. So then it becomes a judgement cal= l=0A= on what to respond to and what can be safely ignored, or perhaps postponed= =0A= until more data is available.=0A= =0A= For me, this is an engineering issue, not a crypto/mathematics one. At the= =0A= start of my book on crypto architecture design I include Jon Bentley's quot= e=0A= about John Roebling:=0A= =0A= John Roebling had sense enough to know what he didn=92t know. So he desi= gned=0A= the stiffness of the truss on the Brooklyn Bridge roadway to be six times= =0A= what a normal calculation based on known static and dynamic loads would h= ave=0A= called for. When Roebling was asked whether his proposed bridge wouldn=92= t=0A= collapse like so many others, he said =93No, because I designed it six ti= mes=0A= as strong as it needs to be, to prevent that from happening=94=0A= =0A= If you look at SSL, that design principle is evident there in the use of du= al=0A= MD5 + SHA1 hashes. MD5 has been broken, SHA1 is looking a bit wobbly, but = no-=0A= one's even managed to suggest an attack against the combined hashes. It's = a=0A= 20-year-old design using broken/near-broken hash functions, and yet its=0A= Roebling-style design means it's still sound, and there's (currently) no si= gn=0A= of it failing.=0A= =0A= Peter.= From nobody Tue Jun 2 09:05:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFB71B2E55 for ; Tue, 2 Jun 2015 09:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77a5HEdrEgWi for ; Tue, 2 Jun 2015 09:05:50 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EAF331B2C6C for ; Tue, 2 Jun 2015 09:02:40 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8869C9A400D; Tue, 2 Jun 2015 12:02:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 2c+1CGb0qDam; Tue, 2 Jun 2015 12:01:10 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BD5109A401A; Tue, 2 Jun 2015 12:02:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 2 Jun 2015 12:01:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C3DEE19-97C8-4150-ACC8-24B4DAA45CF3@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:05:52 -0000 Phillip: > Comments >=20 > Section 2.2 >=20 > " Note that this is not done for protocols that are embedded in > other protocols, where the system-level protocol specification > identifies the mandatory-to-implement algorithm or suite." >=20 > I would rather this is called out as a named exception, = 'Specifications that provide a platform' or some such. >=20 > The reason for this is that I have sat through many unproductive hours = of argument over what should be MTI in what is obviously a platform = spec. Having RSA-SHA1 be MTI in XML Signature only hurts. >=20 > As written, the language uses 'protocol' which is too narrow. Only = some IETF specs are protocols. I suggest a subsection: 2.2.1. Platform Specifications Note that mandatory-to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases the system-level protocol specification identifies the mandatory-to-implement algorithm or suite. For example, S/MIME [RFC5751] makes use of the cryptographic message Syntax (CMS) [RFC5652], and S/MIME specifies the mandatory-to-implement algorithms, not CMS. This approach allows other protocols can make use of CMS and make different mandatory-to-implement algorithm choices. > "To achieve this > goal, the base protocol specification includes a reference to a > companion algorithms document, allowing the update of one document > without necessarily requiring an update to the other. " >=20 > I would prefer it if the 'companion document' can be shared across = specs. As a practical matter, a mail client has to use TLS these days. = Ergo the intersection of the cipher suites supported by TLS, OpenPGP and = S/MIME should be non-zero and be MTI for the 'email' domain. This cross-many-security-protocol document seems like a pretty high bar. = I am unaware of any attempt to write used a document, ever. So, it = certainly is not current practice. Russ From nobody Tue Jun 2 09:07:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F311B2A69 for ; Tue, 2 Jun 2015 09:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39Ut_0ee5R_u for ; Tue, 2 Jun 2015 09:07:50 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 42DCA1B2A82 for ; Tue, 2 Jun 2015 09:06:17 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 01E9C9A404C for ; Tue, 2 Jun 2015 12:06:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id XPZQa1NyM9Ju for ; Tue, 2 Jun 2015 12:04:46 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4C31C9A4019 for ; Tue, 2 Jun 2015 12:05:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 2 Jun 2015 12:05:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> , <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> To: IETF SAAG X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:07:51 -0000 >> And indeed, it's in the nature of academic publishing that all papers = try to >> sound like they are world-changers (with a few honourable = exceptions), so it's >> not clear to me that we should immediately start to deprecate = as soon as >> a preprint hits arxiv.org in all cases. >=20 > +1 Insightful. On the one hand there are complaints that vendors = won't do > anything until there's an active exploit in the wild, but then if they > believed every arxiv.org (although I'd use eprint.iacr.org) article = then > nothing would be safe to use. Or, worse, there'd be ten conflicting = ways that > we're supposed to use something safely. So then it becomes a = judgement call > on what to respond to and what can be safely ignored, or perhaps = postponed > until more data is available. Does this capture the point? It takes a long time to specify, implement, and deploy a replacement algorithm or suite. For this reason, the transition process needs to begin when initial flaws are discovered, not when attacks become practical. Russ= From nobody Tue Jun 2 09:36:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140ED1AC3B5 for ; Tue, 2 Jun 2015 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RUc4S8JOYKg for ; Tue, 2 Jun 2015 09:36:23 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846E51B2B02 for ; Tue, 2 Jun 2015 09:36:23 -0700 (PDT) Received: by wibut5 with SMTP id ut5so75153933wib.1 for ; Tue, 02 Jun 2015 09:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gKqJOy3uzefpjCebUh0CgmTyP2l8nH99xwae7RFjLbE=; b=UQi1gi1MxN6q9Cp4rnNE7oC/WL9Wom0qXGQvH7Z5el1UgujKv3dDwHmsF0sS75ouha Q6LPByY+9ujYJaOB5TscrI59LL4gC/6OI1HHj/ZJls521wFYPJO/iOdh4p+b1hDP++eT Vl+Lb/s7/zPZwGigFCVwFPsPvDCPdqzZtnD5StDslUUexaMN3O+DbokyfbPNXWTpBTqk VCatTsf0n+HXfbOPsBgsXLbww9M943rvJ4r3+sTeIUwMNrtrp6ah2HebNYo6COzZG7nv ry3ZYH32h/oHY5hYN6EgiQKJpKE4Nh2tGoUhRzliZEuayOwPGDoM2hrKKZoCx9ht/3h+ gsfw== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr7617928wjb.94.1433262982311; Tue, 02 Jun 2015 09:36:22 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Tue, 2 Jun 2015 09:36:22 -0700 (PDT) In-Reply-To: <556D9CFF.7030803@cs.tcd.ie> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> Date: Tue, 2 Jun 2015 09:36:22 -0700 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:36:32 -0000 On Jun 2, 2015 5:09 AM, "Stephen Farrell" wrote: > > > Hi Watson, > > On 02/06/15 07:18, Watson Ladd wrote: > > -Replacement of algorithms needs to begin when results are discovered, > > not when attacks become practical. > > Just on this point. Most IETF folks do not monitor the academic > literature for crypto publications. And indeed, it's in the nature > of academic publishing that all papers try to sound like they are > world-changers (with a few honourable exceptions), so it's not clear > to me that we should immediately start to deprecate as soon > as a preprint hits arxiv.org in all cases. So > there's a bit of skilled interpretation required here. It's true that some foo has issue papers are overhyped or contain mistakes. But this tends to be easy to notice. Wang's 2004 MD5 paper came complete with collisions. Andrew Roos's experimental observations can be replicated with a comparatively small amount of machine time. Could you point to examples of attack papers, widely believed to work, that should have been ignored? Of course, if you don't understand what properties ciphers are required to have, you'll ignore any result. IETF participants were absolutely aware of the 2001 Vaudenay paper, and Bard's production of practical attacks: look at Bodo Moeller's text file from 2004, detailing these attacks. They dismissed them for incorrect reasons, and never fixed the core problems. The Fluhrer and McGrew of RC4 cryptanalysis are who you think they are. That didn't help with RC4 depreciation, which didn't start until 2013. One of the flaws which logjam exploits is the absence of any data indicating what was supposed to be signed. This was a widely known weakness of TLS, which wasn't fixed through several revisions. It doesn't exist in SSH, and IKEv2 handles it slightly better. Clearly some people understood the issues better than others, and some communities, like the SSH community, have been able to react better than other communities like the TLS community. This is not missing obscure paper on the archive: these were widely publicized results, or in some cases immediately visible flaws in schemes, which some people payed attention to and others didn't. The problem is not "plugging into the IETF", but the way in which IETF participants don't take security seriously, and instead come to accept longstanding issues as not worth the trouble of fixing: the IKEv1 aggressive mode issue that the NSA is exploiting today isn't new. > > I don't think it's part of Russ' draft, but if folks had any ideas > of ways to better feed important academic results into the IETF > process that'd be good. (And yes, we could ask CFRG, but I'm not > sure that kind of ongoing maintenance type thing is so well suited > for that group.) > > I wonder if some of the larger vendors have groups who do this > internally and would be willing to share some of that analysis with > the IETF from time to time? > > Anyway, ideas welcome. > > Cheers, > S. > > From nobody Tue Jun 2 09:56:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4C61A6EF1 for ; Tue, 2 Jun 2015 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhAie_6Hhcrk for ; Tue, 2 Jun 2015 09:56:35 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5342A1A0107 for ; Tue, 2 Jun 2015 09:56:35 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 28C5526C090; Tue, 2 Jun 2015 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=fKfzi8f5dBQ1qZ 6jMlJaJ2/2rNg=; b=r8GMQ5N9JlW3OhZgNhorqcT/ynB/mXbWKmyIfs5nmgwMA6 H/wSpkGjpD7ZJ8pdjkcvsiFsgoJPW1To+CI2VHNpA/l9rrev1maIOpJ80yAwbKxs 9gmUJbapMxwxgjKkv4cuBxgjyS/ISb0UdyoxvhCumAOgBMxqS5Xd87j4r1IKQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id E020B26C0A3; Tue, 2 Jun 2015 09:56:33 -0700 (PDT) Date: Tue, 2 Jun 2015 11:56:32 -0500 From: Nico Williams To: Russ Housley Message-ID: <20150602165630.GI17122@localhost> References: <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:56:36 -0000 On Tue, Jun 02, 2015 at 12:05:35PM -0400, Russ Housley wrote: > It takes a long time to specify, implement, and deploy a replacement > algorithm or suite. For this reason, the transition process needs to > begin when initial flaws are discovered, not when attacks become > practical. Our protocols need to be agile-capable so that we don't have to struggle with that aspect of protocol design when it comes time to design, specify, implement, and deploy a replacement algorithm/algorithm suite. As to when an algorithm's flaws are first found, well, generally we can start extrapolating based on Moore's law and past improvements in cryptanalysis capabilities. Every flaw isn't panic button worthy, but some are. We need a process to decide when to hit the panic button. The IETF ought to commit to reviewing public cryptanalysis results and then making _official_ (IESG and IAB) statements as to their impact on Internet protocols in particular, and the IETF in general. Official statements coupled with I* policy. That is: we should NOT allow ourselves to ignore public cryptanalysis results (whatever the cause might be, such as apathy, inertia, whatever). This way we'll be ready to start the migration process as soon as it becomes advisable to do so. And if we make our protocols agile to begin with, then migrations won't hurt much. Nico -- From nobody Tue Jun 2 09:59:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9C1B2B5E for ; Tue, 2 Jun 2015 09:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS39qtoTiPQp for ; Tue, 2 Jun 2015 09:59:53 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9621B2B39 for ; Tue, 2 Jun 2015 09:59:53 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id A6BC22005E61D; Tue, 2 Jun 2015 09:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=idBE0ew+NYDtU+ r2PKBuAOTwyUM=; b=Ocxl7e82WMu9oeYJVKCni1FitR/HO40dglCGjTzGtiARVS JkpU4I/XP22VoTLF3oKFi4gmHEkLi6yZmnk0BpzmX48Yz0/HrqsJjM3JyqfD2gvU ZBhB1Hyri3Js7d/ndBACLWHchAL7zLKxCPdMKBINCI9lHbfiIlUghU49xPZdQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 38BC22005E61A; Tue, 2 Jun 2015 09:59:50 -0700 (PDT) Date: Tue, 2 Jun 2015 11:59:49 -0500 From: Nico Williams To: Russ Housley Message-ID: <20150602165948.GJ17122@localhost> References: <555FA6C5.5000004@cs.tcd.ie> <8C3DEE19-97C8-4150-ACC8-24B4DAA45CF3@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C3DEE19-97C8-4150-ACC8-24B4DAA45CF3@vigilsec.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:59:54 -0000 On Tue, Jun 02, 2015 at 12:01:58PM -0400, Russ Housley wrote: > I suggest a subsection: > > 2.2.1. Platform Specifications > > Note that mandatory-to-implement algorithms or suites are not > specified for protocols that are embedded in other protocols; in > these cases the system-level protocol specification identifies the > mandatory-to-implement algorithm or suite. For example, S/MIME > [RFC5751] makes use of the cryptographic message Syntax (CMS) > [RFC5652], and S/MIME specifies the mandatory-to-implement > algorithms, not CMS. This approach allows other protocols can make > use of CMS and make different mandatory-to-implement algorithm > choices. I agree with this. But note that TLS is not quite like CMS here. TLS needs a set of MTIs for general use. Other profiles of TLS might change this. > > I would prefer it if the 'companion document' can be shared across > > specs. As a practical matter, a mail client has to use TLS these > > days. Ergo the intersection of the cipher suites supported by TLS, > > OpenPGP and S/MIME should be non-zero and be MTI for the 'email' > > domain. > > This cross-many-security-protocol document seems like a pretty high > bar. I am unaware of any attempt to write used a document, ever. So, > it certainly is not current practice. If we can pull it off, we should. How many such "domains" might we have? Nico -- From nobody Tue Jun 2 10:15:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BD91B2C5D for ; Tue, 2 Jun 2015 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1LOCTgvw-_I for ; Tue, 2 Jun 2015 10:15:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C631B2C54 for ; Tue, 2 Jun 2015 10:15:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0706EBEE0; Tue, 2 Jun 2015 18:15:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV0ry7RQ_6YF; Tue, 2 Jun 2015 18:15:11 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C330ABEDF; Tue, 2 Jun 2015 18:15:11 +0100 (IST) Message-ID: <556DE49F.6000904@cs.tcd.ie> Date: Tue, 02 Jun 2015 18:15:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams , Russ Housley References: <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> In-Reply-To: <20150602165630.GI17122@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 17:15:19 -0000 Hi Nico, On 02/06/15 17:56, Nico Williams wrote: > On Tue, Jun 02, 2015 at 12:05:35PM -0400, Russ Housley wrote: >> It takes a long time to specify, implement, and deploy a replacement >> algorithm or suite. For this reason, the transition process needs to >> begin when initial flaws are discovered, not when attacks become >> practical. > > Our protocols need to be agile-capable so that we don't have to struggle > with that aspect of protocol design when it comes time to design, > specify, implement, and deploy a replacement algorithm/algorithm suite. > > As to when an algorithm's flaws are first found, well, generally we can > start extrapolating based on Moore's law and past improvements in > cryptanalysis capabilities. Every flaw isn't panic button worthy, but > some are. We need a process to decide when to hit the panic button. > > The IETF ought to commit to reviewing public cryptanalysis results and > then making _official_ (IESG and IAB) statements as to their impact on > Internet protocols in particular, and the IETF in general. > > Official statements coupled with I* policy. In practice the IESG (and probably the IAB) would assume the SEC ADs would do this. I don't think it's feasible to assume that the SEC ADs are going to be able to monitor all academic crypto publications. (That also goes against attempts the IESG are starting to make to reduce the time required for the AD role.) And I'm not sure if pronouncement from on high like that are really a good plan for us either, even though it has been the case that the IETF and implementers of IETF RFCs have been too slow to deprecate stuff. So while I do like the aimed-for outcome, I really doubt there's a mechanism to get there that'd work. But if you have a detailed suggestion I'd be v. interested. Cheers, S. > > That is: we should NOT allow ourselves to ignore public cryptanalysis > results (whatever the cause might be, such as apathy, inertia, whatever). > > This way we'll be ready to start the migration process as soon as it > becomes advisable to do so. And if we make our protocols agile to begin > with, then migrations won't hurt much. > > Nico > From nobody Tue Jun 2 10:42:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102F11B2F03 for ; Tue, 2 Jun 2015 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-fogGtjpMvB for ; Tue, 2 Jun 2015 10:42:18 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 352F51ACE34 for ; Tue, 2 Jun 2015 10:42:18 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id C0A8C20047B88; Tue, 2 Jun 2015 10:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9/ctLyldFwxb9y fzDLvIBKCFWbg=; b=I0JlIMnx9wNGW6tc2An1+OTrVG0/GnRfX78lBcE3PQdBOJ x79poqGrudBHMfRNtHLjvK7D1tanwv687F+hMncThEaeYGG8LEYCzHtR43f+YEGY UVBtd7CLuA/WWVl1wv4FBXlOsIb0WqEOyr9IPtkyTE+x9mCOaJzRJ5pyQdyMc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 779E920047B8A; Tue, 2 Jun 2015 10:42:16 -0700 (PDT) Date: Tue, 2 Jun 2015 12:42:15 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150602174214.GL17122@localhost> References: <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556DE49F.6000904@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 17:42:19 -0000 On Tue, Jun 02, 2015 at 06:15:11PM +0100, Stephen Farrell wrote: > On 02/06/15 17:56, Nico Williams wrote: > > The IETF ought to commit to reviewing public cryptanalysis results and > > then making _official_ (IESG and IAB) statements as to their impact on > > Internet protocols in particular, and the IETF in general. > > > > Official statements coupled with I* policy. > > In practice the IESG (and probably the IAB) would assume the > SEC ADs would do this. I don't think it's feasible to assume > that the SEC ADs are going to be able to monitor all academic > crypto publications. (That also goes against attempts the IESG > are starting to make to reduce the time required for the AD > role.) As Watson points out, we do tend to notice cryptanalysis results that require our attention. The problem is that we've dropped the ball in the past. We need a process for obtaining official statements, and a way for anyone who notices such results to trigger it. > And I'm not sure if pronouncement from on high like that are > really a good plan for us either, even though it has been the > case that the IETF and implementers of IETF RFCs have been too > slow to deprecate stuff. It's about removing excuses. We might still take years to respond (perhaps because the protocols as deployed are not really agile, or because implementation update mechanisms are slow, or because of abandonware with large market share), but at least we'll know we have to, and everyone will know we know we have to. > So while I do like the aimed-for outcome, I really doubt > there's a mechanism to get there that'd work. But if you have > a detailed suggestion I'd be v. interested. - someone notices such a paper - they open a ticket in the Datatracker requiring IAB and/or IESG attention - the IESG and/or IAB should be obliged to produce a response, with a Datatracker ticket for it. If no response is forthcoming, we'll at least have the ticket. - if an official statement is deemed unnecessary, this should be recorded in the ticket - if an official statement issues, this too should be recorded in the ticket Any proposed official statement should have IETF review. Do we need an RFC to document such a process? It should suffice that we have the requisite Datatracker functionality. Nico -- From nobody Tue Jun 2 11:08:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CBE1B3465 for ; Tue, 2 Jun 2015 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZmt6Ks8Nz-w for ; Tue, 2 Jun 2015 11:08:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378F01B346C for ; Tue, 2 Jun 2015 11:08:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B406DBEF6; Tue, 2 Jun 2015 19:08:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYEZjC5h13ry; Tue, 2 Jun 2015 19:08:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F191BEEE; Tue, 2 Jun 2015 19:08:25 +0100 (IST) Message-ID: <556DF118.5070501@cs.tcd.ie> Date: Tue, 02 Jun 2015 19:08:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> In-Reply-To: <20150602174214.GL17122@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 18:08:33 -0000 Hiya, On 02/06/15 18:42, Nico Williams wrote: > On Tue, Jun 02, 2015 at 06:15:11PM +0100, Stephen Farrell wrote: >> On 02/06/15 17:56, Nico Williams wrote: >>> The IETF ought to commit to reviewing public cryptanalysis results and >>> then making _official_ (IESG and IAB) statements as to their impact on >>> Internet protocols in particular, and the IETF in general. >>> >>> Official statements coupled with I* policy. >> >> In practice the IESG (and probably the IAB) would assume the >> SEC ADs would do this. I don't think it's feasible to assume >> that the SEC ADs are going to be able to monitor all academic >> crypto publications. (That also goes against attempts the IESG >> are starting to make to reduce the time required for the AD >> role.) > > As Watson points out, we do tend to notice cryptanalysis results that > require our attention. The problem is that we've dropped the ball in > the past. I agree we've done that. I'm less sure there would have been an overall better outcome if we'd acted sooner, but it's definitely arguable. > We need a process for obtaining official statements, and a > way for anyone who notices such results to trigger it. I'm not convinced an official statement that isn't an RFC is useful, but that's a detail, we do know how to produce statements as RFCs. > >> And I'm not sure if pronouncement from on high like that are >> really a good plan for us either, even though it has been the >> case that the IETF and implementers of IETF RFCs have been too >> slow to deprecate stuff. > > It's about removing excuses. > > We might still take years to respond (perhaps because the protocols as > deployed are not really agile, or because implementation update > mechanisms are slow, or because of abandonware with large market share), > but at least we'll know we have to, and everyone will know we know we > have to. > >> So while I do like the aimed-for outcome, I really doubt >> there's a mechanism to get there that'd work. But if you have >> a detailed suggestion I'd be v. interested. > > - someone notices such a paper > - they open a ticket in the Datatracker requiring IAB and/or IESG > attention > - the IESG and/or IAB should be obliged to produce a response, with a > Datatracker ticket for it. Yeah, I'm very unconvinced that the "IESG and/or IAB" is right for that. That'd basically be the SEC ADs (do you think the routing ADs would do it?:-) and that's too much work for which SEC ADs aren't usually qualified. To illustrate, if we got a credible problem report about alg-X, it could take quite a while to figure out all the protocols that use that, and to figure out how important/practical it is to deprecate alg-X. And even more effort to push that through the consensus process, esp if there are folks (as there will be) who'd prefer to not start deprecating alg-X just now. That's a lot of work, and as one of the SEC ADs I'd not be willing to take it on or argue that the IESG/IAB ought take it on collectively. I could maybe buy a version of this where we setup a new "cryptodir" with a smallish number of qualified folks selected by the IESG or SEC ADs and who have just this responsibility, i.e. to do the analysis and churn out RFCs signalling when it's time to start to deprecate alg-X or mode-Y or similar. I'd need to ponder it more though, but reactions to that (and/or other ideas) are welcome. > If no response is forthcoming, we'll at least have the ticket. > > - if an official statement is deemed unnecessary, this should be > recorded in the ticket > > - if an official statement issues, this too should be recorded in the > ticket > > Any proposed official statement should have IETF review. > > Do we need an RFC to document such a process? It should suffice that we > have the requisite Datatracker functionality. I'd say best would be to figure out something practical and where it'd be something to which thos e implementing and deploying would pay attention and then we can figure out how to do the related process-wonkery. Cheers, S. > > Nico > From nobody Tue Jun 2 11:51:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F9B1A036A for ; Tue, 2 Jun 2015 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYB3Ibz4doMl for ; Tue, 2 Jun 2015 11:51:07 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 340461A02F1 for ; Tue, 2 Jun 2015 11:51:07 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id D64F820047B86; Tue, 2 Jun 2015 11:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nuoN/hSiH/VsTV ceRNzF46xx5BU=; b=HBxZ9+he4X5moD6WMqhpSOrtkVh9Q0S6f9/eU8gTy8aPoa 5ojO2AuKJ0JRQ869pjGBEzpN+Mudvw49iZsloxozUPyFZR2hkhOkMCE2MQSeIfQS ZxNpTDkAvkKLcDPBKMHVIeAyywaU3NGzLcc+99TNRax1ktsq9tsNY1S5V73Yk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 0C18220047B80; Tue, 2 Jun 2015 11:51:05 -0700 (PDT) Date: Tue, 2 Jun 2015 13:51:04 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150602185102.GP17122@localhost> References: <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556DF118.5070501@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 18:51:08 -0000 On Tue, Jun 02, 2015 at 07:08:24PM +0100, Stephen Farrell wrote: > On 02/06/15 18:42, Nico Williams wrote: > > As Watson points out, we do tend to notice cryptanalysis results that > > require our attention. The problem is that we've dropped the ball in > > the past. > > I agree we've done that. I'm less sure there would have been > an overall better outcome if we'd acted sooner, but it's > definitely arguable. We can't know that. I'm not talking about the past anyways, but the future. > > We need a process for obtaining official statements, and a > > way for anyone who notices such results to trigger it. > > I'm not convinced an official statement that isn't an RFC > is useful, but that's a detail, we do know how to produce > statements as RFCs. Well, just this week there's a long thread about a statement, isn't there, about the IETF using HTTPS everywhere. So we do know how to make such statements in ways other than by producing RFCs. > > - someone notices such a paper > > - they open a ticket in the Datatracker requiring IAB and/or IESG > > attention > > - the IESG and/or IAB should be obliged to produce a response, with a > > Datatracker ticket for it. > > Yeah, I'm very unconvinced that the "IESG and/or IAB" is right > for that. That'd basically be the SEC ADs (do you think the > routing ADs would do it?:-) and that's too much work for which > [...] Any security-conscious AD might, or any AD might at the request of an IETF participant. That should suffice. What matters is that we begin tracking the issue and that it result in some sort of action (perhaps an RFC, perhaps something else). I don't think it's a lot of work to start the ball moving! Finishing, of course, might take a while, but again, the key is to have a datatracker item we can... track. > I could maybe buy a version of this where we setup a new > "cryptodir" with a smallish number of qualified folks selected by > the IESG or SEC ADs and who have just this responsibility, i.e. > to do the analysis and churn out RFCs signalling when it's time > to start to deprecate alg-X or mode-Y or similar. I'd need to > ponder it more though, but reactions to that (and/or other ideas) > are welcome. Secdir should suffice. How often do we think such cryptanalysis results to occur? > I'd say best would be to figure out something practical and where > it'd be something to which thos e implementing and deploying would > pay attention and then we can figure out how to do the related > process-wonkery. This is a good argument for producing an RFC. But we can start with a statement that produces the impetus for participants to bother with an RFC. Nico -- From nobody Tue Jun 2 12:18:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68FF1B2AC3 for ; Tue, 2 Jun 2015 12:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgnlGGHNKX2q for ; Tue, 2 Jun 2015 12:18:15 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051B31B2ABB for ; Tue, 2 Jun 2015 12:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433272695; x=1464808695; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5GH4C2CQ9tL+tNQuWcHW3IhgyRkUlKdDWZuQxKX805c=; b=dN4CFAjuhGaD0ortf/PD9eR+IwGw4AliPOfAqlZL3pe0NkOxmntsu7LZ eamAJ2qCqIs+Z4cELY8qxtzxQSDJqY0BgsH+LaN3ypFuxx6NsqhIKkUGR d1mVa/StKlgKphmkLn01hHVZKiGfASqkxaF7C9UQAdshvFs0LhKOlElKb uqNokkhhzR0s7DcIrd2TNBl+yf0rdBjDaM+2gUg2ypfriDu2pKJuQJFuj xDYAHL97RfAvzotkGp9rlDoVewfy+2Jf1tnY9aRmivKyjcz6whdBhe5eR L9UGh7wPg5pM4Wfp2mL/6SyK5ZNRDUod83CAcdTDBMCtiqDYV/s+TsKzb A==; X-IronPort-AV: E=Sophos;i="5.13,541,1427713200"; d="scan'208";a="20287536" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 07:18:13 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 07:18:13 +1200 From: Peter Gutmann To: Russ Housley , IETF SAAG Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9//9mRoCAAP6ycA== Date: Tue, 2 Jun 2015 19:18:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> , <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz>, <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> In-Reply-To: <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 19:18:18 -0000 Russ Housley writes:=0A= =0A= >Does this capture the point?=0A= >=0A= > It takes a long time to specify, implement, and deploy a replacement=0A= > algorithm or suite. For this reason, the transition process needs to= =0A= > begin when initial flaws are discovered, not when attacks become=0A= > practical.=0A= =0A= Uhh, no, I think it makes it worse. Every algorithm has flaws (well, with = the=0A= possible exception of Montgomery ladder-based ECC systems, which are totall= y=0A= perfect, if you've been following the discussion on the cryptography mailin= g=0A= list :-), so what the above is saying is that every crypto algorithm needs = to=0A= have steps taken to replace it.=0A= =0A= Now you could say "practically exploitable flaws", but that means different= =0A= things to different people. I don't think there's a way to definitively st= ate=0A= this.=0A= =0A= Peter.=0A= From nobody Tue Jun 2 12:25:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DBF1B2B0B for ; Tue, 2 Jun 2015 12:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNid3BTHNpqG for ; Tue, 2 Jun 2015 12:25:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B12F1B2B61 for ; Tue, 2 Jun 2015 12:25:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B1C55BEDB; Tue, 2 Jun 2015 20:25:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPxmYESGF4FC; Tue, 2 Jun 2015 20:25:20 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4AFC0BEF2; Tue, 2 Jun 2015 20:25:20 +0100 (IST) Message-ID: <556E031F.1010601@cs.tcd.ie> Date: Tue, 02 Jun 2015 20:25:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> In-Reply-To: <20150602185102.GP17122@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 19:25:34 -0000 Just a couple of points below, this is maybe more one to ponder for a bit or let's see if we get more input... On 02/06/15 19:51, Nico Williams wrote: > On Tue, Jun 02, 2015 at 07:08:24PM +0100, Stephen Farrell wrote: >> On 02/06/15 18:42, Nico Williams wrote: >>> As Watson points out, we do tend to notice cryptanalysis results that >>> require our attention. The problem is that we've dropped the ball in >>> the past. >> >> I agree we've done that. I'm less sure there would have been >> an overall better outcome if we'd acted sooner, but it's >> definitely arguable. > > We can't know that. I'm not talking about the past anyways, but the > future. > >>> We need a process for obtaining official statements, and a >>> way for anyone who notices such results to trigger it. >> >> I'm not convinced an official statement that isn't an RFC >> is useful, but that's a detail, we do know how to produce >> statements as RFCs. > > Well, just this week there's a long thread about a statement, isn't > there, about the IETF using HTTPS everywhere. So we do know how to make > such statements in ways other than by producing RFCs. > >>> - someone notices such a paper >>> - they open a ticket in the Datatracker requiring IAB and/or IESG >>> attention >>> - the IESG and/or IAB should be obliged to produce a response, with a >>> Datatracker ticket for it. >> >> Yeah, I'm very unconvinced that the "IESG and/or IAB" is right >> for that. That'd basically be the SEC ADs (do you think the >> routing ADs would do it?:-) and that's too much work for which >> [...] > > Any security-conscious AD might, or any AD might at the request of an > IETF participant. That should suffice. Sure, in theory. But we're after something systematic here so I really can't see that happening. (Where that == anyone other than the SEC ADs being on the hook for doing all the work, and this one won't be:-) > What matters is that we begin tracking the issue and that it result in > some sort of action (perhaps an RFC, perhaps something else). > > I don't think it's a lot of work to start the ball moving! Finishing, > of course, might take a while, but again, the key is to have a > datatracker item we can... track. I figure tracking is necessary, but far from sufficient for this. >> I could maybe buy a version of this where we setup a new >> "cryptodir" with a smallish number of qualified folks selected by >> the IESG or SEC ADs and who have just this responsibility, i.e. >> to do the analysis and churn out RFCs signalling when it's time >> to start to deprecate alg-X or mode-Y or similar. I'd need to >> ponder it more though, but reactions to that (and/or other ideas) >> are welcome. > > Secdir should suffice. How often do we think such cryptanalysis results > to occur? I don't think secdir is right for this myself, but I could be wrong. Reasons: a) secdir folk are good but generally aren't crypto people, b) there're ~50 secdir folks which is too many for this, if the starting point was to be some level of group-consensus that a report is worth pursuing, (which I think would be needed) and c) secdir is busy already, I think getting it even better at what it does would be more worthwhile than adding new tasks for now. Cheers, S. > >> I'd say best would be to figure out something practical and where >> it'd be something to which thos e implementing and deploying would >> pay attention and then we can figure out how to do the related >> process-wonkery. > > This is a good argument for producing an RFC. But we can start with a > statement that produces the impetus for participants to bother with an > RFC. > > Nico > From nobody Tue Jun 2 14:00:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9881B307D for ; Tue, 2 Jun 2015 14:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.833 X-Spam-Level: X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM1vJj49Tx7Q for ; Tue, 2 Jun 2015 14:00:22 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD741B3071 for ; Tue, 2 Jun 2015 14:00:22 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 146832005CF00; Tue, 2 Jun 2015 14:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yHnzqq4x2SmEds OU+xB1+G8Gs1U=; b=vPjx+IJ5G9CWwyPr3Usp1OVUCYa5Vz6C0gWmUAV7XhmKkS 6oaWaglIlVbbQU/DTzpKswK1frWKr1w/Ker3YVXuVgxtzyp042m7N1YLNyrUlCu4 iP8efVzRQEXziZ4an8mSKe3RDTBghKkUBFtGNdMv99UHDdq027sp7lfIVdmxk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 082B220058DB5; Tue, 2 Jun 2015 14:00:20 -0700 (PDT) Date: Tue, 2 Jun 2015 16:00:20 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150602205911.GQ17122@localhost> References: <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> <556E031F.1010601@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556E031F.1010601@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:00:23 -0000 On Tue, Jun 02, 2015 at 08:25:19PM +0100, Stephen Farrell wrote: > > Any security-conscious AD might, or any AD might at the request of an > > IETF participant. That should suffice. > > Sure, in theory. But we're after something systematic here > so I really can't see that happening. (Where that == anyone > other than the SEC ADs being on the hook for doing all the > work, and this one won't be:-) "on the hook for doing all the work" is not what I have in mind. More like: on the hook for shepherding the work, which is what ADs do. And if they want to delegate that to someone outside the IESG, that'd be fine too. What I imagine is that for the more obvious cases the statement would be obvious and non-controversial. "Algorithm A is now clearly on its last legs [or utterly useless, or whatever might be the case], it's time to move on. We ask that WGs X, Y, and Z re-charter to make specification for a replacement (likely algorithm B) a priority." Where the statement to make is less obvious or more controversial, an IETF LC (and I-D vehicle for it?) may be necessary. So what. > I figure tracking is necessary, but far from sufficient for > this. Tracking is a first step. Not quite a sine qua non, but look, it doesn't cost much and it will be harder for us to ignore things that shouldn't be if we have a tracker. > > Secdir should suffice. How often do we think such cryptanalysis results > > to occur? > > I don't think secdir is right for this myself, but I could be > wrong. Reasons: a) secdir folk are good but generally aren't crypto > people, b) there're ~50 secdir folks which is too many for this, Yes, but again, some of the papers we're talking about have very obvious impact. If not, go ask CFRG or whatever crypto experts you can round up. If you (the ADs, the IESG, the IAB) can't find the requisite expertise and advise even when you ask for it, and you're not sure yourselves, then leave the issue open in the tracker and make no statement until the expert advise required materializes. > if the starting point was to be some level of group-consensus that > a report is worth pursuing, (which I think would be needed) and > c) secdir is busy already, I think getting it even better at what > it does would be more worthwhile than adding new tasks for now. The starting point is never consensus. The starting point is a proposal that begins the process of discovering consensus. I want to put the onus for *starting* that process on the adults in the room: the IESG and the IAB. With luck you won't really have to do much because we, IETF participants, hopefully will be on the ball. It's not like you guys don't make statements about this or that all the time. And it's not like keeping an eye on cryptanalysis news is something you really don't do or really ought not have to do. We engineer cryptographic protocols here. Why is all this not obvious? I don't get how this is asking ADs to do that much more work than they are doing now. When something bad happens, ETOOBUSY is not really an appropriate answer. (Don't make me browbeat you into this even more. That's no fun. Submit already! :) Nico -- From nobody Tue Jun 2 14:01:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477E41A8A1F for ; Tue, 2 Jun 2015 14:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaZGm9jJAlK7 for ; Tue, 2 Jun 2015 14:01:29 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848C61A8A49 for ; Tue, 2 Jun 2015 14:01:28 -0700 (PDT) Received: by wgez8 with SMTP id z8so150202226wge.0 for ; Tue, 02 Jun 2015 14:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Qbsy9hh64DIlBukeZtMbuhAQ09O/QzrzbIELNrHX7Y=; b=mSs19I7l1lo29VkAkMeEjFAwJEYJ9QeF6iGKnDSIEkEq+pa1yeKBIJbF/NAyF2xwoZ QEy/3cCix4yjvMLr9f9N1vRGbKTpX9xuZUdpzlWgZBnxxhOl7mMNBv5i9TeURfqdeyPt 9bkahHWM0fMAGcm1a+ZUAj5LPZTMki/zsRyro8iDrl3XYZNgC+Qw5J05GyoZRahcjiZd wKkQZA9OO67fW/5IzFLVC13SJu4khp1HIEehWSI7c5MYPXIdmAfeua3RLFzI+eb3nSQR M7k9hjNMa0TL//66wtlVMo3N5iClNpsCmRFwUC2QH5Gvs3tIFkXh97O8KeGhiOdCF21h IxsA== MIME-Version: 1.0 X-Received: by 10.194.222.230 with SMTP id qp6mr55016651wjc.70.1433278887253; Tue, 02 Jun 2015 14:01:27 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Tue, 2 Jun 2015 14:01:27 -0700 (PDT) In-Reply-To: <556E031F.1010601@cs.tcd.ie> References: <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> <556E031F.1010601@cs.tcd.ie> Date: Tue, 2 Jun 2015 17:01:27 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c3bad8f0599f05178f3ed7 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:01:31 -0000 --001a11c3bad8f0599f05178f3ed7 Content-Type: text/plain; charset=UTF-8 Hello, I agree with Stephen in that we would need more help, how about... On Tue, Jun 2, 2015 at 3:25 PM, Stephen Farrell wrote: > > Just a couple of points below, this is maybe more > one to ponder for a bit or let's see if we get more > input... > > On 02/06/15 19:51, Nico Williams wrote: > > On Tue, Jun 02, 2015 at 07:08:24PM +0100, Stephen Farrell wrote: > >> On 02/06/15 18:42, Nico Williams wrote: > >>> As Watson points out, we do tend to notice cryptanalysis results that > >>> require our attention. The problem is that we've dropped the ball in > >>> the past. > >> > >> I agree we've done that. I'm less sure there would have been > >> an overall better outcome if we'd acted sooner, but it's > >> definitely arguable. > > > > We can't know that. I'm not talking about the past anyways, but the > > future. > > > >>> We need a process for obtaining official statements, and a > >>> way for anyone who notices such results to trigger it. > >> > >> I'm not convinced an official statement that isn't an RFC > >> is useful, but that's a detail, we do know how to produce > >> statements as RFCs. > > > > Well, just this week there's a long thread about a statement, isn't > > there, about the IETF using HTTPS everywhere. So we do know how to make > > such statements in ways other than by producing RFCs. > > > >>> - someone notices such a paper > That someone starts a discussion on SAAG/CFRG to get consensus on next steps. >>> - they open a ticket in the Datatracker requiring IAB and/or IESG > >>> attention > The list builds sample text in a draft or for a statement > >>> - the IESG and/or IAB should be obliged to produce a response, with a > >>> Datatracker ticket for it. > >> > >> Yeah, I'm very unconvinced that the "IESG and/or IAB" is right > >> for that. That'd basically be the SEC ADs (do you think the > >> routing ADs would do it?:-) and that's too much work for which > >> [...] > > > > Any security-conscious AD might, or any AD might at the request of an > > IETF participant. That should suffice. > > Sure, in theory. But we're after something systematic here > so I really can't see that happening. (Where that == anyone > other than the SEC ADs being on the hook for doing all the > work, and this one won't be:-) > This is tough, but delegation would be key and capable volunteers are necessary. > > > What matters is that we begin tracking the issue and that it result in > > some sort of action (perhaps an RFC, perhaps something else). > > > > I don't think it's a lot of work to start the ball moving! Finishing, > > of course, might take a while, but again, the key is to have a > > datatracker item we can... track. > > I figure tracking is necessary, but far from sufficient for > this. > Agreed, we need more help on leg work, there aren't enough hours in the day unfortunately for ADs. Thanks, Kathleen > > >> I could maybe buy a version of this where we setup a new > >> "cryptodir" with a smallish number of qualified folks selected by > >> the IESG or SEC ADs and who have just this responsibility, i.e. > >> to do the analysis and churn out RFCs signalling when it's time > >> to start to deprecate alg-X or mode-Y or similar. I'd need to > >> ponder it more though, but reactions to that (and/or other ideas) > >> are welcome. > > > > Secdir should suffice. How often do we think such cryptanalysis results > > to occur? > > I don't think secdir is right for this myself, but I could be > wrong. Reasons: a) secdir folk are good but generally aren't crypto > people, b) there're ~50 secdir folks which is too many for this, > if the starting point was to be some level of group-consensus that > a report is worth pursuing, (which I think would be needed) and > c) secdir is busy already, I think getting it even better at what > it does would be more worthwhile than adding new tasks for now. > > Cheers, > S. > > > > > >> I'd say best would be to figure out something practical and where > >> it'd be something to which thos e implementing and deploying would > >> pay attention and then we can figure out how to do the related > >> process-wonkery. > > > > This is a good argument for producing an RFC. But we can start with a > > statement that produces the impetus for participants to bother with an > > RFC. > > > > Nico > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen --001a11c3bad8f0599f05178f3ed7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I agree with Stephen in that we = would need more help, how about...

On Tue, Jun 2, 2015 at 3:25 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Just a couple of points below, this is maybe more
one to ponder for a bit or let's see if we get more
input...

On 02/06/15 19:51, Nico Williams wrote:
> On Tue, Jun 02, 2015 at 07:08:24PM +0100, Stephen Farrell wrote:
>> On 02/06/15 18:42, Nico Williams wrote:
>>> As Watson points out, we do tend to notice cryptanalysis resul= ts that
>>> require our attention.=C2=A0 The problem is that we've dro= pped the ball in
>>> the past.
>>
>> I agree we've done that. I'm less sure there would have be= en
>> an overall better outcome if we'd acted sooner, but it's >> definitely arguable.
>
> We can't know that.=C2=A0 I'm not talking about the past anywa= ys, but the
> future.
>
>>> We need a process for obtaining official statements, and a
>>> way for anyone who notices such results to trigger it.
>>
>> I'm not convinced an official statement that isn't an RFC<= br> >> is useful, but that's a detail, we do know how to produce
>> statements as RFCs.
>
> Well, just this week there's a long thread about a statement, isn&= #39;t
> there, about the IETF using HTTPS everywhere.=C2=A0 So we do know how = to make
> such statements in ways other than by producing RFCs.
>
>>>=C2=A0 - someone notices such a paper

That someone starts a discussion on SAAG/CFRG to get= consensus on next steps.

>>>=C2=A0 - they open a ticket in the Datatracker requiring IAB an= d/or IESG
>>>=C2=A0 =C2=A0 attention

The list builds sample text in a draft or for a statement
=C2=A0
>>>=C2=A0 - the IESG and/or IAB should be obliged to produce a res= ponse, with a
>>>=C2=A0 =C2=A0 Datatracker ticket for it.
>>
>> Yeah, I'm very unconvinced that the "IESG and/or IAB"= ; is right
>> for that. That'd basically be the SEC ADs (do you think the >> routing ADs would do it?:-) and that's too much work for which=
>> [...]
>
> Any security-conscious AD might, or any AD might at the request of an<= br> > IETF participant.=C2=A0 That should suffice.

Sure, in theory. But we're after something systematic here<= br> so I really can't see that happening. (Where that =3D=3D anyone
other than the SEC ADs being on the hook for doing all the
work, and this one won't be:-)

This= is tough, but delegation would be key and capable volunteers are necessary= .
=C2=A0

> What matters is that we begin tracking the issue and that it result in=
> some sort of action (perhaps an RFC, perhaps something else).
>
> I don't think it's a lot of work to start the ball moving!=C2= =A0 Finishing,
> of course, might take a while, but again, the key is to have a
> datatracker item we can... track.

I figure tracking is necessary, but far from sufficient for
this.

Agreed, we need more help on leg = work, there aren't enough hours in the day unfortunately for ADs.
=


Thanks,
Kathleen=C2=A0

>> I could maybe buy a version of this where we setup a new
>> "cryptodir" with a smallish number of qualified folks se= lected by
>> the IESG or SEC ADs and who have just this responsibility, i.e. >> to do the analysis and churn out RFCs signalling when it's tim= e
>> to start to deprecate alg-X or mode-Y or similar. I'd need to<= br> >> ponder it more though, but reactions to that (and/or other ideas)<= br> >> are welcome.
>
> Secdir should suffice.=C2=A0 How often do we think such cryptanalysis = results
> to occur?

I don't think secdir is right for this myself, but I could be wrong. Reasons: a) secdir folk are good but generally aren't crypto
people, b) there're ~50 secdir folks which is too many for this,
if the starting point was to be some level of group-consensus that
a report is worth pursuing, (which I think would be needed) and
c) secdir is busy already, I think getting it even better at what
it does would be more worthwhile than adding new tasks for now.

Cheers,
S.


>
>> I'd say best would be to figure out something practical and wh= ere
>> it'd be something to which thos e implementing and deploying w= ould
>> pay attention and then we can figure out how to do the related
>> process-wonkery.
>
> This is a good argument for producing an RFC.=C2=A0 But we can start w= ith a
> statement that produces the impetus for participants to bother with an=
> RFC.
>
> Nico
>

____________________________= ___________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



--
=

Best regards,
Kathleen
--001a11c3bad8f0599f05178f3ed7-- From nobody Tue Jun 2 14:06:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34D1B2F44 for ; Tue, 2 Jun 2015 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzzrVkfl4qi6 for ; Tue, 2 Jun 2015 14:06:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CE31B3092 for ; Tue, 2 Jun 2015 14:06:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A05B7BEF6; Tue, 2 Jun 2015 22:06:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzYm405rhuLj; Tue, 2 Jun 2015 22:06:31 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9980ABE9C; Tue, 2 Jun 2015 22:06:31 +0100 (IST) Message-ID: <556E1AD7.2090602@cs.tcd.ie> Date: Tue, 02 Jun 2015 22:06:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> <556E031F.1010601@cs.tcd.ie> <20150602205911.GQ17122@localhost> In-Reply-To: <20150602205911.GQ17122@localhost> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:06:36 -0000 On 02/06/15 22:00, Nico Williams wrote: > (Don't make me browbeat you into this even more. That's no fun. > Submit already! :) Yeah, sure. Maybe later, like when I'm done being an AD:-) More chat about this would be good though. Would anyone be willing to document a concrete proposal with enough detail so folks could shoot it down? A wiki page or git repo that folks could edit might be a fine start. Shouldn't take more than a few paragraphs to start. (And yes, anyone == Nico is fine:-) S. From nobody Tue Jun 2 14:10:23 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C381B30A0 for ; Tue, 2 Jun 2015 14:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ClZ4O9hGlhW for ; Tue, 2 Jun 2015 14:10:21 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2681B309B for ; Tue, 2 Jun 2015 14:10:21 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id D2CC43B807E; Tue, 2 Jun 2015 14:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2WE3nFs2ttPrb/ nsmKbbJXmTk4k=; b=cnus/iAh9X7kuawGjU3lT8uqVp2u3fsTMX3ylux8GopFU9 zv/YNBg0jtTnoJ+lK72GswrcHrPv+cQtUjcYGnyqlfpAZ/QyJ8EPSNDelOcj2dwM 0oUw5qqfcOVtAD4Sse0+yI+k4W0neiFq53DMlknllq9pvmi6PrhybL3DpX3AQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 6AB343B8077; Tue, 2 Jun 2015 14:10:19 -0700 (PDT) Date: Tue, 2 Jun 2015 16:10:18 -0500 From: Nico Williams To: Kathleen Moriarty Message-ID: <20150602211017.GR17122@localhost> References: <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> <556E031F.1010601@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:10:21 -0000 On Tue, Jun 02, 2015 at 05:01:27PM -0400, Kathleen Moriarty wrote: > > >>> - someone notices such a paper > > That someone starts a discussion on SAAG/CFRG to get consensus on next > steps. > > >>> - they open a ticket in the Datatracker requiring IAB and/or IESG > >>> attention SAAG is fine, but we need something we can track. > The list builds sample text in a draft or for a statement Sure. > > Sure, in theory. But we're after something systematic here > > so I really can't see that happening. (Where that == anyone > > other than the SEC ADs being on the hook for doing all the > > work, and this one won't be:-) > > This is tough, but delegation would be key and capable volunteers are > necessary. Exactly. I want an AD to be on the hook for doing that which only an AD can really do: make sure that someone's looking at this and obtaining and/or providing advice to I*. > > I figure tracking is necessary, but far from sufficient for > > this. > > Agreed, we need more help on leg work, there aren't enough hours in the day > unfortunately for ADs. Indeed, so other things may get displaced by more pressing new things. Tough, too bad, c'est la vie, them's the breaks, ... But at least you get to delegate. Ask SAAG/secdir/CFRG, random experts who are willing to provide advice free of charge (they will materialize, since plenty of vendors are effectively providing such experts to the IETF and IRTF as it is, and we are more security-conscious today). Nico -- From nobody Tue Jun 2 14:11:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D064B1A8A48 for ; Tue, 2 Jun 2015 14:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX_0uJvtsvDM for ; Tue, 2 Jun 2015 14:11:18 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 397BB1A8A29 for ; Tue, 2 Jun 2015 14:11:18 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 1843B20058DBD; Tue, 2 Jun 2015 14:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=MjlWhnXxOuUA0Z CWYOZ/hRG++KM=; b=oTueSttj5gfTQChGOP1esftP0DGMd32jIWf8OGlLr7P/Ah DeVJrSTwl4HWB3EB0K6BqBv/W/+tylmqkZQtslN664fQFtMa029iOeiqBALr13tJ VTKTu1XYjFKYBoH8DC4Jg8uE1LBBjyqQMbxuaRBadWJ0QsuklwwNTlKYUo3bI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id E692220058DB8; Tue, 2 Jun 2015 14:11:16 -0700 (PDT) Date: Tue, 2 Jun 2015 16:11:15 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150602211115.GS17122@localhost> References: <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <20150602165630.GI17122@localhost> <556DE49F.6000904@cs.tcd.ie> <20150602174214.GL17122@localhost> <556DF118.5070501@cs.tcd.ie> <20150602185102.GP17122@localhost> <556E031F.1010601@cs.tcd.ie> <20150602205911.GQ17122@localhost> <556E1AD7.2090602@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556E1AD7.2090602@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:11:19 -0000 On Tue, Jun 02, 2015 at 10:06:31PM +0100, Stephen Farrell wrote: > On 02/06/15 22:00, Nico Williams wrote: > > (Don't make me browbeat you into this even more. That's no fun. > > Submit already! :) > > Yeah, sure. Maybe later, like when I'm done being an AD:-) > > More chat about this would be good though. Would anyone be > willing to document a concrete proposal with enough detail > so folks could shoot it down? A wiki page or git repo that > folks could edit might be a fine start. Shouldn't take more > than a few paragraphs to start. > > (And yes, anyone == Nico is fine:-) Sure, I'll whip up a skeleton I-D and put it on one of the git*s. From nobody Tue Jun 2 14:14:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522BA1B309B for ; Tue, 2 Jun 2015 14:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo-aqLqBPQM6 for ; Tue, 2 Jun 2015 14:14:50 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 55A651B307E for ; Tue, 2 Jun 2015 14:14:50 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 417E59A4049; Tue, 2 Jun 2015 17:14:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 6u7i69CrBJ2F; Tue, 2 Jun 2015 17:13:18 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 969269A403B; Tue, 2 Jun 2015 17:14:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 2 Jun 2015 17:14:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> , <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz>, <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:14:53 -0000 >> Does this capture the point? >>=20 >> It takes a long time to specify, implement, and deploy a replacement >> algorithm or suite. For this reason, the transition process needs = to >> begin when initial flaws are discovered, not when attacks become >> practical. >=20 > Uhh, no, I think it makes it worse. Every algorithm has flaws (well, = with the > possible exception of Montgomery ladder-based ECC systems, which are = totally > perfect, if you've been following the discussion on the cryptography = mailing > list :-), so what the above is saying is that every crypto algorithm = needs to > have steps taken to replace it. >=20 > Now you could say "practically exploitable flaws", but that means = different > things to different people. I don't think there's a way to = definitively state > this. Thanks Peter. Is this better? It takes a long time to specify, implement, and deploy a replacement algorithm or suite. For this reason, the transition process needs to begin when practically exploitable flaws become known, which is expected to be well before it becomes available in attacker toolkits. Russ From nobody Tue Jun 2 15:09:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E451B3143 for ; Tue, 2 Jun 2015 15:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK4U8rfSuruL for ; Tue, 2 Jun 2015 15:09:51 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121B31B3149 for ; Tue, 2 Jun 2015 15:05:35 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 64A2A6D7D7; Tue, 2 Jun 2015 18:05:31 -0400 (EDT) Message-ID: <556E28A7.9020203@iang.org> Date: Tue, 02 Jun 2015 23:05:27 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> In-Reply-To: <556D9CFF.7030803@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 22:09:53 -0000 On 2/06/2015 13:09 pm, Stephen Farrell wrote: > > Hi Watson, > > On 02/06/15 07:18, Watson Ladd wrote: >> -Replacement of algorithms needs to begin when results are discovered, >> not when attacks become practical. > > Just on this point. Most IETF folks do not monitor the academic > literature for crypto publications. And indeed, it's in the nature > of academic publishing that all papers try to sound like they are > world-changers (with a few honourable exceptions), so it's not clear > to me that we should immediately start to deprecate as soon > as a preprint hits arxiv.org in all cases. So > there's a bit of skilled interpretation required here. A whole lot of skilled interpretation, and unfortunately the more skill the more over-reaction. In cryptography world, a cipher can be called broken if it's lost 2 bits of strength, which is no way broken to the user world. Also, if you start monitoring, you also create a flag to capture. Crypanalysts's careers are made or unmade by the success of their papers, they are incentivised to get a red flag listed at IETF's monitoring service as with any other. > I don't think it's part of Russ' draft, but if folks had any ideas > of ways to better feed important academic results into the IETF > process that'd be good. (And yes, we could ask CFRG, but I'm not > sure that kind of ongoing maintenance type thing is so well suited > for that group.) > > I wonder if some of the larger vendors have groups who do this > internally and would be willing to share some of that analysis with > the IETF from time to time? So, several institutions present views on this. NIST has a list, as do others. About 5 years back, NIST famously started recommending that everyone shift to RSA 2048 minimum. Unfortunately (imho) its advice wasn't entirely appropriate because NIST has a different threat model to most of the rest of the world, by its charter. To some people it was no odds, to others it was an embuggerance. There is a danger in a powerful voice over-reacting, as much as under-reacting and wrong-reacting. When the Wang presentation on MD5 hit in 2004, everyone knew we were in trouble. I remember it because every cryptographer was talking about it, all of a sudden, within hours of the talk. At that time there was a feeling that SHA1 would fall imminently, and indeed SHA0 did fall fairly shortly. But SHA1 is still going strong... On the other hand people have been recommending against RC4 for the longest time, and MD5 should have been replaced from 1996 onwards. What comes out of this is that one institution isn't that reliable. A committee isn't that useful either. Simple signals don't work well. A single person can say what the single person knows, or can also be asleep. In economics we talk about the value of the buck as a reliable signal - in this context, the only thing that matters is whether someone lost dollars to theft but so far crypto itself hasn't given us that information in abundance. The industry as a group does however seem to have some sense of the wisdom of crowds. How to capture that? How about taking a straw poll at each IETF meeting? Put up a huge chart with algorithms down the left hand axis, and ratings across the top horizontal axis. Say, from 1="might as well email it to the NSA" all the way up to 10="exceeds power of sun." Then, hand a bunch of sticky dots to the various security groups and ask everyone to stick on their dots. At the end of the event count them up and display the results. It might not say much the first time, but if we see a downtrend over 3 meetings, that might indicate it's time to raise the red flag. It's also a soft indicator, if something averages at a 7 that says something whereas a 4 says something else, all in relativity. In a sense we want to record a hum over each cipher, but in a way that brings in a large choir over a longer time. iang From nobody Tue Jun 2 16:26:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A111A1A77 for ; Tue, 2 Jun 2015 16:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTdewwOIpwU3 for ; Tue, 2 Jun 2015 16:26:21 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05081A1A73 for ; Tue, 2 Jun 2015 16:26:20 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so152624511wgb.3 for ; Tue, 02 Jun 2015 16:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LPYiEAjrmKq/VERXikx9sePJpphWAk9CquYcV2jqT9U=; b=bNNpVxA7oHEAwKPqxbVmctNJvmjmUQtJ3+J/1jTofK596HSbB5Y7VjUkhDRyTQ0wrx OXLSWcA/LZrTYmKkJ9qRqsWtAOoUYmdXyWtJEsLuKKCOLFtW4qPTcWtVOa04/R+a3YCw wWCoMhvvHmtS5SFa6R7tbXLhHAqs6c2WQE4vm1sNbXQ6y3uEsLFbm64oye0zT4/s4FrE HciJ1BLnuSlMd5LrpRza+Uf7rHbVJT1tguSQyMdIUuVAAwNa9m8ZfTNIMZlGK0ZU+ArT fW9Qh6loiJW6gtboEnEsAZuStWMdbipQ5pnG8mAKbSsuFEU87d5QmNUuVDdSVmGB3qgM dwBw== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr10493041wjb.94.1433287579498; Tue, 02 Jun 2015 16:26:19 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Tue, 2 Jun 2015 16:26:19 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 2 Jun 2015 16:26:19 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:26:23 -0000 On Tue, Jun 2, 2015 at 12:18 PM, Peter Gutmann wrote: > Russ Housley writes: > >>Does this capture the point? >> >> It takes a long time to specify, implement, and deploy a replacement >> algorithm or suite. For this reason, the transition process needs to >> begin when initial flaws are discovered, not when attacks become >> practical. > > Uhh, no, I think it makes it worse. Every algorithm has flaws (well, with the > possible exception of Montgomery ladder-based ECC systems, which are totally > perfect, if you've been following the discussion on the cryptography mailing > list :-), so what the above is saying is that every crypto algorithm needs to > have steps taken to replace it. > > Now you could say "practically exploitable flaws", but that means different > things to different people. I don't think there's a way to definitively state > this. How does delaying replacement improve security? Can you point to ciphers we would have replaced where that replacement would not have been a good idea? Can you point to flaws in AES that merit replacement? I don't see how the change being proposed makes things better. If anything it enables the sort of stuff in the TLS WG where people argue against changes on the basis that the flaws don't really exist, even after live demos. How about "Replacement of an algorithm takes time. However, it is usually clear that replacement will be necessary long before exploitation techniques advance enough to produce reliable exploits. Algorithms that fail to meet the desired security goals, or where continued advance of computing power will weaken security, should be replaced ahead of time. As adversaries can record encrypted data and decrypt it later, it's more critical for encryption algorithms to be secure then authentication algorithms". > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Jun 2 16:32:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AD61A8764 for ; Tue, 2 Jun 2015 16:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y05PZVUQaSc for ; Tue, 2 Jun 2015 16:31:57 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46D1A1B76 for ; Tue, 2 Jun 2015 16:31:56 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 3407121DE6A; Tue, 2 Jun 2015 16:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=X7ptLtaI/j2mbE xYqmwpyAY14Vw=; b=c12myNlFt4uCBX/tB2a6+fMdgLYrJKNae+E6SZ2rcXLXxL 7x35++4I2rjK3hMjmk64UUcL+M388bpkRpZRXEoiI9fHIKPcmzKzihpYbNToHvqL FiOuhg9drkyrdI4/U6Ex75gXVDeaB3ia80JWM6Rn1Ju67GwQHruIl9vFy2uRs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id ACF6B21DE57; Tue, 2 Jun 2015 16:31:55 -0700 (PDT) Date: Tue, 2 Jun 2015 18:31:55 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20150602233154.GV17122@localhost> References: <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:31:58 -0000 On Tue, Jun 02, 2015 at 04:26:19PM -0700, Watson Ladd wrote: > How does delaying replacement improve security? Can you point to > [...] If it led to a surfeit of MTIs, or very fast thrashing of MTIs... Though arguably the latter would be good: we'd get to practice alg. agility, so we could make fair predictions about future costs of, and timelines for, replacement. > How about "Replacement of an algorithm takes time. However, it is > [...] > decrypt it later, it's more critical for encryption algorithms to be > secure then authentication algorithms". "...it's more critical for encryption and key exchange algorithms..." From nobody Tue Jun 2 16:34:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF51B2B46 for ; Tue, 2 Jun 2015 16:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-R9vBDMbH4C for ; Tue, 2 Jun 2015 16:34:47 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6131ACE2C for ; Tue, 2 Jun 2015 16:34:47 -0700 (PDT) Received: from [10.20.30.109] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t52NYiLo025780 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2015 16:34:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: Date: Tue, 2 Jun 2015 16:34:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> To: Watson Ladd X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 23:34:48 -0000 On Jun 2, 2015, at 4:26 PM, Watson Ladd wrote: > How does delaying replacement improve security? It does not improve cryptographic security, but it can improve = operational security. For encryption algorithms, a sender using a new algorithm before the = receiver is able to use it means that encryption will not be set up (for = interactive protocols) or the receiver will not be able to read the = message (for store-and-forward protocols). The receiver might need to = get the message, so they fall back to trying to get it unencrypted. For a signing algorithms, replacing the algorithm when verifiers don't = yet have the new algorithm means that they will receive messages that = they cannot verify that they would have been able to verify yesterday. = So, now they don't know if the message really is signed. In other words, delaying replacement the "right" amount of time improves = security. However, determining "right" is impossible when a community = contains activists, followers-along, and feet draggers. --Paul Hoffman= From nobody Wed Jun 3 01:27:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4C1B3646 for ; Wed, 3 Jun 2015 01:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGT_BurKBX3Z for ; Wed, 3 Jun 2015 01:27:51 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3301B3644 for ; Wed, 3 Jun 2015 01:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433320070; x=1464856070; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PUn2nw2Wudwmnb3/8Xwc2lYFWI6LS9hpPJfBr3rz3GE=; b=1bM0244ncu1l7yZlSedMSB1dbx5M4HRx7U0uojwcz57Y1fJKtFBt8LLK BnpUR7o/JQv4FFeIV6ySAc3h/hrjXV4nKAR8xgZfBy23/1chKnNua/dCk oOWNogOp6F91wPawdfjRPyKqk1/hQQQgI+GfyoSn+eqUchYFESz8O06n+ jRn3mx81p5LulP2hr70qE+zdGjwTztrfSW1pulKKQR/gvGsvS71fTlVbS Kcb7/s4u5zjToE9ke1KU2x5bOz58e8SwALtkBWM1IPn6bI18955EQpjcP ecrOiB3XyhiOYp9C5c3UBuFruMEt+XPpEZui5UFgmTnkt8048eaWA3vqq Q==; X-IronPort-AV: E=Sophos;i="5.13,546,1427713200"; d="scan'208";a="20501586" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 20:27:49 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 20:27:49 +1200 From: Peter Gutmann To: Russ Housley Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9//9mRoCAAP6ycP//V4KAgAGFKvk= Date: Wed, 3 Jun 2015 08:27:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> , <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz>, <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 08:27:52 -0000 Russ Housley writes:=0A= =0A= >Is this better?=0A= >=0A= > It takes a long time to specify, implement, and deploy a replacement=0A= > algorithm or suite. For this reason, the transition process needs to= =0A= > begin when practically exploitable flaws become known, which is=0A= > expected to be well before it becomes available in attacker toolkits.= =0A= =0A= Definitely. This then leaves the problem of determining what constitutes a= =0A= "practically exploitable flaw", for which until now there didn't seem to be= =0A= any obvious solution, until I saw iang's suggestion. His whole email is wo= rth=0A= reading, but I'll excerpt one bit from the end:=0A= =0A= How about taking a straw poll at each IETF meeting? Put up a huge chart= =0A= with algorithms down the left hand axis, and ratings across the top=0A= horizontal axis. Say, from 1=3D"might as well email it to the NSA" all t= he=0A= way up to 10=3D"exceeds power of sun." Then, hand a bunch of sticky dots = to=0A= the various security groups and ask everyone to stick on their dots. At = the=0A= end of the event count them up and display the results.=0A= =0A= The only change I'd make is to do it via the mailing list(s), since only a= =0A= particular subset of people go to IETF meetings.=0A= =0A= Peter.=0A= From nobody Wed Jun 3 01:33:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A01F1AD10A for ; Wed, 3 Jun 2015 01:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlJPYUWNrYMZ for ; Wed, 3 Jun 2015 01:33:05 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D61F1AD0C7 for ; Wed, 3 Jun 2015 01:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433320385; x=1464856385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ewRwrIYethb5REDrxUq76DYmpr8Se5+OU4j3D41u77g=; b=ou0oOdW/MT/AIq2Yw6OUTuHzVjhB0cYvugDd/wbNHqklFt49OP9KWL1M ucNSgnKPl93S/KQdwcnr3E17bN3l/AlrHRmyDkbbrhoFMF0E+3VC/cu08 veBUd/O5uOdQAOYQLNBYYBCFiS6EOxVsnStUtMr3EiCHcexOh0wf5blnR j9evar5BFc055B6LGZ1mjZRQJQAPlT8NIOBI926Ch5gK9iN6ba7L2OCf2 Iw/X+R2dwqafWP4OilRCdhV4QY8mmPIdJvmk0ypQhQIzhzzDVXod7ryjw yBQeUHX9MHd31HsNucg0F3HfFKYTXnhBwUPKYwxk8kwR40ojYnner1XvL Q==; X-IronPort-AV: E=Sophos;i="5.13,546,1427713200"; d="scan'208";a="20502080" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 20:33:03 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 20:32:58 +1200 From: Peter Gutmann To: Watson Ladd Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9//9mRoCAAP6ycP//fHKAgAFhqas= Date: Wed, 3 Jun 2015 08:32:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 08:33:06 -0000 Watson Ladd writes:=0A= =0A= >Can you point to flaws in AES that merit replacement?=0A= =0A= That wasn't what the original text said, it simply said "flaws" (not "flaws= =0A= that merit replacement"). See the subsequent discussion about possible=0A= methods to distinguish "flaws" from "flaws that merit replacement". In=0A= particular for:=0A= =0A= it is usually clear that replacement will be necessary long before=0A= exploitation techniques advance enough to produce reliable exploits.=0A= =0A= it is only occasionally clear, and very often the topic of endless debate,= =0A= whether replacement will be necessary. That's why I found iang's suggestio= n=0A= on a way forward interesting.=0A= =0A= Peter.= From nobody Wed Jun 3 01:37:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DF21A1A9D for ; Wed, 3 Jun 2015 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9G6XwgYuOBO for ; Wed, 3 Jun 2015 01:37:23 -0700 (PDT) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC4F1B3652 for ; Wed, 3 Jun 2015 01:37:22 -0700 (PDT) Received: from [10.11.0.122] (5ED29D98.cm-7-3c.dynamic.ziggo.nl [94.210.157.152]) (authenticated bits=0) by weser.webweaving.org (8.15.1/8.15.1) with ESMTPSA id t538Zwlj022901 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 10:35:59 +0200 (CEST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29D98.cm-7-3c.dynamic.ziggo.nl [94.210.157.152] claimed to be [10.11.0.122] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\)) From: Dirk-Willem van Gulik In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 10:35:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2100) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Wed, 03 Jun 2015 10:35:59 +0200 (CEST) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 08:37:25 -0000 > On 03 Jun 2015, at 10:27, Peter Gutmann = wrote: >=20 > Russ Housley writes: >=20 >> Is this better? >>=20 >> It takes a long time to specify, implement, and deploy a replacement >> algorithm or suite. For this reason, the transition process needs = to >> begin when practically exploitable flaws become known, which is >> expected to be well before it becomes available in attacker = toolkits. >=20 > Definitely. This then leaves the problem of determining what = constitutes a > "practically exploitable flaw", for which until now there didn't seem = to be > any obvious solution, until I saw iang's suggestion. His whole email = is worth > reading, but I'll excerpt one bit from the end: >=20 > How about taking a straw poll at each IETF meeting? Put up a huge = chart > with algorithms down the left hand axis, and ratings across the top > horizontal axis. Say, from 1=3D"might as well email it to the NSA" = all the > way up to 10=3D"exceeds power of sun." Then, hand a bunch of sticky = dots to > the various security groups and ask everyone to stick on their dots. = At the > end of the event count them up and display the results. >=20 > The only change I'd make is to do it via the mailing list(s), since = only a > particular subset of people go to IETF meetings. And perhaps have this prefixed by a smaller team taking input of the = various regional and annual 'Algorithms, Key Sizes and Parameters Report =E2=80=99s* report as a =E2=80=98minimal=E2=80=99 baseline. Dw. *: e.g. = https://www.enisa.europa.eu/activities/identity-and-trust/library/delivera= bles/algorithms-key-size-and-parameters-report-2014, the NIST = reccomendations, the BSI ones, etc. Ending up with something perhaps = akin to an updated version of: http://www.keylength.com/en/4/ From nobody Wed Jun 3 01:38:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37091B3663 for ; Wed, 3 Jun 2015 01:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk4iZtd9Nv7R for ; Wed, 3 Jun 2015 01:38:36 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4021B3662 for ; Wed, 3 Jun 2015 01:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433320716; x=1464856716; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j/IWzEoY8itljZ1sXE/LI1x22tstTd8gx+vMJ3j81HU=; b=fMWD2fuIgEXbygPdNm3MdBGUZ2qkprK1meysnTR5ohIk8Yk02kBuE+NY grOdSnDUh8umWYCBKILGTN+JtfKx3xJPZXF6NK57BAgzDMptLzwC4R1sV C0GyaT0DlkPhQZxb9xDJ8KQD/QR3uDnVnA8imQMXMvJicEluslch09HMR 4BwOxKGEBqsM+flkfGxv1TIirRGoLpKoXwtN+BYDvCOGjx2oZwNHvvtv+ gPCgiiYdf5wl/x1DMSPutryTktbFGBU1GqMx4cZ7u5aS22Twqu0dFonZh i3vt5JPhMcM2WrKd1V8D+7oDCgOmP0rxsvEivJuFo6+CfJnxjT9d0JUjH A==; X-IronPort-AV: E=Sophos;i="5.13,546,1427713200"; d="scan'208";a="20502567" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 03 Jun 2015 20:38:33 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 3 Jun 2015 20:38:34 +1200 From: Peter Gutmann To: Dirk-Willem van Gulik Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9//9mRoCAAP6ycP//V4KAgAGFKvn//zlWgAAZOVaX Date: Wed, 3 Jun 2015 08:38:33 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB034FD3@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 08:38:38 -0000 Dirk-Willem van Gulik writes:=0A= =0A= >And perhaps have this prefixed by a smaller team taking input of the vario= us=0A= >regional and annual 'Algorithms, Key Sizes and Parameters Report =92s* rep= ort as=0A= >a =91minimal=92 baseline.=0A= =0A= Uhh, no. Ideally we'd want something based on real-world experience (which= is=0A= what iang's straw poll is meant to capture), not just numerology.=0A= =0A= Peter.=0A= From nobody Wed Jun 3 03:51:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40F1A1A75 for ; Wed, 3 Jun 2015 03:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX1RjjP3i4AX for ; Wed, 3 Jun 2015 03:51:30 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDDF41A1A72 for ; Wed, 3 Jun 2015 03:51:29 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so5677532wgb.3 for ; Wed, 03 Jun 2015 03:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FPaBY+Bu0ZQXHprLqk49UILb1O9/ZFW0LtScgclukwQ=; b=yqdXc/XQpQaMF0YNegApKxbvzjft2NlDyOGC6x3cdQ5dSMqb+sH6wHJoSMoLbpcYAc 7DJhrV07HXmCSA3JXDSL1l05ZqHnz6koe3BzT+XpCo0p4P6zpB51A1ZJmSALlYjssVSp AzYXggsavfefMqE0Mr6xZ7DX+H7g0VNRC6+U2/MrQEAxhF7puOwQDipYg03GdDOkb2x3 2/dYQkOKcHAnPx/s+9LN3Pjv/sQeGP2GDohJHbVbflBGid9fTWvX/WVhkYrc6ZtWw2hq jPPWpGXFfFlpCylK56CDkpLWZcVLnkHZXZ5j9ZLluPxfQ4km3MOxhTWIvbOFiGVVlPov 880Q== X-Received: by 10.180.189.10 with SMTP id ge10mr40886513wic.85.1433328688532; Wed, 03 Jun 2015 03:51:28 -0700 (PDT) Received: from [172.24.251.185] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id tl3sm499384wjc.20.2015.06.03.03.51.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jun 2015 03:51:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <556E28A7.9020203@iang.org> Date: Wed, 3 Jun 2015 13:51:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <556E28A7.9020203@iang.org> To: ianG X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:51:31 -0000 > On Jun 3, 2015, at 1:05 AM, ianG wrote: >=20 >=20 > The industry as a group does however seem to have some sense of the = wisdom of crowds. How to capture that? The industry as a group kept using RC4 years after it was clear that = this was not a good idea. The industry as a group (not every vendor, but = some) kept using MD5 for signing certificates as late as 2009. > How about taking a straw poll at each IETF meeting? Put up a huge = chart with algorithms down the left hand axis, and ratings across the = top horizontal axis. Say, from 1=3D"might as well email it to the NSA" = all the way up to 10=3D"exceeds power of sun." >=20 > Then, hand a bunch of sticky dots to the various security groups and = ask everyone to stick on their dots. At the end of the event count them = up and display the results. It might not say much the first time, but = if we see a downtrend over 3 meetings, that might indicate it's time to = raise the red flag. It's also a soft indicator, if something averages = at a 7 that says something whereas a 4 says something else, all in = relativity. >=20 > In a sense we want to record a hum over each cipher, but in a way that = brings in a large choir over a longer time. Or we can find volunteers to keep Dave=E2=80=99s and Sean=E2=80=99s = effort current, perhaps with a bit more advice such as =E2=80=9Cgood=E2=80= =9D, =E2=80=9Cbad=E2=80=9D, =E2=80=9Ctry to migrate away=E2=80=9D: https://tools.ietf.org/html/draft-irtf-cfrg-cipher-catalog Yoav From nobody Wed Jun 3 07:22:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6331A8906 for ; Wed, 3 Jun 2015 07:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVi4OqYAwj_h for ; Wed, 3 Jun 2015 07:22:41 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id AB76F1A8903 for ; Wed, 3 Jun 2015 07:22:41 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3ACAF9A4064 for ; Wed, 3 Jun 2015 10:22:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id MX8EFB5T0HTd for ; Wed, 3 Jun 2015 10:21:11 -0400 (EDT) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9D3CA9A4066 for ; Wed, 3 Jun 2015 10:22:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 10:21:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> To: IETF SAAG X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:22:42 -0000 Trying to pull the divergent ideas together in the text, I suggest: It takes a long time to specify, implement, and deploy a replacement algorithm or suite. For this reason, the transition process needs to begin when practically exploitable flaws become known. Replacement will necessarily take a long time, but it can be accomplished before exploitation techniques become widely available exploits. Russ From nobody Wed Jun 3 07:37:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196B31A896C for ; Wed, 3 Jun 2015 07:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_CIvh9PM2pz for ; Wed, 3 Jun 2015 07:37:02 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BA91A8969 for ; Wed, 3 Jun 2015 07:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2720; q=dns/txt; s=iport; t=1433342221; x=1434551821; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Zgd3z/DQibKhJ3agy1+mS2bEvtr3aUcTl/V9HTMwJhk=; b=jCAyaBanXdhSE0fzpJoqSvQ4UM3r9Ax1O5dVh+/DQ+MoEyHEx4P2pWGr 8hAwSj9+m5UoWCIjVWZVNVKQMkYYGqfwzfMkl4pVgNUbpPPDweJb6GHdE 2nKPZNRJnCxYBxUFSVxTchd/RuaKpPIot6FR53/x+GgCoObTC/4H2W49R s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQC6D29V/xbLJq1bh2C7QodRAoF1EwEBAQEBAQGBCoQjAQEEI1URCxgJFgsCAgkDAgECAUUGAQwIAQGIKbcxo3sBAQEBAQEBAwEBAQEBAQEbi0OFDYJogUUBBJUmgUSHRoEug3OCXodhh2Qjg3o8gngBAQE X-IronPort-AV: E=Sophos;i="5.13,547,1427760000"; d="asc'?scan'208";a="504975156" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Jun 2015 14:36:59 +0000 Received: from [10.61.169.54] ([10.61.169.54]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t53EaxAo015346; Wed, 3 Jun 2015 14:36:59 GMT Message-ID: <556F110A.5020303@cisco.com> Date: Wed, 03 Jun 2015 16:36:58 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley , IETF SAAG References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> In-Reply-To: <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1JHFM0Q0txIiRP5GS0hniVwLa5ax0LofK" Archived-At: Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:37:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1JHFM0Q0txIiRP5GS0hniVwLa5ax0LofK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, I must admit I don't have the context of the whole section in my head, and so this might be a queue for a new draft rev ;-) Please see below. On 6/3/15 4:21 PM, Russ Housley wrote: > Trying to pull the divergent ideas together in the text, I suggest: > > It takes a long time to specify, implement, and deploy a replacement= > algorithm or suite. For this reason, the transition process needs t= o > begin when practically exploitable flaws become known. Replacement > will necessarily take a long time, but it can be accomplished before= > exploitation techniques become widely available exploits. > Editorially speaking I think you're saying the same thing in the first sentence and first part of the last sentence. Strictly speaking the last statement may not be true, if not qualified. Consider the case of a long-lived device with no update path (like many cell phones from yesteryear that still function today). My suggestion is to either drop the last sentence or run with something like the following: It takes a long time to specify, implement, and deploy a replacement algorithm or suite. For this reason, the transition process needs to begin when practically exploitable flaws become known. Proper and timely update processes on long-lived devices, therefore, are particularly critical. This leads to another question (sorry). Such update processes on certain classes of devices are going to slowed by certification regimes (think health and safety or other devices that can harm people). Again, the current draft isn't directly in my head, but do we want to say something about weighing the value of such certification against risk posed by the algorithm vulnerability? Eliot --1JHFM0Q0txIiRP5GS0hniVwLa5ax0LofK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVbxELAAoJEIe2a0bZ0nozccgH/RVJuJ1hnTA70tF7pcnZzuQS itzU4vYh5+PQa+7EfJWFyHAZ+zTZjujPK7G0YZ4lFrDlqI7A7hfEcBCqbF8G+HI5 5Bhb7XC2EXO7PCMDtWngxos++EU+HRwx5AfOzyoU6O/hNeoEnUkeGjoy6Uuz/ID8 mTYNMup0BTiesppi9Ymx2O5gUTuGWbXwvWKSyoMvWWD8r4+d14cWdT/olslI2cIc g45f3Cz2tbD/VUtqkRpEVuILM1LZ7P/PKdi4/IW/G6cgzfIMTGu17Doqc0pB6UdB 7rzZfZSUYvnc3Ckkt3FJsPs8XqnTqt3iTyG/jh//JV2+cJa8sx3gDo153PDCb9U= =YYuk -----END PGP SIGNATURE----- --1JHFM0Q0txIiRP5GS0hniVwLa5ax0LofK-- From nobody Wed Jun 3 07:42:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810911A8980 for ; Wed, 3 Jun 2015 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icWOb2CD2Aqe for ; Wed, 3 Jun 2015 07:42:09 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB441A896C for ; Wed, 3 Jun 2015 07:42:09 -0700 (PDT) Received: from [10.20.30.109] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t53Eg15t081342 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 07:42:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 07:42:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2098) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:42:11 -0000 On Jun 3, 2015, at 1:27 AM, Peter Gutmann = wrote: >=20 > Russ Housley writes: >=20 >> Is this better? >>=20 >> It takes a long time to specify, implement, and deploy a replacement >> algorithm or suite. For this reason, the transition process needs = to >> begin when practically exploitable flaws become known, which is >> expected to be well before it becomes available in attacker = toolkits. >=20 > Definitely. This then leaves the problem of determining what = constitutes a > "practically exploitable flaw", for which until now there didn't seem = to be > any obvious solution, until I saw iang's suggestion. His whole email = is worth > reading, but I'll excerpt one bit from the end: >=20 > How about taking a straw poll at each IETF meeting? Put up a huge = chart > with algorithms down the left hand axis, and ratings across the top > horizontal axis. Say, from 1=3D"might as well email it to the NSA" = all the > way up to 10=3D"exceeds power of sun." Then, hand a bunch of sticky = dots to > the various security groups and ask everyone to stick on their dots. = At the > end of the event count them up and display the results. >=20 > The only change I'd make is to do it via the mailing list(s), since = only a > particular subset of people go to IETF meetings. Peter, you rarely go to IETF meetings, but you are on mailing lists = here. Do you really think that the majority of people who would = participate in such a poll who have any relevant input? That is, that = they read any of the crypto research? As much as some folks here would = love the IETF to become the Crypto Police, I would only want the ones = who both read technical articles (not news reports) and can quickly and = correctly differentiate CCM from CBC, and Curve25519 from Goldilocks, = from voting in the poll. Otherwise, we might as well just do darts. Yes, your proposal would simplify things. It will also make enough wrong = statements to make operational security worse, not better, possibly in = the first year. --Paul Hoffman= From nobody Wed Jun 3 07:53:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342CA1A89ED for ; Wed, 3 Jun 2015 07:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvwAi6DsJ6vW for ; Wed, 3 Jun 2015 07:53:01 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637121A8A04 for ; Wed, 3 Jun 2015 07:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1164; q=dns/txt; s=iport; t=1433343179; x=1434552779; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=JAEuxxTs7AEqNkOniq3dcz3g6ZjB1bNwXrBcTNh5dTg=; b=AC5r5x6IRSlYvVt1yUOAQFMhlc3hByWCJnPYiYjPgfc53DRJ2dmqtX1b wUlkb4jzZMYw8nM2kUXhmpMzVZEmRTi3cqjdTK2Ig/Qe77A2biqFHM8ur SF8MDObGOWerIkJ8Y8fcHJF/+G9KN0K3QnYen7SB3cmydUvIWEBjPE3FE w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBAB5E29V/xbLJq1bh2C7OQmHUQKBdBQBAQEBAQEBgQqEIwEBBCNVEQsYCRYLAgIJAwIBAgFFBgEMCAEBiCm3P6N+AQEBAQEBAQMBAQEBAQEBG4tDhQ2CaIFFAQSQU4RTgUSHRoEug3OCXo9FI4N6PIJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,547,1427760000"; d="asc'?scan'208";a="509606486" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Jun 2015 14:52:57 +0000 Received: from [10.61.169.54] ([10.61.169.54]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t53EqvS9007984; Wed, 3 Jun 2015 14:52:57 GMT Message-ID: <556F14C8.8030103@cisco.com> Date: Wed, 03 Jun 2015 16:52:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley , IETF SAAG References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> <556F110A.5020303@cisco.com> In-Reply-To: <556F110A.5020303@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d18waldglLDPHjpXIVpK1XihnENDc5D4a" Archived-At: Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:53:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d18waldglLDPHjpXIVpK1XihnENDc5D4a Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Argh. On 6/3/15 4:36 PM, Eliot Lear wrote: > Hi Russ, > > I must admit I don't have the context of the whole section in my head, > and so this might be a queue for a new draft rev ;-) Please see below.= s/queue/cue/. --d18waldglLDPHjpXIVpK1XihnENDc5D4a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVbxTJAAoJEIe2a0bZ0nozgRsIAKF0AaSTaym2O/LK4NZGPVon 44kysWV1kSpN75LQANhc6GYd8KniCVPkLKq5TBQRHEh97rfmcHZydb+YkKGL7hWg LDzAtyaKP3l9pD6LLY46z+IBSKflLBgUNklOTQEA0ALH1EcXIQXa0ITCzlpofFuW RmZRl0YdQqgYX93Xu0EFfjHYlhmA4m/mrAA2XMJP0XRUFNjZeW2cNMZ+nAKmGRWk oaBKHQIZoZ8rzcJXrlFV2P7xHvet6UZL6vEuuRMrU2FGFpXpxzrC4wz32jkcTI+l VI6fkS1ABArYttzxRDq5I8zYsXXqU5mvLCUjmYpmgihzMrnYDRPDE2IuH05IYR4= =qVdz -----END PGP SIGNATURE----- --d18waldglLDPHjpXIVpK1XihnENDc5D4a-- From nobody Wed Jun 3 08:04:04 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5047C1A8A89 for ; Wed, 3 Jun 2015 08:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhA1sADo2R7t for ; Wed, 3 Jun 2015 08:04:00 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F3F1A8A8E for ; Wed, 3 Jun 2015 08:03:59 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so11721238wgb.3 for ; Wed, 03 Jun 2015 08:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pcXjzO9swPbgT7hmzpxhDX/eFSv2Wh7eXGh2ET9PCf8=; b=snNri2FZnYaa6wP6616X1NiXf8cE2cfM+S2gQW9GsEWOIkVbtGeYkTGVb0gFqJi+/Z 4ecs2qHgyEA1zGJwujvN3G9OgvZq/UTE6gxSzMfpXZYTi8cIsSCvgLO8W03W+gDBClHC npza/DC5tZ5ZXOBi7oFo1cUAgWYCT23VWJoHem5EXDo+5ogF/fIfanzgoSHRQR0oWnDF +O4D7aXRLKoc4lkmfAxnGi8ZMqh8dojhlYLbCjqUReAL5+bV/YV1353sEp/29OaWh728 65W+SwBVEYhhn0wvRVhBwkFoY4bbscwWZadv4eeFUHdT9AHCs04iTen3M7vnXXwzK1u1 W82Q== MIME-Version: 1.0 X-Received: by 10.180.79.73 with SMTP id h9mr42415269wix.35.1433343838323; Wed, 03 Jun 2015 08:03:58 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 3 Jun 2015 08:03:58 -0700 (PDT) In-Reply-To: References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 08:03:58 -0700 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d041825e253091c05179e5ec4 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:04:01 -0000 --f46d041825e253091c05179e5ec4 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 2, 2015 at 4:34 PM, Paul Hoffman wrote: > On Jun 2, 2015, at 4:26 PM, Watson Ladd wrote: >> How does delaying replacement improve security? > > It does not improve cryptographic security, but it can improve operational security. > > For encryption algorithms, a sender using a new algorithm before the receiver is able to use it means that encryption will not be set up (for interactive protocols) or the receiver will not be able to read the message (for store-and-forward protocols). The receiver might need to get the message, so they fall back to trying to get it unencrypted. > > For a signing algorithms, replacing the algorithm when verifiers don't yet have the new algorithm means that they will receive messages that they cannot verify that they would have been able to verify yesterday. So, now they don't know if the message really is signed. > > In other words, delaying replacement the "right" amount of time improves security. However, determining "right" is impossible when a community contains activists, followers-along, and feet draggers. Huh? I'm not saying that we shorten the time between when we roll out the new version and stop the old version. Rather, I'm saying that delaying the start of the transition is almost never a good idea. Of course, when it comes to RC4 you can turn off RC4 right now and nothing bad will happen: the MTI algorithm for all TLS is not RC4. > > --Paul Hoffman -- "Man is born free, but everywhere he is in chains". --Rousseau. --f46d041825e253091c05179e5ec4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 2, 2015 at 4:34 PM, Paul Hoffman <<= a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.hoffman@vpnc= .org> wrote:
> On Jun 2, 2015, at 4:26 PM, Watson Ladd <watsonbladd@gmail.c= om> wrote:
>> How does delaying replacement improve securit= y?
>
> It does not improve cryptographic security, but it can i= mprove operational security.
>
> For encryption algorithms, a s= ender using a new algorithm before the receiver is able to use it means tha= t encryption will not be set up (for interactive protocols) or the receiver= will not be able to read the message (for store-and-forward protocols). Th= e receiver might need to get the message, so they fall back to trying to ge= t it unencrypted.
>
> For a signing algorithms, replacing the a= lgorithm when verifiers don't yet have the new algorithm means that the= y will receive messages that they cannot verify that they would have been a= ble to verify yesterday. So, now they don't know if the message really = is signed.
>
> In other words, delaying replacement the "r= ight" amount of time improves security. However, determining "rig= ht" is impossible when a community contains activists, followers-along= , and feet draggers.

Huh? I'm not saying that we sho= rten the time between when we roll out the new version and stop the old ver= sion. Rather, I'm saying that delaying the start of the transition is a= lmost never a good idea. Of course, when it comes to RC4 you can turn off R= C4 right now and nothing bad will happen: the MTI algorithm for all TLS is = not RC4.

>
> --Paul Hoffman



--
&q= uot;Man is born free, but everywhere he is in chains".
--Rousseau.<= br>
--f46d041825e253091c05179e5ec4-- From nobody Wed Jun 3 08:41:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF7B1A906C for ; Wed, 3 Jun 2015 08:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAIAvVyTot_i for ; Wed, 3 Jun 2015 08:41:34 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D8D1A8754 for ; Wed, 3 Jun 2015 08:41:33 -0700 (PDT) Received: by wibdt2 with SMTP id dt2so17986466wib.1 for ; Wed, 03 Jun 2015 08:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rjRH1RJfIZ5AKRvIqatVPObFCYziz3jXlrl5a/BaZjk=; b=UiDrifNo2Jb6sBuXcYZVRsgDppw3jajvYVaM5+XIIi8HudKKNjWOuhwn39oYxSRZL+ Om6OfZKEn6dA1AyhleHuES0O7fXB/Ohq/kHXc4Ug1rxtDY8q00/FeC+1+qTY2q9tNkPk 5p/NhUqyc8fBcLA89QxNFa1WOo9j6n2tTZSSqIboi11bDZsHhTvBEqa3mkP7IGFVKuzB sQytR5Nob8iSXFMegcRw4kDP2xBPZ8L9uI+wrFjq5ifBqSg5ziqT1nODXLc65z7kmChL bTSc9CCoNyZooTX8m3jbdrQAEiWGJLZOS3B02ndFV5qQlL52MCRdB4WxMzux/uSrIitP Vx4A== MIME-Version: 1.0 X-Received: by 10.194.248.227 with SMTP id yp3mr61095548wjc.32.1433346092545; Wed, 03 Jun 2015 08:41:32 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 3 Jun 2015 08:41:32 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB034FD3@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034FD3@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 3 Jun 2015 08:41:32 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: multipart/alternative; boundary=089e0141a840afbbb105179ee4d6 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:41:35 -0000 --089e0141a840afbbb105179ee4d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 3, 2015 at 1:38 AM, Peter Gutmann wrote: > Dirk-Willem van Gulik writes: > > >And perhaps have this prefixed by a smaller team taking input of the > various > >regional and annual 'Algorithms, Key Sizes and Parameters Report =E2=80= =99s* > report as > >a =E2=80=98minimal=E2=80=99 baseline. > > Uhh, no. Ideally we'd want something based on real-world experience > (which is > what iang's straw poll is meant to capture), not just numerology. > Could you provide an example of when it is unclear when to depreciate today, or say from 5 years ago? Could you provide an example of recommendations based on "numerology", and explain why the analysis is wrong? Conversely, given that most people exploiting cryptography don't publicize the fact, how does real-world experience help? > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --089e0141a840afbbb105179ee4d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 1:38 AM, Peter Gutmann <pgut001@cs.auck= land.ac.nz> wrote:
Di= rk-Willem van Gulik <dirkx@webweaving.org> writes:

>And perhaps have this prefixed by a smaller team taking input of the va= rious
>regional and annual 'Algorithms, Key Sizes and Parameters Report = =E2=80=99s* report as
>a =E2=80=98minimal=E2=80=99 baseline.

Uhh, no.=C2=A0 Ideally we'd want something based on real-world e= xperience (which is
what iang's straw poll is meant to capture), not just numerology.

Could you provide an example of when it is u= nclear when to depreciate today, or say from 5 years ago?

Could you provide an example of recommendations based on "nume= rology", and explain why the analysis is wrong?

Conversely, given that most people exploiting cryptography don't pub= licize the fact, how does real-world experience help?

Peter.

_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



--
=
"Man is born free, but everywhere he is in chains".
--Rou= sseau.
--089e0141a840afbbb105179ee4d6-- From nobody Wed Jun 3 09:33:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B921ACDA4 for ; Wed, 3 Jun 2015 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1X6gVMJWEHP for ; Wed, 3 Jun 2015 09:33:52 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 04FC61ACE3A for ; Wed, 3 Jun 2015 09:31:35 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D76B69A406F; Wed, 3 Jun 2015 12:31:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id lTJ3N8P+SiuR; Wed, 3 Jun 2015 12:30:04 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 026569A4061; Wed, 3 Jun 2015 12:31:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <556F110A.5020303@cisco.com> Date: Wed, 3 Jun 2015 12:30:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8913E6ED-1D0E-4A54-915E-E69F94544EC2@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> <556F110A.5020303@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 16:33:54 -0000 Eliot: > I must admit I don't have the context of the whole section in my head, > and so this might be a queue for a new draft rev ;-) I was hoping to sort out this paragraph before turning my working buffer = into the next Internet-Draft. >> Trying to pull the divergent ideas together in the text, I suggest: >>=20 >> It takes a long time to specify, implement, and deploy a = replacement >> algorithm or suite. For this reason, the transition process needs = to >> begin when practically exploitable flaws become known. Replacement >> will necessarily take a long time, but it can be accomplished = before >> exploitation techniques become widely available exploits. >=20 > Editorially speaking I think you're saying the same thing in the first > sentence and first part of the last sentence. Strictly speaking the > last statement may not be true, if not qualified. Consider the case = of > a long-lived device with no update path (like many cell phones from > yesteryear that still function today). My suggestion is to either = drop > the last sentence or run with something like the following: >=20 > It takes a long time to specify, implement, and deploy a replacement > algorithm or suite. For this reason, the transition process needs = to > begin when practically exploitable flaws become known. Proper and > timely update processes on long-lived devices, therefore, are > particularly critical. >=20 > This leads to another question (sorry). Such update processes on > certain classes of devices are going to slowed by certification = regimes > (think health and safety or other devices that can harm people). = Again, > the current draft isn't directly in my head, but do we want to say > something about weighing the value of such certification against risk > posed by the algorithm vulnerability? This leads to a somewhat different take on the paragraph. Maybe it gets = us closer. Mechanisms for timely update of devices are needed to deploy a replacement algorithm or suite. It takes a long time to specify, implement, and deploy a replacement, therefore the transition process needs to begin when practically exploitable flaws become known. The update processes on some devices involve certification, which further increases the time to deploy a replacement. For example, devices that are part of health or safety systems often require certification before deployment. Prompt action is needed if a replacement has any hope of being deployed before exploitation techniques become widely available exploits. Russ From nobody Wed Jun 3 10:01:55 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EB01A908A for ; Wed, 3 Jun 2015 10:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkwlc7Qu4TzR for ; Wed, 3 Jun 2015 10:01:52 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD91AC3D0 for ; Wed, 3 Jun 2015 10:01:48 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 8B1582005E807; Wed, 3 Jun 2015 10:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yz9TisnBRKGap9 QXTk0qQYrlQBg=; b=MaEDGZfhP55dQAqbWLzwwuDLbvMkDn67MBiD4pk32jwGP9 wmPOuWtRh4QaDFYFccUF2uw4r9PgzTQOXmCE5dKs2HCfDknNgpiUmeZ00l74D9jq CBUg2wKoOYuGY+Qxi57ttxfUqD7K/md5QNHjegwfz3sRzttjGwjCRwy+IMSAQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id DCB202005E805; Wed, 3 Jun 2015 10:01:46 -0700 (PDT) Date: Wed, 3 Jun 2015 12:01:46 -0500 From: Nico Williams To: Paul Hoffman Message-ID: <20150603170145.GD18760@localhost> References: <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 17:01:53 -0000 On Wed, Jun 03, 2015 at 07:42:12AM -0700, Paul Hoffman wrote: > Peter, you rarely go to IETF meetings, but you are on mailing lists > here. Do you really think that the majority of people who would > participate in such a poll who have any relevant input? That is, that > they read any of the crypto research? As much as some folks here would > love the IETF to become the Crypto Police, I would only want the ones > who both read technical articles (not news reports) and can quickly > and correctly differentiate CCM from CBC, and Curve25519 from > Goldilocks, from voting in the poll. Otherwise, we might as well just > do darts. IETF consensus finding already accounts for this sort of thing. It's not about numbers of votes, and we do get to weigh input from noise-makers and experts according to their expertise and their arguments' merits. We don't need a big board, but we do need a range of estimates of realistic cryptanalysis improvements (this being speculation) and Moore's law progress (this being less speculative), which is where most of the error range in the estimated remaining useful lifetime of any cryptographic algorithm will come from. Consensus as to work factors required to break an algorithm given current cryptanalysis will, I assume, be easy to reach (though there may be errors in the cryptanalysis). Nico -- From nobody Wed Jun 3 12:18:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C0D1B2A05 for ; Wed, 3 Jun 2015 12:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcyymkkTfGiS for ; Wed, 3 Jun 2015 12:18:07 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F311B2A04 for ; Wed, 3 Jun 2015 12:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433359087; x=1464895087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uCSuxT5ZwDkribD29zvK0KHqGZwP31dGZcZay0kc1d4=; b=RbMQLuCUkFg80wjY5Ol7gmnzO2RaEFY/cDgN/TPAQZ0pYkP+Z+JyktLy efBjtIIxB762trJYTmIn0bBDl6uGQa7hR4jVH2m9voamsi8aoEgbdyYon F9FajqlyzSMl2pDD9E5yzYg/xANToMgtBGJ+4QWVKGZDToqO7mAHYqnhi XY7gSZ0wolPdDzWrsD8Bjh1ezzJl2dvIz16YYu8/RxIQjc5sVBdUh4otV FpOx0j3g06VBwYW5b5AejMxYKNvyaTcSFfvzNyiIdarUzqmBxAiIwtdWC o7N/ry7VRdDiERxMHW6llCuSA2ZvDU8078pCTQXT6hjcXzbCyXWzdqjOI Q==; X-IronPort-AV: E=Sophos;i="5.13,548,1427713200"; d="scan'208";a="20560397" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Jun 2015 07:18:06 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 4 Jun 2015 07:18:05 +1200 From: Peter Gutmann To: Russ Housley , Eliot Lear Thread-Topic: [saag] feeding in crypto results Thread-Index: AQHQngrHK8nUim7T0kyzzpxciEEvDp2aMBAAgAD3VyU= Date: Wed, 3 Jun 2015 19:18:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB035402@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz>, <9A043F3CF02CD34C8E74AC1594475C73AB034FB8@uxcn10-tdc05.UoA.auckland.ac.nz> <9878910C-AFD9-4C82-8E87-4AE51D1B96BF@vigilsec.com> <556F110A.5020303@cisco.com>, <8913E6ED-1D0E-4A54-915E-E69F94544EC2@vigilsec.com> In-Reply-To: <8913E6ED-1D0E-4A54-915E-E69F94544EC2@vigilsec.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:18:11 -0000 Russ Housley writes:=0A= =0A= For example, devices that are part of health or safety systems often requ= ire=0A= certification before deployment.=0A= =0A= I'd perhaps add as a second example:=0A= =0A= Embedded/SCADA systems, which often have upgrade cycles stretching over m= any=0A= years, have similar issues.=0A= =0A= Peter.=0A= =0A= From nobody Wed Jun 3 12:24:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6B1A1A3E for ; Wed, 3 Jun 2015 12:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yy62N0ckUaW for ; Wed, 3 Jun 2015 12:24:34 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324DF1A1A17 for ; Wed, 3 Jun 2015 12:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1433359474; x=1464895474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CXNeqiFPRRAbgCNmwHQgtz6s3D2npiIeOCNS4hpXxpI=; b=BiQ1BOCihH+saoR4OdE9xq1/wIxeKQ6PBKwp3wA0uZYiAnrYuVQvEGgv lle+lJ/R6iN/ooL/8wJpXz3KN127117q2EdEuWYM3WkWeeX44pibvjWoW Z7KGmM/NIpdMQK7wHhPjjgFx+awrU42FX6hlMaVj32FjuFQJXTA6S6q3L G6IwZUxE+tmhKVVENUwm+HTM3svN4DNu84cltQHP5Qjh/i4jTnDAnPYIw ewyYsOVQtPe3e4/l/SfDIRyLEut9bwYV0RMT9C29Zw/WHXgEunZiHnSC+ RrMnkT41My9e30z/0TrNyiFBHK12ZQxIehLwY7iLlhGZ98hd3RxrhJ1yb g==; X-IronPort-AV: E=Sophos;i="5.13,548,1427713200"; d="scan'208";a="20561094" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Jun 2015 07:24:33 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Thu, 4 Jun 2015 07:24:32 +1200 From: Peter Gutmann To: Paul Hoffman Thread-Topic: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) Thread-Index: AQHQnS0R7Mr16z/wKUiQ9XlevpEVQ52ZMiB9//9mRoCAAP6ycP//V4KAgAGFKvn//5+rAAAi9ip3 Date: Wed, 3 Jun 2015 19:24:32 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB035429@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:24:35 -0000 Paul Hoffman writes:=0A= =0A= >Yes, your proposal would simplify things. It will also make enough wrong= =0A= >statements to make operational security worse, not better, possibly in the= =0A= >first year.=0A= =0A= This isn't an irrevocable, binding vote, merely a poll. At the moment we h= ave=0A= no data on this, just a lot of opinions. If we ran a poll or two, we could= =0A= see... well, I have no idea what we'd see or we wouldn't need a poll for it= .=0A= The point is we would at that point at least have some data. Since it's ju= st=0A= an opinion poll, there's nothing to prevent us from then saying "well, that= =0A= didn't work, all we got was noise" (or, more hopefully, "this gives us some= =0A= useful guidance").=0A= =0A= (Oh, and it's iang's idea, not mine, he should get the credit for it).=0A= =0A= Peter.= From nobody Thu Jun 4 09:33:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D9A1A9097 for ; Thu, 4 Jun 2015 09:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p83Mul8NZnHH for ; Thu, 4 Jun 2015 09:33:46 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B921A9066 for ; Thu, 4 Jun 2015 09:31:38 -0700 (PDT) Received: by wifw1 with SMTP id w1so64722950wif.0 for ; Thu, 04 Jun 2015 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=urlTZePnaryj3oHW2GjnTxJjfErlut9pabmRXk91sRI=; b=W1h//MNvtQ+gJM2x5y54KWrsUAGR+QBjivshFQVdRHpuqf6WUIEGJXHL0EtA+xWc7u Y5kKDxFUlnYLkCv0MlkkL3CEuz35Q51O6KnD+qY02FYwDbz2IpC63iA6oOM+b9Eu1eU4 RRqTelLFbQ4MaqZmLXkau1t+c+FiY/t34RSdT6Gp93r+jsRMvGqYEW01I/9Bo9s2eXMH F5daxyMFoDL7xRFvdaYQH+cKOpNuNNBsLMNgzDNWYvfdgEbre0D7Wx12xtXWGmb1lzzE U0EFJHMZwwKRicNHR48/vR/QWXmXAIhV2aEd5KRgK0Ee50aIPnFsAjqoa0EEjNWhAcFQ A6KA== MIME-Version: 1.0 X-Received: by 10.180.187.203 with SMTP id fu11mr53858143wic.26.1433435497052; Thu, 04 Jun 2015 09:31:37 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 4 Jun 2015 09:31:36 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB035429@uxcn10-tdc05.UoA.auckland.ac.nz> References: <555FA6C5.5000004@cs.tcd.ie> <5560BA33.7000300@iang.org> <9A043F3CF02CD34C8E74AC1594475C73AB02AA5A@uxcn10-tdc05.UoA.auckland.ac.nz> <642EBA7A-5A17-42DC-B4E5-6E0A513840EA@vigilsec.com> <5564D265.4030504@iang.org> <8E113049-2037-404A-B138-37E30819EBD7@vigilsec.com> <556D9CFF.7030803@cs.tcd.ie> <9A043F3CF02CD34C8E74AC1594475C73AB03450B@uxcn10-tdc05.UoA.auckland.ac.nz> <990A1F78-8295-46F5-A719-67E033CBB2E4@vigilsec.com> <9A043F3CF02CD34C8E74AC1594475C73AB034834@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB034F9C@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73AB035429@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Thu, 4 Jun 2015 09:31:36 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a11c267d89c40fc0517b3b546 Archived-At: Cc: Paul Hoffman , IETF SAAG Subject: Re: [saag] feeding in crypto results (was: Re: AD sponsoring draft-iab-crypto-alg-agility) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:33:48 -0000 --001a11c267d89c40fc0517b3b546 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 12:24 PM, Peter Gutmann wrote: > Paul Hoffman writes: > > >Yes, your proposal would simplify things. It will also make enough wrong > >statements to make operational security worse, not better, possibly in the > >first year. > > This isn't an irrevocable, binding vote, merely a poll. At the moment we > have > no data on this, just a lot of opinions. If we ran a poll or two, we could > see... well, I have no idea what we'd see or we wouldn't need a poll for > it. > The point is we would at that point at least have some data. Since it's > just > an opinion poll, there's nothing to prevent us from then saying "well, that > didn't work, all we got was noise" (or, more hopefully, "this gives us some > useful guidance"). > If you take a bunch of blind people, put them together, and take a poll, they don't suddenly develop sight. We're still assuming that the problem is that we didn't "know" that MtE in TLS was insecure. I think it's pretty clear that a good number of people were aware: after all, you wrote the draft that was ultimately adopted to solve the problem, several years afterwards. Would taking a poll have actually helped that situation? It may have helped with RC4. > (Oh, and it's iang's idea, not mine, he should get the credit for it). > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- "Man is born free, but everywhere he is in chains". --Rousseau. --001a11c267d89c40fc0517b3b546 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 12:24 PM, Peter Gutmann <pgut001@cs.auc= kland.ac.nz> wrote:
P= aul Hoffman <= paul.hoffman@vpnc.org> writes:

>Yes, your proposal would simplify things. It will also make enough wron= g
>statements to make operational security worse, not better, possibly in = the
>first year.

This isn't an irrevocable, binding vote, merely a poll.=C2=A0 At= the moment we have
no data on this, just a lot of opinions.=C2=A0 If we ran a poll or two, we = could
see... well, I have no idea what we'd see or we wouldn't need a pol= l for it.
The point is we would at that point at least have some data.=C2=A0 Since it= 's just
an opinion poll, there's nothing to prevent us from then saying "w= ell, that
didn't work, all we got was noise" (or, more hopefully, "this= gives us some
useful guidance").

If you take a b= unch of blind people, put them together, and take a poll, they don't su= ddenly develop sight. We're still assuming that the problem is that we = didn't "know" that MtE in TLS was insecure. I think it's = pretty clear that a good number of people were aware: after all, you wrote = the draft that was ultimately adopted to solve the problem, several years a= fterwards. Would taking a poll have actually helped that situation?

It may have helped with RC4.


(Oh, and it's iang's idea, not mine, he should get the credit for i= t).

Peter.
_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag



--
=
"Man is born free, but everywhere he is in chains".
--Rou= sseau.
--001a11c267d89c40fc0517b3b546-- From nobody Thu Jun 4 12:56:29 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D301A907F; Thu, 4 Jun 2015 12:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtWHPnwmXi2j; Thu, 4 Jun 2015 12:56:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C775C1A0018; Thu, 4 Jun 2015 12:56:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BE31D20098; Thu, 4 Jun 2015 16:10:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8430463AEC; Thu, 4 Jun 2015 15:56:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6ADAF637FE; Thu, 4 Jun 2015 15:56:09 -0400 (EDT) From: Michael Richardson To: saag@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: dane@ietf.org Subject: [saag] HTTPS everywhere question --- donated mirrors X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 19:56:18 -0000 --=-=-= Content-Type: text/plain So you may know I mismanage www.tcpdump.org. We have a half-dozen mirrors of the site (and code) around the world, all of them donated. 100M of disk space or something... Most answer to www.tcpdump.org as a virtual host, some have their own URLs. HTTP based virtual hosting is simple and cheap, and anyone can put up a mirror using rsync, and then I put the A and AAAA records in along with an extra name like www.us.tcpdump.org (hosted by wireshark). Now, www.us.tcpdump.org shares a host with www.wireshark.org, and https://www.wireshark.org also exists, and my impression is that some browsers are now doing things like trying port-443, and if it works, assuming that the same content is there. (No, you can't exactly try, because I pulled that IP from www.tcpdump.org pending resolution) Let's assume that I want to make this true (that www.tcpdump.org is https-everywhere), we need at a minimum, universal SNI or I need to enable this only when there is a unique v6 (because v4 is too scarce) available. Okay, that solves the VirtualHost issue... but it seems that I still have a certificate and private key issue. I could buy certificates for all sites, or... ? is there some technology I've missed? I could go DANE with self-signed certificates, which has some advantage. In theory, one could have a dozen TLSA RR in DNS, and fortunately they won't clog up the apex; but in practice are browsers that support DANE smart enough at this point to search all the records? Going DANE assumes browsers new enough to do SNI, which I guess is good. I wish we had signed HTTP objects instead, so that I could just sign the web site *contents*, and let the content distribution systems do their job, and let me do mine. (hey, the entire http site contents is also on github) Privacy could be machine to machine, while authentication be browser to web site owner... {I'm allowed to dream, aren't I?} I know that we have this issue with SMTP pointing MX records for example.com at ISP mail.example.net, and the names not matching, and I guess we are doing something there. Am I missing some piece of the puzzle? Some contemplated aspect of TLSA which might let me say, "www.wireshark.org is an allowed name for www.tcpdump.org"?? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXCtWYCLcPvd0N1lAQLtpwgAqPmP54Y0BMaNT6e3Kmx5yzDGcIxepr0/ W5tk9CaBUwTaKGPrBGaUbQ7ogLKx8Oz9OItjXfLI7OJArFznytXY6/VMYYjb3cg+ OXWPy00zPcnj9Nm/zoZTyrsRDVAOu5PSYjuJz7bl7xApyXIZSRwCgUe/18aGhZps 00RpZtMkxQ8GXW/PsgkVyOz9EmOLONGI3YVeugImY/VbOEnx3yJrdTntUE2u6SmM JiPdkZ9a+qBdsbSTbbiI0SumHNoyvjhOfb84od0uo8Whsa/vXNbRobo2TKDjSRns Pa2KVEWsT8iUdSKhlSczmX9c0hQaQVMsZZFf/RPHpNZG6/nqFiIWWA== =Fmuh -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 4 15:27:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1801A1A72 for ; Thu, 4 Jun 2015 15:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fikHy6iZuAvR for ; Thu, 4 Jun 2015 15:27:20 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6161A1A4F for ; Thu, 4 Jun 2015 15:27:20 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 74A149A4070 for ; Thu, 4 Jun 2015 18:27:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id r1N8uha1sC7k for ; Thu, 4 Jun 2015 18:25:48 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F0249A4066 for ; Thu, 4 Jun 2015 18:26:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <555FA6C5.5000004@cs.tcd.ie> Date: Thu, 4 Jun 2015 18:26:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E913E68-968E-40D4-A26E-75B4D438E92F@vigilsec.com> References: <555FA6C5.5000004@cs.tcd.ie> To: IETF SAAG X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 22:27:21 -0000 Based on the discussion on this thread, I have made many updates. A new = version (-05) was just posted: = https://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-05.txt The diff from previous version is here: = https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-crypto-alg-agility-05 Thanks for all of the helpful discussion. Russ= From nobody Thu Jun 4 17:01:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4E51ACD86; Thu, 4 Jun 2015 17:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SvxMcwsIfe6; Thu, 4 Jun 2015 17:01:49 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0021ACD82; Thu, 4 Jun 2015 17:01:49 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 894D41E038; Fri, 5 Jun 2015 00:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1433462508; bh=KEvi2FoinE4aPfYSrNsCm8RgdliNO5WOFrHxSldU/1U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D3uO8vC3W6XWanxYfQjiqylpz47pX64PlCS3HhxwonSsj+LLdzwKYmfJHwnvZ6uNO YGiASc3SKjltzaUeaR6Th+W/HtwedYFXsfV8+IPSM/rwqZRx25dJD77uBwOdoQUZct 7TzH3HmMWOvHpIO9jFSFKHFzk9PjGHOs805sadW4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id B4AD8106FD888; Fri, 5 Jun 2015 00:00:38 +0000 (UTC) From: James Cloos To: Michael Richardson In-Reply-To: <15980.1433447769@sandelman.ca> (Michael Richardson's message of "Thu, 04 Jun 2015 15:56:09 -0400") References: <15980.1433447769@sandelman.ca> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 04 Jun 2015 20:00:38 -0400 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150605:mcr+ietf@sandelman.ca::4SBQhbnDpLwY2Jqw:0000000000000000000000000000000000000001t2uU X-Hashcash: 1:28:150605:saag@ietf.org::deOlm4k3lxUsy34j:000BgnuV X-Hashcash: 1:28:150605:dane@ietf.org::Usq0/Kt1SxFmQxoW:000BEvXD Archived-At: Cc: saag@ietf.org, dane@ietf.org Subject: Re: [saag] [dane] HTTPS everywhere question --- donated mirrors X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 00:01:51 -0000 >>>>> "MR" == Michael Richardson writes: MR> We have a half-dozen mirrors of the site (and code) around the world, all of MR> them donated. 100M of disk space or something... MR> Most answer to www.tcpdump.org as a virtual host, some have their own MR> URLs. HTTP based virtual hosting is simple and cheap, and anyone can put up MR> a mirror using rsync, and then I put the A and AAAA records in along with an MR> extra name like www.us.tcpdump.org (hosted by wireshark). MR> Let's assume that I want to make this true (that www.tcpdump.org is MR> https-everywhere), we need at a minimum, universal SNI or I need to enable MR> this only when there is a unique v6 (because v4 is too scarce) available. [Apologies for any typos. I'm in the process of re-learnin how to type; left hand doesn't wok quite right anymore... -JimC] For mirror netwoks like that you need to have each of them get their own certs (or their own names) and have downloads redirect rom the main site to mirrors with something like an http 302. The main site an distribute the redirrecs using things like geoip or (optionally weighted) round robin, or whatever. There really isn't any other secure way to do it. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 8 11:35:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683171B3186; Mon, 8 Jun 2015 11:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRrSbrD0ZLxV; Mon, 8 Jun 2015 11:35:50 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFF21ACCD9; Mon, 8 Jun 2015 11:35:50 -0700 (PDT) Received: by yhak3 with SMTP id k3so39279935yha.2; Mon, 08 Jun 2015 11:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p32g8caXrc1Fsmyoz3rf1YZEj1SaltQR7Q1CFpOsENg=; b=wyV1xbDofxq8BwNRO00z748bNDaYhXlGr4EJSj1uY4P5xITIF6DZISmXwEadWdecMv OUK+mF3CL+y3d+0FLSieit6MXqEBtQgBcm1niIwq90fUHTRYTWS75Ghkj9r6BDlYYvbn QCAsnB1A9h/sH8wZuEUdhYIMFGr4jjWlRbW/2JQj+b2z/u2lcYzO8yL+3kbFE3UnZXZK ocEyyPsOPmgOO5s/YiEKsm+c8tKcezE7M46O+UD7W4XxrQjPh0+tH57qq++h/LztmP0s OlKgDWF3l9OQHCBnN+HOwFv+h3TNRBmRy+ywH3BITK89rvpzGpccf3tffbFBKfYZh9qB f7ag== MIME-Version: 1.0 X-Received: by 10.13.247.3 with SMTP id h3mr18217413ywf.154.1433788549582; Mon, 08 Jun 2015 11:35:49 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 8 Jun 2015 11:35:49 -0700 (PDT) In-Reply-To: <15980.1433447769@sandelman.ca> References: <15980.1433447769@sandelman.ca> Date: Mon, 8 Jun 2015 11:35:49 -0700 Message-ID: From: Martin Thomson To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: saag , dane@ietf.org Subject: Re: [saag] HTTPS everywhere question --- donated mirrors X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 18:35:51 -0000 On 4 June 2015 at 12:56, Michael Richardson wrote: > Am I missing some piece of the puzzle? Some contemplated aspect of TLSA > which might let me say, "www.wireshark.org is an allowed name for > www.tcpdump.org"?? Well... ACME will let wireshark.org get a certificate for tcpdump.org, now that you have setup DNS. If you want them to be able to use your name, then allow them to have a certificate for it. SNI is a problem, but you might decide that IE 6 and Android 2.2 users aren't that important. I know several people running services that rely on SNI alone happily. From nobody Mon Jun 8 12:18:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96DD1B3229; Mon, 8 Jun 2015 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDr1xYuoF49Q; Mon, 8 Jun 2015 12:18:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE571A0105; Mon, 8 Jun 2015 12:18:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A0EED283033; Mon, 8 Jun 2015 19:18:00 +0000 (UTC) Date: Mon, 8 Jun 2015 19:18:00 +0000 From: Viktor Dukhovni To: dane@ietf.org, saag@ietf.org Message-ID: <20150608191800.GK5512@mournblade.imrryr.org> References: <15980.1433447769@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15980.1433447769@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] [dane] HTTPS everywhere question --- donated mirrors X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:18:03 -0000 On Thu, Jun 04, 2015 at 03:56:09PM -0400, Michael Richardson wrote: > Now, www.us.tcpdump.org shares a host with www.wireshark.org, and > https://www.wireshark.org also exists, and my impression is that some > browsers are now doing things like trying port-443, and if it works, > assuming that the same content is there. (No, you can't exactly try, because > I pulled that IP from www.tcpdump.org pending resolution) Assuming that port 443 is semantically identical to port 80 is rather unwise. Are browsers really doing that, or is the host in question configured to publish alternative service access via 443? > In theory, one could have a dozen TLSA RR in DNS, and fortunately they won't > clog up the apex; but in practice are browsers that support DANE smart enough > at this point to search all the records? Going DANE assumes browsers new > enough to do SNI, which I guess is good. There are essentially no browsers that support DANE. There are some experimental plugins, but nothing mainstream anyone should rely on. > Am I missing some piece of the puzzle? Some contemplated aspect of TLSA > which might let me say, "www.wireshark.org is an allowed name for > www.tcpdump.org"? Unfortunately, HTTP does not use SRV records. If HTTP had used SRV records, and if browsers supported DANE, then the DANE SRV draft (approved and in the RFC editor queue) would do precisely what you want, in that each target host's own name from the SRV record would be used for TLSA record lookup and any peername checks. This is not how HTTPS works today. There is no service indirection via DNS for HTTP, so you have to do that at the application layer via an HTTPS redirector (that can somehow guess which servers are up and reachable by the client). -- Viktor. From nobody Wed Jun 10 20:00:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67A1A00E4 for ; Wed, 10 Jun 2015 20:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0nLFCAmqtA1 for ; Wed, 10 Jun 2015 20:00:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0679.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::679]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD591A0084 for ; Wed, 10 Jun 2015 20:00:08 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (25.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (25.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 02:58:44 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) with mapi id 15.01.0184.014; Thu, 11 Jun 2015 02:58:44 +0000 From: Natasha Rooney To: saag Thread-Topic: Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks Thread-Index: AQHQo/KHck3zlci4pkerXqUG3HaIaA== Date: Thu, 11 Jun 2015 02:58:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [222.11.84.241] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(243025005)(66654002)(53754006)(43784003)(450100001)(50986999)(5002640100001)(86362001)(2900100001)(229853001)(36756003)(102836002)(15975445007)(82746002)(122556002)(15395725005)(189998001)(1720100001)(50226001)(2656002)(5001960100002)(107886002)(5890100001)(110136002)(19580395003)(5001920100001)(40100003)(46102003)(218763003)(33656002)(83716003)(57306001)(62966003)(19580405001)(66066001)(77156002)(87936001)(106116001)(92566002)(104396002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <71EA2980DE71584F909D21A2E2E36E34@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 02:58:43.6649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 222.11.84.241 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Subject: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 03:00:12 -0000 Hi all! First time post to this mailing list for me to please excuse any process mi= stakes! I have collected some information on caching in mobile networks (an= d on mobile) for the Ubiquitous Encryption draft. A lot of this information= comes from academic studies and information that some mobile operators are= willing to share. This is not my area of expertise so I am happy to hear a= ny suggestion for changes. Also I would like to say that I support this dra= ft not as a way to mitigate these issues but as one place which shows the e= ffects of ubiquitous encryption for the IETF and the wider community. Many = thanks and let me know if you have any questions! Natasha New suggested content below: 2.1.X. Caching in Mobile Networks Mobile networks operate a centralised architecture; traffic traverses throu= gh a small number of packet-gateways within the Core Network before reachin= g the internet[1]. These centralised architectures have lead mobile network= operators to cache content. Forward caching is used in most cases [4]. Caching tends to occur in the Core Network. In LTE networks caching happens= in the Packet Gateway (PGW) in the Evolved Packet Core (the evolution of t= he Core Network) [1]. Within 3G networks caching can again happen at the PG= W and sometimes more specifically at the GI Interface which connects the GG= SN (Gateway GPRS support node) and the PGW. Web caching can reduce download= bandwidth consumption to around 25% [1] and have a cache hit ratio around = 33%. Cache hit ratios naturally grow as the population increases. Caching can happen at the Radio Access Network but is much less common; cac= hing at this level is harder due to managing handover of users between base= stations, although this technique may be suitable for some video use cases= . Caching in the mobile network both delivers content faster to users and cre= ate savings for mobile operators [5]. Caching at the RAN or on the handset = would be preferred for latency saving [4], but cost savings and ease of dep= loyment, use, and development of Core Network caches have lead to caching w= ithin the core network being more widely used. 2.1.X.1 Caching in Future Evolved Networks Within the next few years a shift away from caching towards CDNs, interconn= ected CDNs and software defined networking is expected. This may offer furt= her methods for moving content closer to the customer and over those bottle= necks in the network. In this case we may find the effects listed here to b= e less drastic and reliance on caching to decrease. 2.1.X.2 Caching Video Video transcoding can often occur at the same time as content caching withi= n the operator network. Some caching systems will request a video asset, di= scover the format and transcode this to a suitable mobile format and cache = before delivering the content to the user [2]. Encrypting video content mea= ns both this caching and transcoding are no longer possible. 2.1.X.3 On-Device Caching Transparent on-device caching caches data from browsers and apps on the dev= ice. This caching method can be configured to cache data specifically to a = particular user, making content retrieval extremely fast by not needing to = traverse any network [6]. Encrypted content cannot be cached by on-device c= ache solutions. [1] http://www.cs.princeton.edu/~sihm/papers/monbot-mobisys13.pdf [2] http://www.rcrwireless.com/20140522/wireless/video-optimization-cache-k= ing-fixed-networks-mobile [3] http://www-personal.umich.edu/~hjx/file/mobisys12_caching.pdf [4] J. Erman, A. Gerber, M. Hajiaghayi, D. Pei, S. Sen, and O. Spatscheck. = To Cache or not to Cache: The 3G case. IEEE Internet Computing, 2011., http= ://www-math.mit.edu/~hajiagha/InternetComputing.pdf [5] http://pennysleuth.com/invest-in-cell-phone-infrastructure-for-growth-i= n-2010/ [6] http://www.mobolize.com/wp/wp-content/uploads/2015/01/Mobile-Endpoint-O= ptimization-Technical-WP.pdf Thanks again! Natasha Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org Tokyo, Japan This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. From nobody Wed Jun 10 21:59:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D722E1A8935 for ; Wed, 10 Jun 2015 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e91B8T7qzYdX for ; Wed, 10 Jun 2015 21:59:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943831A8A39 for ; Wed, 10 Jun 2015 21:59:19 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-d0-557915a5192a Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.F0.17665.5A519755; Thu, 11 Jun 2015 06:59:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Thu, 11 Jun 2015 06:59:01 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Natasha Rooney Thread-Topic: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks Thread-Index: AQHQo/KHck3zlci4pkerXqUG3HaIaJ2mvsQ0 Date: Thu, 11 Jun 2015 04:59:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre5S0cpQg40LVCwazi9lsZjS38nk wOTxtF/eY8mSn0wBTFFcNimpOZllqUX6dglcGU33drAVTNSo+DDzD2sD40uFLkZODgkBE4n5 DbvYIWwxiQv31rN1MXJxCAkcZZRobD3OCuEsZpT4f3AZG0gVm4C3xLQVZ1lBbBEBVYl115ax gNjMAhISV9etBrOFBSIkutesYYeoiZQ49XYlYxcjB5BtJHHpfRlImAWo9VzjHLAxvAL2Eitb lzKB2EIC1hK7pq4EW8UpYCOx691vRhCbUUBW4v73e1CrxCU+z33ABHG0gMSSPeeZIWxRiZeP /7FC1OhJ3Jg6hQ3C1pZYtvA1M8QuQYmTM5+wTGAUnYVk1CwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCUHNzyW3cH4+rXjocYBTgYlXh4F7yuCBViTSwrrsw9xCjN waIkzjtjc16okEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkam+KCji0MvM51xrjt48sPUbXye pmqpnAcOPzZ2/uLpn5Mx8UFURtnNrwtyz5k+e/btEYdhVu7hWJmHLf83cqwXjTrz6tPJO2sy JNp/bZdx2fl3Uk7u8v0fNyyU7Na+bdA8wf2Q3eek5TwJ4gsX/X3++OQG4YwH51Y/ZTrcuPnb Ms1Hztc+l71eosRSnJFoqMVcVJwIAKXbI4JzAgAA Archived-At: Cc: saag Subject: Re: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 04:59:23 -0000 Hi, Perhaps obvious for many but what is the definition of a cache and a CDN or= even more to the point- what is the difference? They both cache... I am sure You have such a text as well, explaining this. Might be good addi= ng it. Best regards G=F6ran Eriksson > 11 jun 2015 kl. 05:00 skrev Natasha Rooney : >=20 > Hi all! >=20 > First time post to this mailing list for me to please excuse any process = mistakes! I have collected some information on caching in mobile networks (= and on mobile) for the Ubiquitous Encryption draft. A lot of this informati= on comes from academic studies and information that some mobile operators a= re willing to share. This is not my area of expertise so I am happy to hear= any suggestion for changes. Also I would like to say that I support this d= raft not as a way to mitigate these issues but as one place which shows the= effects of ubiquitous encryption for the IETF and the wider community. Man= y thanks and let me know if you have any questions! >=20 > Natasha >=20 > New suggested content below: >=20 > 2.1.X. Caching in Mobile Networks >=20 > Mobile networks operate a centralised architecture; traffic traverses thr= ough a small number of packet-gateways within the Core Network before reach= ing the internet[1]. These centralised architectures have lead mobile netwo= rk operators to cache content. Forward caching is used in most cases [4]. >=20 > Caching tends to occur in the Core Network. In LTE networks caching happe= ns in the Packet Gateway (PGW) in the Evolved Packet Core (the evolution of= the Core Network) [1]. Within 3G networks caching can again happen at the = PGW and sometimes more specifically at the GI Interface which connects the = GGSN (Gateway GPRS support node) and the PGW. Web caching can reduce downlo= ad bandwidth consumption to around 25% [1] and have a cache hit ratio aroun= d 33%. Cache hit ratios naturally grow as the population increases. >=20 > Caching can happen at the Radio Access Network but is much less common; c= aching at this level is harder due to managing handover of users between ba= se stations, although this technique may be suitable for some video use cas= es. >=20 > Caching in the mobile network both delivers content faster to users and c= reate savings for mobile operators [5]. Caching at the RAN or on the handse= t would be preferred for latency saving [4], but cost savings and ease of d= eployment, use, and development of Core Network caches have lead to caching= within the core network being more widely used. >=20 > 2.1.X.1 Caching in Future Evolved Networks >=20 > Within the next few years a shift away from caching towards CDNs, interco= nnected CDNs and software defined networking is expected. This may offer fu= rther methods for moving content closer to the customer and over those bott= lenecks in the network. In this case we may find the effects listed here to= be less drastic and reliance on caching to decrease. >=20 > 2.1.X.2 Caching Video >=20 > Video transcoding can often occur at the same time as content caching wit= hin the operator network. Some caching systems will request a video asset, = discover the format and transcode this to a suitable mobile format and cach= e before delivering the content to the user [2]. Encrypting video content m= eans both this caching and transcoding are no longer possible. >=20 > 2.1.X.3 On-Device Caching >=20 > Transparent on-device caching caches data from browsers and apps on the d= evice. This caching method can be configured to cache data specifically to = a particular user, making content retrieval extremely fast by not needing t= o traverse any network [6]. Encrypted content cannot be cached by on-device= cache solutions. >=20 > [1] http://www.cs.princeton.edu/~sihm/papers/monbot-mobisys13.pdf > [2] http://www.rcrwireless.com/20140522/wireless/video-optimization-cache= -king-fixed-networks-mobile > [3] http://www-personal.umich.edu/~hjx/file/mobisys12_caching.pdf > [4] J. Erman, A. Gerber, M. Hajiaghayi, D. Pei, S. Sen, and O. Spatscheck= . To Cache or not to Cache: The 3G case. IEEE Internet Computing, 2011., ht= tp://www-math.mit.edu/~hajiagha/InternetComputing.pdf > [5] http://pennysleuth.com/invest-in-cell-phone-infrastructure-for-growth= -in-2010/ > [6] http://www.mobolize.com/wp/wp-content/uploads/2015/01/Mobile-Endpoint= -Optimization-Technical-WP.pdf >=20 > Thanks again! >=20 > Natasha >=20 >=20 > Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 773= 0 219 765 | @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan >=20 >=20 > This email and its attachments are intended for the above named only and = may be confidential. If they have come to you in error you must take no act= ion based on them, nor must you copy or show them to anyone; please reply t= o this email or call +44 207 356 0600 and highlight the error. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Jun 11 03:14:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4D1B2E62 for ; Thu, 11 Jun 2015 03:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkmXKv3CkWPO for ; Thu, 11 Jun 2015 03:14:00 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3E71B2E61 for ; Thu, 11 Jun 2015 03:14:00 -0700 (PDT) Received: (qmail 39445 invoked from network); 11 Jun 2015 10:14:08 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jun 2015 10:14:08 -0000 Date: 11 Jun 2015 09:43:10 -0000 Message-ID: <20150611094310.9483.qmail@ary.lan> From: "John Levine" To: saag@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:14:01 -0000 In article you write: >Hi, > >Perhaps obvious for many but what is the definition of a cache and a CDN or even >more to the point- what is the difference? They both cache... Seems to me the useful difference is that a CDN is under the control of the entity providing the material, while caches are under control of the end user or an intermediary. CDNs and end user caches seem benign, intermediary caches less so. R's, John From nobody Thu Jun 11 03:18:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E752B1ACE4D for ; Thu, 11 Jun 2015 03:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3jP2ZRA9OsA for ; Thu, 11 Jun 2015 03:18:35 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0695.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB441ACE1B for ; Thu, 11 Jun 2015 03:18:34 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (25.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (25.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 10:18:28 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) with mapi id 15.01.0184.014; Thu, 11 Jun 2015 10:18:28 +0000 From: Natasha Rooney To: =?Windows-1252?Q?G=F6ran_Eriksson_AP?= Thread-Topic: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks Thread-Index: AQHQpANgNxmfqWFDKU632xSLLfLLRZ2nF+MA Date: Thu, 11 Jun 2015 10:18:28 +0000 Message-ID: <8766ADBC-68A4-4BDB-BB9C-DD9B01CD3AD9@gsma.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [203.136.247.121] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(243025005)(24454002)(377454003)(51704005)(66654002)(43784003)(53754006)(19580395003)(15395725005)(102836002)(87936001)(76176999)(218763003)(1720100001)(86362001)(46102003)(15975445007)(122556002)(50226001)(50986999)(2950100001)(66066001)(2656002)(57306001)(19580405001)(40100003)(77156002)(62966003)(92566002)(106116001)(110136002)(5001920100001)(5001960100002)(36756003)(5002640100001)(2900100001)(189998001)(33656002)(83716003)(82746002)(5890100001)(104396002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 10:18:28.3850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 203.136.247.121 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Cc: saag Subject: Re: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:18:38 -0000 Thanks for this G=F6ran! The difference is CDNs tend to have permission from the content provider, u= sually its a service the content provider has purchased from the CDN provid= er. Operator caches tend to be transparent, they do it if you like it or no= t! So maybe=85 "Caching in this case refers to transparent caching where content providers= have no control on whether or for what duration something is being cached"= . I wonder, however, whether these caches do obey cache headers, which is som= ething I don=92t know. Can anyone on the list confirm if these caches obey = caching headers (one hopes they do!). Thanks! Natasha Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 = 219 765 | @thisNatasha | Skype: nrooney@gsm.org Tokyo, Japan > On Jun 11, 2015, at 1:59 PM, G=F6ran Eriksson AP wrote: > > Hi, > > Perhaps obvious for many but what is the definition of a cache and a CDN = or even more to the point- what is the difference? They both cache... > > I am sure You have such a text as well, explaining this. Might be good ad= ding it. > > Best regards > G=F6ran Eriksson > > > >> 11 jun 2015 kl. 05:00 skrev Natasha Rooney : >> >> Hi all! >> >> First time post to this mailing list for me to please excuse any process= mistakes! I have collected some information on caching in mobile networks = (and on mobile) for the Ubiquitous Encryption draft. A lot of this informat= ion comes from academic studies and information that some mobile operators = are willing to share. This is not my area of expertise so I am happy to hea= r any suggestion for changes. Also I would like to say that I support this = draft not as a way to mitigate these issues but as one place which shows th= e effects of ubiquitous encryption for the IETF and the wider community. Ma= ny thanks and let me know if you have any questions! >> >> Natasha >> >> New suggested content below: >> >> 2.1.X. Caching in Mobile Networks >> >> Mobile networks operate a centralised architecture; traffic traverses th= rough a small number of packet-gateways within the Core Network before reac= hing the internet[1]. These centralised architectures have lead mobile netw= ork operators to cache content. Forward caching is used in most cases [4]. >> >> Caching tends to occur in the Core Network. In LTE networks caching happ= ens in the Packet Gateway (PGW) in the Evolved Packet Core (the evolution o= f the Core Network) [1]. Within 3G networks caching can again happen at the= PGW and sometimes more specifically at the GI Interface which connects the= GGSN (Gateway GPRS support node) and the PGW. Web caching can reduce downl= oad bandwidth consumption to around 25% [1] and have a cache hit ratio arou= nd 33%. Cache hit ratios naturally grow as the population increases. >> >> Caching can happen at the Radio Access Network but is much less common; = caching at this level is harder due to managing handover of users between b= ase stations, although this technique may be suitable for some video use ca= ses. >> >> Caching in the mobile network both delivers content faster to users and = create savings for mobile operators [5]. Caching at the RAN or on the hands= et would be preferred for latency saving [4], but cost savings and ease of = deployment, use, and development of Core Network caches have lead to cachin= g within the core network being more widely used. >> >> 2.1.X.1 Caching in Future Evolved Networks >> >> Within the next few years a shift away from caching towards CDNs, interc= onnected CDNs and software defined networking is expected. This may offer f= urther methods for moving content closer to the customer and over those bot= tlenecks in the network. In this case we may find the effects listed here t= o be less drastic and reliance on caching to decrease. >> >> 2.1.X.2 Caching Video >> >> Video transcoding can often occur at the same time as content caching wi= thin the operator network. Some caching systems will request a video asset,= discover the format and transcode this to a suitable mobile format and cac= he before delivering the content to the user [2]. Encrypting video content = means both this caching and transcoding are no longer possible. >> >> 2.1.X.3 On-Device Caching >> >> Transparent on-device caching caches data from browsers and apps on the = device. This caching method can be configured to cache data specifically to= a particular user, making content retrieval extremely fast by not needing = to traverse any network [6]. Encrypted content cannot be cached by on-devic= e cache solutions. >> >> [1] http://www.cs.princeton.edu/~sihm/papers/monbot-mobisys13.pdf >> [2] http://www.rcrwireless.com/20140522/wireless/video-optimization-cach= e-king-fixed-networks-mobile >> [3] http://www-personal.umich.edu/~hjx/file/mobisys12_caching.pdf >> [4] J. Erman, A. Gerber, M. Hajiaghayi, D. Pei, S. Sen, and O. Spatschec= k. To Cache or not to Cache: The 3G case. IEEE Internet Computing, 2011., h= ttp://www-math.mit.edu/~hajiagha/InternetComputing.pdf >> [5] http://pennysleuth.com/invest-in-cell-phone-infrastructure-for-growt= h-in-2010/ >> [6] http://www.mobolize.com/wp/wp-content/uploads/2015/01/Mobile-Endpoin= t-Optimization-Technical-WP.pdf >> >> Thanks again! >> >> Natasha >> >> >> Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 77= 30 219 765 | @thisNatasha | Skype: nrooney@gsm.org >> Tokyo, Japan >> >> >> This email and its attachments are intended for the above named only and= may be confidential. If they have come to you in error you must take no ac= tion based on them, nor must you copy or show them to anyone; please reply = to this email or call +44 207 356 0600 and highlight the error. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. From nobody Thu Jun 11 03:21:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A281B2EBA for ; Thu, 11 Jun 2015 03:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_7laaDF9JLd for ; Thu, 11 Jun 2015 03:21:02 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0668.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::668]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D3E1B2EAF for ; Thu, 11 Jun 2015 03:21:01 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (25.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (25.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 10:19:23 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([25.162.26.142]) with mapi id 15.01.0184.014; Thu, 11 Jun 2015 10:19:23 +0000 From: Natasha Rooney To: John Levine Thread-Topic: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks Thread-Index: AQHQpANgNxmfqWFDKU632xSLLfLLRZ2nDgcAgAAKHQA= Date: Thu, 11 Jun 2015 10:19:23 +0000 Message-ID: <9E0FBC0B-EED7-48E8-B265-5DAAE971398F@gsma.com> References: <20150611094310.9483.qmail@ary.lan> In-Reply-To: <20150611094310.9483.qmail@ary.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: taugh.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [203.136.247.121] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(377454003)(19580395003)(102836002)(87936001)(76176999)(218763003)(86362001)(16236675004)(46102003)(122556002)(50226001)(50986999)(2950100001)(66066001)(2656002)(57306001)(19580405001)(40100003)(77156002)(62966003)(92566002)(106116001)(110136002)(5001920100001)(5001960100002)(36756003)(5002640100001)(2900100001)(189998001)(33656002)(83716003)(82746002)(5890100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_9E0FBC0BEED748E8B2655DAAE971398Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 10:19:23.2289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 203.136.247.121 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Cc: saag Subject: Re: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:21:04 -0000 --_000_9E0FBC0BEED748E8B2655DAAE971398Fgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jun 11, 2015, at 6:43 PM, John Levine > wrote: Seems to me the useful difference is that a CDN is under the control of the entity providing the material, while caches are under control of the end user or an intermediary. Oh I like this sentence better than mine! This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_9E0FBC0BEED748E8B2655DAAE971398Fgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <27A0208AFCD9E147B713C7FFF72131A3@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

On Jun 11, 2015, at 6:43 PM, John Levine <johnl@taugh.com> wrote:

Seems to me the useful difference is that a CDN is under the control
of the entity providing the material, while caches are under control of the end user or an intermediary.

Oh I like this sentence better than mine!

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_9E0FBC0BEED748E8B2655DAAE971398Fgsmacom_-- From nobody Thu Jun 11 03:30:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529661B2F00 for ; Thu, 11 Jun 2015 03:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA30U561-OUG for ; Thu, 11 Jun 2015 03:30:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6511B2F01 for ; Thu, 11 Jun 2015 03:30:36 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-45-5579634b920f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.70.17665.B4369755; Thu, 11 Jun 2015 12:30:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Thu, 11 Jun 2015 12:30:34 +0200 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Natasha Rooney , John Levine Thread-Topic: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks Thread-Index: AQHQpDBWzS70fDGOtkmDwm2hOOLs+Z2nGusA Date: Thu, 11 Jun 2015 10:30:34 +0000 Message-ID: References: <20150611094310.9483.qmail@ary.lan> <9E0FBC0B-EED7-48E8-B265-5DAAE971398F@gsma.com> In-Reply-To: <9E0FBC0B-EED7-48E8-B265-5DAAE971398F@gsma.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.1.150515 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <4CF7CFCFF8DFAF4BB7143E61687410FA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvra53cmWowZTDghane9YwWTScX8pi MaW/k8mB2eNpv7zHkiU/mTzubQkNYI7isklJzcksSy3St0vgytj0MrCgg6fi7PWTbA2MD7i7 GDk5JARMJFonzWWGsMUkLtxbz9bFyMUhJHCUUWLpu21QzmJGiRuHN4NVsQl4S7S1HGbpYuTg EBFwkdj7Xx4kzCwgIXF13WoWEFtYIELi08EmJhBbRCBS4v7DzewQtpHEhamTGEFsFgFViQPP ZoDV8wpYS5zZup0dZKSQQKJE854QkDCngI3EgxOTwbYyCshK3P9+jwVilbjErSfzmSBuFpBY suc81P2iEi8f/2MFsUUF9CSmX9wGFVeSaFzyhBVkPLOApsT6XfoQY6wltp46zgphK0pM6X7I DnGNoMTJmU9YJjBKzEKybRZC9ywk3bOQdM9C0r2AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5e askmRmA8HtzyW3cH4+rXjocYBTgYlXh4F7yuCBViTSwrrsw9xCjNwaIkzjtjc16okEB6Yklq dmpqQWpRfFFpTmrxIUYmDk6pBsZasb66RE75/W/kQni7JncxTu3R+lOx4dxKXqaCmz5yp+6F xd3fb36VX8nVZv81xlOt+/5021e0HmGecLm49YOJfjaL/ZVgCaNX2ad9VzLdSy94KrtUfqLj Pa6pKS7rPt1yu1FstEUp3UZhZeCem8d+VGlMPmmZIfbqSejCVyEWyzz+GxUYaiuxFGckGmox FxUnAgCBZRVxqAIAAA== Archived-At: Cc: saag Subject: Re: [saag] Effects of Ubiquitous Encryption Draft: Caching in Mobile Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:30:46 -0000 DQoNCj4NCj4NCj4NCj5PbiBKdW4gMTEsIDIwMTUsIGF0IDY6NDMgUE0sIEpvaG4gTGV2aW5lIDxq b2hubEB0YXVnaC5jb20+IHdyb3RlOg0KPg0KPlNlZW1zDQo+IHRvIG1lIHRoZSB1c2VmdWwgZGlm ZmVyZW5jZSBpcyB0aGF0IGEgQ0ROIGlzIHVuZGVyIHRoZSBjb250cm9sDQo+b2YNCj4gdGhlIGVu dGl0eSBwcm92aWRpbmcgdGhlIG1hdGVyaWFsLCB3aGlsZSBjYWNoZXMgYXJlIHVuZGVyIGNvbnRy b2wNCj5vZg0KPiB0aGUgZW5kIHVzZXIgb3IgYW4gaW50ZXJtZWRpYXJ5Lg0KPg0KPg0KPg0KPg0K Pk9oIEkgbGlrZSB0aGlzIHNlbnRlbmNlIGJldHRlciB0aGFuIG1pbmUhDQoNCuKAnENvbnRyb2zi gJ0gaXMga2luZCBvZiB2YWd1ZS4gSW4gTmF0YXNoYeKAmXMgcmVzcG9uc2UsIHRoZSB3b3JkIOKA nHB1cmNoYXNlZOKAnQ0Kd2FzIHVzZWQuIFRoYXQgcG9pbnRzIGF0IHRoZXJlIGJlaW5nIGEgYnVz aW5lc3MgYWdyZWVtZW50IGluY2x1ZGluZyBhDQpjb250cmFjdC4gVGhlIGNvbnRyYWN0IGlzIGlt cG9ydGFudCBJIHRoaW5rIHNpbmNlIHRoYXQgY29udHJhY3QgY2FuIGFsc28NCmNvdmVyIHdoYXQg dGhlIENETiBtYXkgZG8gd2l0aCBrbm93bGVkZ2UgYWJvdXQgdGhlIGVuZC11c2VyIChpbmRpdmlk dWFsIG9yDQplbnRlcnByaXNlIHVzZXIpIGl0IGFjcXVpcmVzIGJ5IG9wZXJhdGluZyB0aGUgQ0RO LCBhcyB3ZWxsIGFzIGFjdGlvbnMNCnJlcXVpcmVkIHRvIHNhZmVndWFyZCB0aGF0IGRhdGEuDQoN ClRoaXMgaXMgdG9vIG1hbnkgd29yZHMgb2YgY291cnNlIGJ1dCBJIHRoaW5rIGNvbnRyb2wgaXMg bm90IHByZWNpc2UgZW5vdWdoLg0KDQo+DQo+VGhpcw0KPiBlbWFpbCBhbmQgaXRzIGF0dGFjaG1l bnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heQ0KPmJlIGNv bmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRh a2Ugbm8NCj5hY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0 aGVtIHRvIGFueW9uZTsgcGxlYXNlDQo+cmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAy MDcgMzU2IDA2MDANCj4gYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIA0KDQo= From nobody Thu Jun 18 00:58:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF711ACD50 for ; Thu, 18 Jun 2015 00:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhxxnsM6pnla for ; Thu, 18 Jun 2015 00:58:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0692.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::692]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6914B1A8A09 for ; Thu, 18 Jun 2015 00:58:29 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1034.eurprd04.prod.outlook.com (10.162.26.143) with Microsoft SMTP Server (TLS) id 15.1.190.14; Thu, 18 Jun 2015 07:58:07 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0190.013; Thu, 18 Jun 2015 07:58:07 +0000 From: Natasha Rooney To: "saag@ietf.org" Thread-Topic: Ubiquitous Encryption: content filtering Thread-Index: AQHQqZyDVZfM/qjQ1ki7JjpGF/YhdA== Date: Thu, 18 Jun 2015 07:58:07 +0000 Message-ID: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.113.199.38] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1034; 3:fvgcc6xSVoMkzJ2SNgV/sVxjtBrOuXOv/niIUdTzDW4GVghUV8ZU3vl3gml05LQJ0hBReHHMtkrWwKAv8haHsb44dDNXMJYhUiZGSrdVg3HZNG2+TBkiD1RueLSdnsKzd2A3lGWvMSgoo1wDhQMnCQ==; 10:7G60UjvDf/xTnX8j4rvOp3nsSLkUCDNAcquBhhIZhy518dBqoE9+WBJzwQo2/uvbwJvYRai1x5rmXYdNUbH7ua+4MsLC7VBb7lNK2qxvo3Y=; 6:+zdYyJTwjxuv2nXFDVZMLV/u+GQJirWq6TVUOzHOlYnozr70EiCG6qgExM0H7R9l x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1034; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:HE1PR04MB1034; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1034; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(52314003)(52044002)(53754006)(19580395003)(19580405001)(50226001)(2501003)(5890100001)(102836002)(87936001)(2351001)(86362001)(229853001)(106116001)(77096005)(450100001)(77156002)(62966003)(40100003)(2900100001)(33656002)(46102003)(16236675004)(92566002)(82746002)(83716003)(2656002)(122556002)(50986999)(66066001)(57306001)(189998001)(36756003)(5002640100001)(5001960100002)(107886002)(110136002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1034; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_99DC814A2B7D4802A1C7399E77F37BD7gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2015 07:58:07.3423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1034 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 131.113.199.38 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1034.eurprd04.prod.outlook.com Archived-At: Subject: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 07:58:33 -0000 --_000_99DC814A2B7D4802A1C7399E77F37BD7gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgYSBuZXcgc3VibWlzc2lvbiBmb3IgdGhlIFViaXF1aXRvdXMgRW5j cnlwdGlvbiBkcmFmdC4gSSBtdXN0IGFkbWl0LCB0aGlzIG9uZSBpcyBhIGxpdHRsZSBjb250cm92 ZXJzaWFsLCBhbmQgY2VydGFpbmx5IGlzIG5vdCBzb21ldGhpbmcgSSBiZWxpZXZlIGluLiBIb3dl dmVyLCBJIGhhZCBhIGdvb2QgdGhpbmsgYWJvdXQgaXQsIGFuZCBmaWd1cmVkIHRoYXQgdGhpcyBp cyBhbiAiZWZmZWN0IiBvZiB1YmlxdWl0b3VzIGVuY3J5cHRpb24sIGFuZCBtYXliZSB3b3VsZCBi ZSBiZW5lZmljaWFsIGZvciB0aGUgZHJhZnQuIEkgYW0gbm90IGV4cGVjdGluZyBhbnl0aGluZyBj b21lcyBvdXQgb2YgYWRkaW5nIGl0IHBhc3QgZWR1Y2F0aW9uIGZvciBtZW1iZXJzIG9mIHRoZSBJ RVRGIGNvbW11bml0eSB0aGF0IHRoaXMgaXMgYW4gaXNzdWUgZm9yIHNvbWUgb3JnYW5pc2F0aW9u cywgZ292ZXJubWVudHMgYW5kIG1heWJlIHVzZXJzLiBQbGVhc2UgZmVlbCBmcmVlIHRvIHR3ZWV0 IG1lIGlmIHlvdSB3YW50IHRvIGRpc2N1c3MgcGVyc29uYWwgdmlld3MhIEFueXdheSwgaGVyZSB3 ZSBnbzoNCg0KDQoyLjMuWCBDb250ZW50IEZpbHRlcmluZw0KTGF3IGFnZW5jaWVzIG1heSByZXF1 ZXN0IFNlcnZpY2UgUHJvdmlkZXJzIHRvIGJsb2NrIGFjY2VzcyB0byBwYXJ0aWN1bGFyIHNpdGVz IHN1Y2ggYXMgb25saW5lIGJldHRpbmcgYW5kIGdhbWJsaW5nLCBzaXRlcyBwcm9tb3RpbmcgYW5v cmV4aWEsIG9yIGFjY2VzcyB0byBkYXRpbmcgc2l0ZXMuIENvbnRlbnQgZmlsdGVyaW5nIGluIHRo ZSBtb2JpbGUgbmV0d29yayB1c3VhbGx5IG9jY3VycyBpbiB0aGUgY29yZSBuZXR3b3JrLiBBIHBy b3h5IGlzIGluc3RhbGxlZCB3aGljaCBhbmFseXNlcyB0aGUgdHJhbnNwb3J0IG1ldGFkYXRhIG9m IHRoZSBjb250ZW50IHVzZXJzIGFyZSB2aWV3aW5nIGFuZCBlaXRoZXIgZmlsdGVycyBjb250ZW50 IGJhc2VkIG9uIGEgYmxhY2tsaXN0IG9mIHNpdGVzIG9yIGJhc2VkIG9uIHRoZSB1c2Vy4oCZcyBw cmUtZGVmaW5lZCBwcm9maWxlIChlLmcuIGZvciBhZ2Ugc2Vuc2l0aXZlIGNvbnRlbnQpLiBBbHRo b3VnaCBmaWx0ZXJpbmcgY2FuIGJlIGRvbmUgYnkgbWFueSBtZXRob2RzIG9uZSBjb21tb24gbWV0 aG9kIG9jY3VycyB3aGVuIGEgRE5TIGxvb2t1cCByZXZlYWxzIGEgVVJMIHdoaWNoIGFwcGVhcnMg b24gYSBnb3Zlcm5tZW50IG9yIHJlY29nbmlzZWQgYmxvY2stbGlzdC4gVGhlIHN1YnNlcXVlbnQg cmVxdWVzdHMgdG8gdGhhdCBkb21haW4gd2lsbCBiZSByZS1yb3V0ZWQgdG8gYSBwcm94eSB3aGlj aCBjaGVja3Mgd2hldGhlciB0aGUgZnVsbCB1cmwgbWF0Y2hlcyBhIGJsb2NrZWQgdXJsIG9uIHRo ZSBsaXN0LCBhbmQgd2lsbCByZXR1cm4gYSA0MDQgaWYgYSBtYXRjaCBpcyBmb3VuZC4gQWxsIG90 aGVyIHJlcXVlc3RzIHNob3VsZCBjb21wbGV0ZS4NCg0KRXZlbiBpbiBlbmNyeXB0ZWQgY29ubmVj dGlvbnMgdHJhbnNwb3J0IGFuZCBsb3dlciBsYXllciBtZXRhZGF0YSBpcyBhYmxlIHRvIGJlIHZp ZXdlZCBzbyBmb3IgbWFueSBzeXN0ZW1zIGNvbnRlbnQgZmlsdGVyaW5nIHNob3VsZCBiZSBhYmxl IHRvIGNvbnRpbnVlLiBDYXNlcyB3aGVuIHRoZXkgbWF5IG5vdCB3b3JrIGlzIHdoZW4gVExTIHBy b3hpZXMgYXJlIGJlaW5nIHVzZWQgd2hpY2ggb2JzY3VyZSBtZXRhZGF0YSB3aXRoIHRoZSBwcm94 eSBtZXRhZGF0YSwgYW5kIGZ1dHVyZSB2ZXJzaW9ucyBpbiBIVFRQIGFuZCBUQ1AgbWF5IGVuY3J5 cHQgbWV0YWRhdGEgYWdhaW4gc3RvcHBpbmcgY29udGVudCBmaWx0ZXJpbmcgc29mdHdhcmUgZnJv bSB3b3JraW5nICh0aGlzIGlzIGN1cnJlbnRseSBub3QgdGhlIGNhc2UgYW5kIGhhcyBub3QgYmVl biBzdGFuZGFyZGlzZWQpLg0KDQpTb21lIHNpdGVzIGludm9sdmUgYSBtaXh0dXJlIG9mIHVuaXZl cnNhbCBhbmQgYWdlLXNlbnNpdGl2ZSBjb250ZW50IGFuZCBmaWx0ZXJpbmcgc29mdHdhcmUgaW4g dGhlc2UgY2FzZXMgbWF5IHVzZSBtb3JlIGdyYW51bGFyIChhcHBsaWNhdGlvbiBsYXllcikgbWV0 YWRhdGEgdG8gYW5hbHlzZSBhbmQgYmxvY2s7IHRoaXMgd2lsbCBub3Qgd29yayBvbiBlbmNyeXB0 ZWQgY29udGVudC4NCg0KDQpJIGRvIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGFib3V0IHdoYXQgSSBo YXZlIHdyaXR0ZW4sIG1heWJlIHNvbWVvbmUgY2FuIGFuc3dlcjoNClsxXSBEb2VzIEhUVFAyIG11 bHRpcGxleGluZyBkbyBhbnl0aGluZyB0byBjb250ZW50IGZpbHRlcmluZyBzb2Z0d2FyZSwgaS5l LiB3aGVuIHNlbmRpbmcgbXVsdGlwbGUgcmVxdWVzdHMgZm9yIG9uZSB3ZWJwYWdlIChsb2FkaW5n IGltYWdlcyBpbiBwYXJ0aWN1bGFyKS4gSSBkb27igJl0IHRoaW5rIGl0IGRvZXMgaXTigJlzIGp1 c3QgdGhhdCBteSBicmFpbiBpc27igJl0IHdvcmtpbmcgdGhpcyBhZnRlcm5vb24uLi4NClsyXSBJ cyBpdCBmYWlyIHRvIG1lbnRpb24gZnV0dXJlIHZlcnNpb25zIG9mIEhUVFAgYW5kIFRDUCB3aGVu IG5vdGhpbmcgaGFzIGJlZW4gc3RhbmRhcmRpc2VkIHlldD8gSSBkb27igJl0IHRoaW5rIHNvIGlu IHdoaWNoIGNhc2UgbWF5YmUgdGhpcyBzaG91bGQgYmUgcmVtb3ZlZC4NCg0KSG9wZSB0aGlzIGRp ZG7igJl0IHJ1aW4gZXZlcnlvbmVzIG1vcm5pbmchIFRoYW5rcyENCg0KTmF0YXNoYQ0KDQoNCk5h dGFzaGEgUm9vbmV5IHwgV2ViIFRlY2hub2xvZ2lzdCB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29t PG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAoMCkgNzczMCAyMTkgNzY1IHwgQHRoaXNO YXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxtYWlsdG86bnJvb25leUBnc20ub3JnPg0K VG9reW8sIEphcGFuDQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGlu dGVuZGVkIGZvciB0aGUgYWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4g SWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9u IGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7 IHBsZWFzZSByZXBseSB0byB0aGlzIGVtYWlsIG9yIGNhbGwgKzQ0IDIwNyAzNTYgMDYwMCBhbmQg aGlnaGxpZ2h0IHRoZSBlcnJvci4NCg== --_000_99DC814A2B7D4802A1C7399E77F37BD7gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <2671D317A5AF874197323383C859DFC0@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsLA0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBoYXZlIGEgbmV3IHN1Ym1p c3Npb24gZm9yIHRoZSBVYmlxdWl0b3VzIEVuY3J5cHRpb24gZHJhZnQuIEkgbXVzdCBhZG1pdCwg dGhpcyBvbmUgaXMgYSBsaXR0bGUgY29udHJvdmVyc2lhbCwgYW5kIGNlcnRhaW5seSBpcyBub3Qg c29tZXRoaW5nIEkgYmVsaWV2ZSBpbi4gSG93ZXZlciwgSSBoYWQgYSBnb29kIHRoaW5rIGFib3V0 IGl0LCBhbmQgZmlndXJlZCB0aGF0IHRoaXMgaXMgYW4gJnF1b3Q7ZWZmZWN0JnF1b3Q7IG9mIHVi aXF1aXRvdXMNCiBlbmNyeXB0aW9uLCBhbmQgbWF5YmUgd291bGQgYmUgYmVuZWZpY2lhbCBmb3Ig dGhlIGRyYWZ0LiBJIGFtIG5vdCBleHBlY3RpbmcgYW55dGhpbmcgY29tZXMgb3V0IG9mIGFkZGlu ZyBpdCBwYXN0IGVkdWNhdGlvbiBmb3IgbWVtYmVycyBvZiB0aGUgSUVURiBjb21tdW5pdHkgdGhh dCB0aGlzIGlzIGFuIGlzc3VlIGZvciBzb21lIG9yZ2FuaXNhdGlvbnMsIGdvdmVybm1lbnRzIGFu ZCBtYXliZSB1c2Vycy4gUGxlYXNlIGZlZWwgZnJlZSB0byB0d2VldA0KIG1lIGlmIHlvdSB3YW50 IHRvIGRpc2N1c3MgcGVyc29uYWwgdmlld3MhIEFueXdheSwgaGVyZSB3ZSBnbzo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBpZD0iZG9jcy1pbnRlcm5hbC1ndWlk LWM4ZmFkNmZkLTA1YTMtMDQwMy04NGQxLTU4OTBlOTkyNmFiYiIgY2xhc3M9IiI+PGZvbnQgZmFj ZT0iQ29uc29sYXMiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMzg7IG1h cmdpbi10b3A6IDBwdDsgbWFyZ2luLWJvdHRvbTogMHB0OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTMuMzMzMzMzMzMzMzMzMzMycHg7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGlu ZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyIgY2xhc3M9IiI+Mi4zLlggQ29udGVudCBGaWx0ZXJp bmc8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogMS4zODsgbWFyZ2luLXRv cDogMHB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMy4zMzMzMzMzMzMzMzMzMzJweDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0 ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj5MYXcgYWdlbmNpZXMgbWF5IHJlcXVlc3QgU2Vy dmljZSBQcm92aWRlcnMgdG8gYmxvY2sgYWNjZXNzIHRvIHBhcnRpY3VsYXIgc2l0ZXMNCiBzdWNo IGFzIG9ubGluZSBiZXR0aW5nIGFuZCBnYW1ibGluZywgc2l0ZXMgcHJvbW90aW5nIGFub3JleGlh LCBvciBhY2Nlc3MgdG8gZGF0aW5nIHNpdGVzLiBDb250ZW50IGZpbHRlcmluZyBpbiB0aGUgbW9i aWxlIG5ldHdvcmsgdXN1YWxseSBvY2N1cnMgaW4gdGhlIGNvcmUgbmV0d29yay4gQSBwcm94eSBp cyBpbnN0YWxsZWQgd2hpY2ggYW5hbHlzZXMgdGhlIHRyYW5zcG9ydCBtZXRhZGF0YSBvZiB0aGUg Y29udGVudCB1c2VycyBhcmUgdmlld2luZw0KIGFuZCBlaXRoZXIgZmlsdGVycyBjb250ZW50IGJh c2VkIG9uIGEgYmxhY2tsaXN0IG9mIHNpdGVzIG9yIGJhc2VkIG9uIHRoZSB1c2Vy4oCZcyBwcmUt ZGVmaW5lZCBwcm9maWxlIChlLmcuIGZvciBhZ2Ugc2Vuc2l0aXZlIGNvbnRlbnQpLiBBbHRob3Vn aCBmaWx0ZXJpbmcgY2FuIGJlIGRvbmUgYnkgbWFueSBtZXRob2RzIG9uZSBjb21tb24gbWV0aG9k IG9jY3VycyB3aGVuIGEgRE5TIGxvb2t1cCByZXZlYWxzIGEgVVJMIHdoaWNoIGFwcGVhcnMgb24g YQ0KIGdvdmVybm1lbnQgb3IgcmVjb2duaXNlZCBibG9jay1saXN0LiBUaGUgc3Vic2VxdWVudCBy ZXF1ZXN0cyB0byB0aGF0IGRvbWFpbiB3aWxsIGJlIHJlLXJvdXRlZCB0byBhIHByb3h5IHdoaWNo IGNoZWNrcyB3aGV0aGVyIHRoZSBmdWxsIHVybCBtYXRjaGVzIGEgYmxvY2tlZCB1cmwgb24gdGhl IGxpc3QsIGFuZCB3aWxsIHJldHVybiBhIDQwNCBpZiBhIG1hdGNoIGlzIGZvdW5kLiBBbGwgb3Ro ZXIgcmVxdWVzdHMgc2hvdWxkIGNvbXBsZXRlLg0KPC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMzg7IG1hcmdpbi10b3A6IDBwdDsgbWFyZ2lu LWJvdHRvbTogMHB0OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMz MzMzMzMzMzMycHg7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyIgY2xhc3M9IiI+RXZlbiBpbiBlbmNyeXB0ZWQgY29ubmVjdGlvbnMgdHJhbnNwb3J0IGFu ZCBsb3dlciBsYXllciBtZXRhZGF0YSBpcyBhYmxlIHRvDQogYmUgdmlld2VkIHNvIGZvciBtYW55 IHN5c3RlbXMgY29udGVudCBmaWx0ZXJpbmcgc2hvdWxkIGJlIGFibGUgdG8gY29udGludWUuIENh c2VzIHdoZW4gdGhleSBtYXkgbm90IHdvcmsgaXMgd2hlbiBUTFMgcHJveGllcyBhcmUgYmVpbmcg dXNlZCB3aGljaCBvYnNjdXJlIG1ldGFkYXRhIHdpdGggdGhlIHByb3h5IG1ldGFkYXRhLCBhbmQg ZnV0dXJlIHZlcnNpb25zIGluIEhUVFAgYW5kIFRDUCBtYXkgZW5jcnlwdCBtZXRhZGF0YSBhZ2Fp biBzdG9wcGluZw0KIGNvbnRlbnQgZmlsdGVyaW5nIHNvZnR3YXJlIGZyb20gd29ya2luZyAodGhp cyBpcyBjdXJyZW50bHkgbm90IHRoZSBjYXNlIGFuZCBoYXMgbm90IGJlZW4gc3RhbmRhcmRpc2Vk KS4NCjwvc3Bhbj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0 OiAxLjM4OyBtYXJnaW4tdG9wOiAwcHQ7IG1hcmdpbi1ib3R0b206IDBwdDsiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzMzMzMzMzMzMzMzMnB4OyB2ZXJ0aWNhbC1hbGln bjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPlNvbWUgc2l0ZXMg aW52b2x2ZSBhIG1peHR1cmUgb2YgdW5pdmVyc2FsIGFuZCBhZ2Utc2Vuc2l0aXZlIGNvbnRlbnQg YW5kIGZpbHRlcmluZw0KIHNvZnR3YXJlIGluIHRoZXNlIGNhc2VzIG1heSB1c2UgbW9yZSBncmFu dWxhciAoYXBwbGljYXRpb24gbGF5ZXIpIG1ldGFkYXRhIHRvIGFuYWx5c2UgYW5kIGJsb2NrOyB0 aGlzIHdpbGwgbm90IHdvcmsgb24gZW5jcnlwdGVkIGNvbnRlbnQuPC9zcGFuPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzMzMzMzMzMzMzMzJweDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEzLjMzMzMzMzMzMzMzMzMzMnB4OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxp bmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bh bj48L2Rpdj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVl IiBjbGFzcz0iIj5JIGRvIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGFib3V0IHdoYXQgSSBoYXZlIHdy aXR0ZW4sIG1heWJlIHNvbWVvbmUgY2FuIGFuc3dlcjo8L2Rpdj4NCjxkaXYgYXBwbGUtY29udGVu dC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPlsxXSBEb2VzIEhUVFAyIG11bHRpcGxleGluZyBkbyBh bnl0aGluZyB0byBjb250ZW50IGZpbHRlcmluZyBzb2Z0d2FyZSwgaS5lLiB3aGVuIHNlbmRpbmcg bXVsdGlwbGUgcmVxdWVzdHMgZm9yIG9uZSB3ZWJwYWdlIChsb2FkaW5nIGltYWdlcyBpbiBwYXJ0 aWN1bGFyKS4gSSBkb27igJl0IHRoaW5rIGl0IGRvZXMgaXTigJlzIGp1c3QgdGhhdCBteSBicmFp biBpc27igJl0IHdvcmtpbmcNCiB0aGlzIGFmdGVybm9vbi4uLjwvZGl2Pg0KPGRpdiBhcHBsZS1j b250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+WzJdIElzIGl0IGZhaXIgdG8gbWVudGlvbiBm dXR1cmUgdmVyc2lvbnMgb2YgSFRUUCBhbmQgVENQIHdoZW4gbm90aGluZyBoYXMgYmVlbiBzdGFu ZGFyZGlzZWQgeWV0PyBJIGRvbuKAmXQgdGhpbmsgc28gaW4gd2hpY2ggY2FzZSBtYXliZSB0aGlz IHNob3VsZCBiZSByZW1vdmVkLjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1 ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRp dGVkPSJ0cnVlIiBjbGFzcz0iIj5Ib3BlIHRoaXMgZGlkbuKAmXQgcnVpbiBldmVyeW9uZXMgbW9y bmluZyEgVGhhbmtzITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFdl YiBUZWNobm9sb2dpc3QgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21h LmNvbSIgY2xhc3M9IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDApJm5ic3A7 NzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRv Om5yb29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBj bGFzcz0iIj4NClRva3lvLCBKYXBhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNh bnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5v ci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7OyBtc28tYW5z aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1HQjsgbXNvLWJpZGkt bGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBhcmUgaW50 ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJ ZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgdGFrZSBubyBhY3Rpb24g YmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRvIGFueW9uZTsg cGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0K IGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_99DC814A2B7D4802A1C7399E77F37BD7gsmacom_-- From nobody Thu Jun 18 10:37:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146FA1B2AFB for ; Thu, 18 Jun 2015 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYciF5rvEZmm for ; Thu, 18 Jun 2015 10:37:19 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083A21B2AFA for ; Thu, 18 Jun 2015 10:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1434649039; x=1466185039; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=D/sTweC5qxhc1qlEpQ1h+2w43MbOZr6ZaYszEjka+q8=; b=uzdtPZNplaFYZfxsKhJPH8RYsqIlbMZu9euoZlg8M66no9zvqO4BdrI5 6WCriMgceoz5D+bpv6d+9UgQE9uMUNbuTnUAspiLqJHgHHaA7eQ5dad5e v2J2P4LOmVc4ajg98BHtpurWP9pbsSNn877CKy/uiXDp1gnkA5JccP2pT X1c1WxFOHTTwHJ96eb6rYDnSsR3DczxfWiaVQuTwTEB1BQMIP5MrvpkF5 a2RST3DNL59oGaSfAX02e0vJcCRchg+3Fg8MJ8BRQmF0pCkooBsAbqpMF exfqLMs9XpT1mwpqot1gX4gJXHUYs9s+z9zZ7HzKrNCxQfuildLbzyOe7 A==; X-IronPort-AV: E=Sophos;i="5.13,640,1427713200"; d="scan'208";a="23606277" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Jun 2015 05:37:17 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.151]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 19 Jun 2015 05:37:17 +1200 From: Peter Gutmann To: "cfrg@irtf.org" , "saag@ietf.org" Thread-Topic: Twist Insecurity Thread-Index: AdCp7WtAMKFDOmz6TZ2ngjz8zBlMqQ== Date: Thu, 18 Jun 2015 17:37:16 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB045C85@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Twist Insecurity X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 17:37:23 -0000 For those who haven't seen it yet, the following paper may be of interest:= =0A= =0A= http://eprint.iacr.org/2015/577=0A= =0A= Several authors suggest that the use of twist secure Elliptic Curves=0A= automatically leads to secure implementations. We argue that even for twi= st=0A= secure curves a point validation has to be performed. We illustrate this= =0A= with examples where the security of EC-algorithms is strongly degraded, e= ven=0A= for twist secure curves.=0A= =0A= We show that the usual blindig countermeasures against SCA are insufficie= nt=0A= (actually they introduce weaknesses) if no point validation is performed,= or=0A= if an attacker has access to certain intermediate points. In this case th= e=0A= overall security of the system is reduced to the length of the blinding= =0A= parameter. We emphazise that our methods work even in the case of a very= =0A= high identification error rate during the SCA-phase.=0A= =0A= Peter.=0A= From nobody Fri Jun 19 04:25:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1591A8981 for ; Fri, 19 Jun 2015 04:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63cDbE-gz2_q for ; Fri, 19 Jun 2015 04:25:29 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B936C1A8969 for ; Fri, 19 Jun 2015 04:25:28 -0700 (PDT) Received: from [195.245.230.51] by server-14.bemta-3.messagelabs.com id 57/5E-02969-62CF3855; Fri, 19 Jun 2015 11:25:26 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-10.tower-33.messagelabs.com!1434713126!13215369!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9778 invoked from network); 19 Jun 2015 11:25:26 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-10.tower-33.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jun 2015 11:25:26 -0000 Received: from mailint02.vodafone.com (mailint02.vodafone.com [195.232.244.199]) by mailout04.vodafone.com (Postfix) with ESMTP id 3mCd922yKmznTYS for ; Fri, 19 Jun 2015 13:25:26 +0200 (CEST) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailint02.vodafone.com (Postfix) with ESMTP id 3mCd921k2HzQlPF for ; Fri, 19 Jun 2015 13:25:26 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 3mCd921dkMzQmD4 for ; Fri, 19 Jun 2015 13:25:26 +0200 (CEST) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 19 Jun 2015 13:25:26 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.186]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 13:25:25 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] Request for review: new version 'Network Management of Encrypted Traffic' Thread-Index: AdCqgmIzZHdEH0ZAQlWTOxfRg3Bz7Q== Date: Fri, 19 Jun 2015 11:25:24 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Request for review: new version 'Network Management of Encrypted Traffic' X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 11:25:30 -0000 Hi all, Please may I ask for review of the updated version of 'Network Management o= f Encrypted Traffic' [1] - thanks for the previous feedback. Issues can be= raised on this thread or via [2]. [1] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-02= =20 [2] https://github.com/Kevsy/encrypted-traffic-management/issues=20 All best, Kevin From nobody Fri Jun 19 05:32:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062461A877F for ; Fri, 19 Jun 2015 05:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIhFhisVG6Yy for ; Fri, 19 Jun 2015 05:32:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A71A11A8AD3 for ; Fri, 19 Jun 2015 05:32:24 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-1c-55840bd67c0e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.23.04015.6DB04855; Fri, 19 Jun 2015 14:32:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 14:32:22 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: "Smith, Kevin, (R&D) Vodafone Group" Thread-Topic: [saag] Request for review: new version 'Network Management of Encrypted Traffic' Thread-Index: AdCqgmIzZHdEH0ZAQlWTOxfRg3Bz7QACZrpd Date: Fri, 19 Jun 2015 12:32:21 +0000 Message-ID: <3A5C8107-69E3-4717-B109-24497967B005@ericsson.com> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre517pZQg+e7mCwe31zEZDGlv5PJ gcljyZKfTB59M9YzBjBFcdmkpOZklqUW6dslcGXcbVYt+MZWcanpDHMD433WLkZODgkBE4mG y8fYIGwxiQv31gPZXBxCAkcZJZau+sQO4SxmlHg4dytYB5uAt8S0FWfBbBEBZ4nrJ6azgNjM AsoSb/88Yepi5OAQFoiXeHfTCKIkQaKpezEThG0kMe/jLrByFgFViWnTF4HZvAL2Eq+f3ACr ERIIlZh9/AgjiM0pECbRMvseWJxRQFbi/vd7UKvEJT7PfcAEcbSAxJI955khbFGJl4//sULU 6EncmDqFDcLWlli28DUzxC5BiZMzn7BMYBSdhWTULCQts5C0zELSsoCRZRWjaHFqcVJuupGR XmpRZnJxcX6eXl5qySZGYJQc3PLbYAfjy+eOhxgFOBiVeHgV1JpChVgTy4orcw8xSnOwKInz zticFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUbxkgV/z+QmLqkq8u1OcMsUKHJYVhXks 2T5XaWrV3Sdq+lsrzR89FH90YtpnVcXjU89MWaE4m/Ot06tXPzzm+Qv8Vt98N49To8BgTrvd ybb+aSs3mxxfuGffpW1TPbhE22Oa7AyjnnOz7mLQDWkvNXxY8Ojcv9hyhZSPHI2tK8V0zTxm zDXfpsRSnJFoqMVcVJwIACycThBzAgAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Request for review: new version 'Network Management of Encrypted Traffic' X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 12:32:27 -0000 Hi, Section 2.2 mentions "intercepting TLS". There are several interpretations = of that. Perhaps some more details would help clarify this. Section 2.4 seems broken. It suddenly stops after 'zero-rating'... Regards G=F6ran > 19 jun 2015 kl. 13:25 skrev Smith, Kevin, (R&D) Vodafone Group : >=20 > Hi all, >=20 > Please may I ask for review of the updated version of 'Network Management= of Encrypted Traffic' [1] - thanks for the previous feedback. Issues can = be raised on this thread or via [2]. >=20 > [1] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-0= 2=20 > [2] https://github.com/Kevsy/encrypted-traffic-management/issues=20 >=20 > All best, > Kevin >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Jun 19 06:10:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9289F1A8F4F for ; Fri, 19 Jun 2015 06:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnIfatyuRjAP for ; Fri, 19 Jun 2015 06:10:28 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC991A8F4D for ; Fri, 19 Jun 2015 06:10:27 -0700 (PDT) Received: by lbbvz5 with SMTP id vz5so23775262lbb.0 for ; Fri, 19 Jun 2015 06:10:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=R4UOkMY59ZYdhzhNzebH4NrL3z5E7WE8IEXU+r52AJ0=; b=j5lIygMKJ8zKfuXAmYGfseUeAJhoNfFEuSfH2F2pEwf2e2I7+09Ls1gI6HYnp63MTe Xp6f9oNDeD/TaxWhea0P36SpJA5VU82mw7RK2h5axV/vFeaxwPIgvydtOoCG789oYgUO iUF5svuUFWduxkbAZlKnvys1w1oaD+CMpLIFnrtqVN3LK55M8c26gu6d7F7Qghj7ibjz eWYCYwuKmSOzcDC9O+AF8TyD1BL5bPHzlMiO2sCEE08tUUAbYM7x0NJX0KkKhPA0FWKJ eR5wqepNJYQToYoIsBE2CqVIdxINMtXYy2pB8AbR3b/7R3NB47g3Pccsa1tovOvzWRTT eLuQ== X-Gm-Message-State: ALoCoQkZcMN6q+rn75mCSOLfAyBI/B3HHRDaC0EIzMX5doogGKfw41zKxII3i9QabsmUltNfuLKb X-Received: by 10.152.5.65 with SMTP id q1mr17801512laq.110.1434719426141; Fri, 19 Jun 2015 06:10:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.154.5 with HTTP; Fri, 19 Jun 2015 06:10:05 -0700 (PDT) In-Reply-To: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> From: Joseph Lorenzo Hall Date: Fri, 19 Jun 2015 09:10:05 -0400 Message-ID: To: Natasha Rooney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:10:35 -0000 I would at least like this to acknowledge that it's possible to do filtering at the endpoint. As you can imagine, I would argue another term for content filtering is censorship. best, Joe On Thu, Jun 18, 2015 at 3:58 AM, Natasha Rooney wrote: > Hi all, > > I have a new submission for the Ubiquitous Encryption draft. I must admit= , > this one is a little controversial, and certainly is not something I beli= eve > in. However, I had a good think about it, and figured that this is an > "effect" of ubiquitous encryption, and maybe would be beneficial for the > draft. I am not expecting anything comes out of adding it past education = for > members of the IETF community that this is an issue for some organisation= s, > governments and maybe users. Please feel free to tweet me if you want to > discuss personal views! Anyway, here we go: > > > 2.3.X Content Filtering > Law agencies may request Service Providers to block access to particular > sites such as online betting and gambling, sites promoting anorexia, or > access to dating sites. Content filtering in the mobile network usually > occurs in the core network. A proxy is installed which analyses the > transport metadata of the content users are viewing and either filters > content based on a blacklist of sites or based on the user=E2=80=99s pre-= defined > profile (e.g. for age sensitive content). Although filtering can be done = by > many methods one common method occurs when a DNS lookup reveals a URL whi= ch > appears on a government or recognised block-list. The subsequent requests= to > that domain will be re-routed to a proxy which checks whether the full ur= l > matches a blocked url on the list, and will return a 404 if a match is > found. All other requests should complete. > > Even in encrypted connections transport and lower layer metadata is able = to > be viewed so for many systems content filtering should be able to continu= e. > Cases when they may not work is when TLS proxies are being used which > obscure metadata with the proxy metadata, and future versions in HTTP and > TCP may encrypt metadata again stopping content filtering software from > working (this is currently not the case and has not been standardised). > > Some sites involve a mixture of universal and age-sensitive content and > filtering software in these cases may use more granular (application laye= r) > metadata to analyse and block; this will not work on encrypted content. > > > I do have a few questions about what I have written, maybe someone can > answer: > [1] Does HTTP2 multiplexing do anything to content filtering software, i.= e. > when sending multiple requests for one webpage (loading images in > particular). I don=E2=80=99t think it does it=E2=80=99s just that my brai= n isn=E2=80=99t working > this afternoon... > [2] Is it fair to mention future versions of HTTP and TCP when nothing ha= s > been standardised yet? I don=E2=80=99t think so in which case maybe this = should be > removed. > > Hope this didn=E2=80=99t ruin everyones morning! Thanks! > > Natasha > > > Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 773= 0 > 219 765 | @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan > > > This email and its attachments are intended for the above named only and = may > be confidential. If they have come to you in error you must take no actio= n > based on them, nor must you copy or show them to anyone; please reply to > this email or call +44 207 356 0600 and highlight the error. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Fri Jun 19 07:08:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE341A0318 for ; Fri, 19 Jun 2015 07:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s2ZO6IEeTIJ for ; Fri, 19 Jun 2015 07:08:03 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEDC1A02BE for ; Fri, 19 Jun 2015 07:08:03 -0700 (PDT) Received: from [85.158.139.163] by server-6.bemta-5.messagelabs.com id 2C/C6-08467-D3224855; Fri, 19 Jun 2015 14:07:57 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-14.tower-188.messagelabs.com!1434722875!10473151!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9858 invoked from network); 19 Jun 2015 14:07:56 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-14.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jun 2015 14:07:56 -0000 Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3mChmW4JK9znTYP; Fri, 19 Jun 2015 16:07:55 +0200 (CEST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3mChmW38c8z16J6k; Fri, 19 Jun 2015 16:07:55 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3mChmW33W0z16LTY; Fri, 19 Jun 2015 16:07:55 +0200 (CEST) Received: from VOEXC16W.internal.vodafone.com (145.230.101.18) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 19 Jun 2015 16:07:55 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.186]) by voexc16w.internal.vodafone.com ([145.230.101.18]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 16:07:54 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Joseph Lorenzo Hall , Natasha Rooney Thread-Topic: [saag] Ubiquitous Encryption: content filtering Thread-Index: AQHQqZyDVZfM/qjQ1ki7JjpGF/YhdJ2zrcSAgAAotYA= Date: Fri, 19 Jun 2015 14:07:53 +0000 Message-ID: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 14:08:06 -0000 PiBJIHdvdWxkIGF0IGxlYXN0IGxpa2UgdGhpcyB0byBhY2tub3dsZWRnZSB0aGF0IGl0J3MgcG9z c2libGUgdG8gZG8gZmlsdGVyaW5nIGF0IHRoZSBlbmRwb2ludC4gQXMgeW91IGNhbiBpbWFnaW5l LCBJIHdvdWxkIGFyZ3VlIGFub3RoZXIgdGVybSBmb3IgY29udGVudCBmaWx0ZXJpbmcgaXMgY2Vu c29yc2hpcC4gYmVzdCwgSm9lDQoNCkhpIEpvZSwNCg0KSW5kZWVkLCBpdCBpcyBwb3NzaWJsZSB0 byBmaWx0ZXIgYXQgdGhlIGVuZHBvaW50LiBIb3dldmVyLCBhIG1vYmlsZSBvcGVyYXRvciB1dGls aXNpbmcgbGljZW5jZWQgc3BlY3RydW0gbXVzdCBhZGhlcmUgdG8gcmVndWxhdGlvbnMgc2V0IGJ5 IHRoZSBnb3Zlcm5tZW50IGxpY2Vuc29yLCB3aGljaCBpbmNsdWRlIGNvbnRlbnQgZmlsdGVyaW5n LCBvciByaXNrIGZpbmVzL2xpY2VuY2Ugc3VzcGVuc2lvbi4gVGhlIHJpc2UgaW4gZW5kLXRvLWVu ZCBlbmNyeXB0aW9uIG1heSB3ZWxsIGNoYW5nZSB0aGlzIHNpdHVhdGlvbjsgYXMgaWYgdGhlIHJl Z3VsYXRvcnMgY2Fubm90IGNvbnN0cmFpbiBhY2Nlc3MgdmlhIHRoZSBvcGVyYXRvciBuZXR3b3Jr LCBpdCBpcyBsaWtlbHkgdGhleSB3aWxsIGxvb2sgdG8gb3RoZXIgbWVhbnMuIEknbSBpbiBkaXNj dXNzaW9uIHdpdGggb3VyIGxlZ2FsIGFuZCByZWd1bGF0b3J5IHRlYW1zIGFuZCBhaW0gdG8gcHJl c2VudCBvbiB0aGlzIGF0IHRoZSB3b3Jrc2hvcC4NCg0KPiBBcyB5b3UgY2FuIGltYWdpbmUsIEkg d291bGQgYXJndWUgYW5vdGhlciB0ZXJtIGZvciBjb250ZW50IGZpbHRlcmluZyBpcyBjZW5zb3Jz aGlwLg0KDQpGYWlyIHBvaW50LCBidXQgd2Ugc2hvdWxkIGZvY3VzIG9uIHRoZSB0ZWNobmljYWwg b3B0aW9ucyAoZS5nLiBlbmRwb2ludCB2cy4gbmV0d29yayBmaWx0ZXJzKSBmb3IgdGhlIHNjb3Bl IG9mIHRoaXMgd29ya3Nob3AuIA0KDQpBbGwgYmVzdA0KS2V2aW4NCg0KS2V2aW4gU21pdGgsIFZv ZGFmb25lIFImRA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2FhZyBbbWFp bHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvc2VwaCBMb3JlbnpvIEhh bGwNClNlbnQ6IDE5IEp1bmUgMjAxNSAxNDoxMA0KVG86IE5hdGFzaGEgUm9vbmV5DQpDYzogc2Fh Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzYWFnXSBVYmlxdWl0b3VzIEVuY3J5cHRpb246IGNv bnRlbnQgZmlsdGVyaW5nDQoNCkkgd291bGQgYXQgbGVhc3QgbGlrZSB0aGlzIHRvIGFja25vd2xl ZGdlIHRoYXQgaXQncyBwb3NzaWJsZSB0byBkbyBmaWx0ZXJpbmcgYXQgdGhlIGVuZHBvaW50LiBB cyB5b3UgY2FuIGltYWdpbmUsIEkgd291bGQgYXJndWUgYW5vdGhlciB0ZXJtIGZvciBjb250ZW50 IGZpbHRlcmluZyBpcyBjZW5zb3JzaGlwLiBiZXN0LCBKb2UNCg0KT24gVGh1LCBKdW4gMTgsIDIw MTUgYXQgMzo1OCBBTSwgTmF0YXNoYSBSb29uZXkgPG5yb29uZXlAZ3NtYS5jb20+IHdyb3RlOg0K PiBIaSBhbGwsDQo+DQo+IEkgaGF2ZSBhIG5ldyBzdWJtaXNzaW9uIGZvciB0aGUgVWJpcXVpdG91 cyBFbmNyeXB0aW9uIGRyYWZ0LiBJIG11c3QgDQo+IGFkbWl0LCB0aGlzIG9uZSBpcyBhIGxpdHRs ZSBjb250cm92ZXJzaWFsLCBhbmQgY2VydGFpbmx5IGlzIG5vdCANCj4gc29tZXRoaW5nIEkgYmVs aWV2ZSBpbi4gSG93ZXZlciwgSSBoYWQgYSBnb29kIHRoaW5rIGFib3V0IGl0LCBhbmQgDQo+IGZp Z3VyZWQgdGhhdCB0aGlzIGlzIGFuICJlZmZlY3QiIG9mIHViaXF1aXRvdXMgZW5jcnlwdGlvbiwg YW5kIG1heWJlIA0KPiB3b3VsZCBiZSBiZW5lZmljaWFsIGZvciB0aGUgZHJhZnQuIEkgYW0gbm90 IGV4cGVjdGluZyBhbnl0aGluZyBjb21lcyANCj4gb3V0IG9mIGFkZGluZyBpdCBwYXN0IGVkdWNh dGlvbiBmb3IgbWVtYmVycyBvZiB0aGUgSUVURiBjb21tdW5pdHkgdGhhdCANCj4gdGhpcyBpcyBh biBpc3N1ZSBmb3Igc29tZSBvcmdhbmlzYXRpb25zLCBnb3Zlcm5tZW50cyBhbmQgbWF5YmUgdXNl cnMuIA0KPiBQbGVhc2UgZmVlbCBmcmVlIHRvIHR3ZWV0IG1lIGlmIHlvdSB3YW50IHRvIGRpc2N1 c3MgcGVyc29uYWwgdmlld3MhIEFueXdheSwgaGVyZSB3ZSBnbzoNCj4NCj4NCj4gMi4zLlggQ29u dGVudCBGaWx0ZXJpbmcNCj4gTGF3IGFnZW5jaWVzIG1heSByZXF1ZXN0IFNlcnZpY2UgUHJvdmlk ZXJzIHRvIGJsb2NrIGFjY2VzcyB0byANCj4gcGFydGljdWxhciBzaXRlcyBzdWNoIGFzIG9ubGlu ZSBiZXR0aW5nIGFuZCBnYW1ibGluZywgc2l0ZXMgcHJvbW90aW5nIA0KPiBhbm9yZXhpYSwgb3Ig YWNjZXNzIHRvIGRhdGluZyBzaXRlcy4gQ29udGVudCBmaWx0ZXJpbmcgaW4gdGhlIG1vYmlsZSAN Cj4gbmV0d29yayB1c3VhbGx5IG9jY3VycyBpbiB0aGUgY29yZSBuZXR3b3JrLiBBIHByb3h5IGlz IGluc3RhbGxlZCB3aGljaCANCj4gYW5hbHlzZXMgdGhlIHRyYW5zcG9ydCBtZXRhZGF0YSBvZiB0 aGUgY29udGVudCB1c2VycyBhcmUgdmlld2luZyBhbmQgDQo+IGVpdGhlciBmaWx0ZXJzIGNvbnRl bnQgYmFzZWQgb24gYSBibGFja2xpc3Qgb2Ygc2l0ZXMgb3IgYmFzZWQgb24gdGhlIA0KPiB1c2Vy 4oCZcyBwcmUtZGVmaW5lZCBwcm9maWxlIChlLmcuIGZvciBhZ2Ugc2Vuc2l0aXZlIGNvbnRlbnQp LiBBbHRob3VnaCANCj4gZmlsdGVyaW5nIGNhbiBiZSBkb25lIGJ5IG1hbnkgbWV0aG9kcyBvbmUg Y29tbW9uIG1ldGhvZCBvY2N1cnMgd2hlbiBhIA0KPiBETlMgbG9va3VwIHJldmVhbHMgYSBVUkwg d2hpY2ggYXBwZWFycyBvbiBhIGdvdmVybm1lbnQgb3IgcmVjb2duaXNlZCANCj4gYmxvY2stbGlz dC4gVGhlIHN1YnNlcXVlbnQgcmVxdWVzdHMgdG8gdGhhdCBkb21haW4gd2lsbCBiZSByZS1yb3V0 ZWQgDQo+IHRvIGEgcHJveHkgd2hpY2ggY2hlY2tzIHdoZXRoZXIgdGhlIGZ1bGwgdXJsIG1hdGNo ZXMgYSBibG9ja2VkIHVybCBvbiANCj4gdGhlIGxpc3QsIGFuZCB3aWxsIHJldHVybiBhIDQwNCBp ZiBhIG1hdGNoIGlzIGZvdW5kLiBBbGwgb3RoZXIgcmVxdWVzdHMgc2hvdWxkIGNvbXBsZXRlLg0K Pg0KPiBFdmVuIGluIGVuY3J5cHRlZCBjb25uZWN0aW9ucyB0cmFuc3BvcnQgYW5kIGxvd2VyIGxh eWVyIG1ldGFkYXRhIGlzIA0KPiBhYmxlIHRvIGJlIHZpZXdlZCBzbyBmb3IgbWFueSBzeXN0ZW1z IGNvbnRlbnQgZmlsdGVyaW5nIHNob3VsZCBiZSBhYmxlIHRvIGNvbnRpbnVlLg0KPiBDYXNlcyB3 aGVuIHRoZXkgbWF5IG5vdCB3b3JrIGlzIHdoZW4gVExTIHByb3hpZXMgYXJlIGJlaW5nIHVzZWQg d2hpY2ggDQo+IG9ic2N1cmUgbWV0YWRhdGEgd2l0aCB0aGUgcHJveHkgbWV0YWRhdGEsIGFuZCBm dXR1cmUgdmVyc2lvbnMgaW4gSFRUUCANCj4gYW5kIFRDUCBtYXkgZW5jcnlwdCBtZXRhZGF0YSBh Z2FpbiBzdG9wcGluZyBjb250ZW50IGZpbHRlcmluZyBzb2Z0d2FyZSANCj4gZnJvbSB3b3JraW5n ICh0aGlzIGlzIGN1cnJlbnRseSBub3QgdGhlIGNhc2UgYW5kIGhhcyBub3QgYmVlbiBzdGFuZGFy ZGlzZWQpLg0KPg0KPiBTb21lIHNpdGVzIGludm9sdmUgYSBtaXh0dXJlIG9mIHVuaXZlcnNhbCBh bmQgYWdlLXNlbnNpdGl2ZSBjb250ZW50IA0KPiBhbmQgZmlsdGVyaW5nIHNvZnR3YXJlIGluIHRo ZXNlIGNhc2VzIG1heSB1c2UgbW9yZSBncmFudWxhciANCj4gKGFwcGxpY2F0aW9uIGxheWVyKSBt ZXRhZGF0YSB0byBhbmFseXNlIGFuZCBibG9jazsgdGhpcyB3aWxsIG5vdCB3b3JrIG9uIGVuY3J5 cHRlZCBjb250ZW50Lg0KPg0KPg0KPiBJIGRvIGhhdmUgYSBmZXcgcXVlc3Rpb25zIGFib3V0IHdo YXQgSSBoYXZlIHdyaXR0ZW4sIG1heWJlIHNvbWVvbmUgY2FuDQo+IGFuc3dlcjoNCj4gWzFdIERv ZXMgSFRUUDIgbXVsdGlwbGV4aW5nIGRvIGFueXRoaW5nIHRvIGNvbnRlbnQgZmlsdGVyaW5nIHNv ZnR3YXJlLCBpLmUuDQo+IHdoZW4gc2VuZGluZyBtdWx0aXBsZSByZXF1ZXN0cyBmb3Igb25lIHdl YnBhZ2UgKGxvYWRpbmcgaW1hZ2VzIGluIA0KPiBwYXJ0aWN1bGFyKS4gSSBkb27igJl0IHRoaW5r IGl0IGRvZXMgaXTigJlzIGp1c3QgdGhhdCBteSBicmFpbiBpc27igJl0IA0KPiB3b3JraW5nIHRo aXMgYWZ0ZXJub29uLi4uDQo+IFsyXSBJcyBpdCBmYWlyIHRvIG1lbnRpb24gZnV0dXJlIHZlcnNp b25zIG9mIEhUVFAgYW5kIFRDUCB3aGVuIG5vdGhpbmcgDQo+IGhhcyBiZWVuIHN0YW5kYXJkaXNl ZCB5ZXQ/IEkgZG9u4oCZdCB0aGluayBzbyBpbiB3aGljaCBjYXNlIG1heWJlIHRoaXMgDQo+IHNo b3VsZCBiZSByZW1vdmVkLg0KPg0KPiBIb3BlIHRoaXMgZGlkbuKAmXQgcnVpbiBldmVyeW9uZXMg bW9ybmluZyEgVGhhbmtzIQ0KPg0KPiBOYXRhc2hhDQo+DQo+DQo+IE5hdGFzaGEgUm9vbmV5IHwg V2ViIFRlY2hub2xvZ2lzdCB8IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tIHwgKzQ0ICgwKSANCj4g NzczMA0KPiAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZyBU b2t5bywgSmFwYW4NCj4NCj4NCj4gVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBp bnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgDQo+IGFuZCBtYXkgYmUgY29uZmlkZW50 aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11c3QgDQo+IHRha2Ug bm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0sIG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0 byANCj4gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcg MzU2IDA2MDAgYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNhYWcgbWFpbGluZyBsaXN0DQo+ IHNhYWdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z YWFnDQo+DQoNCg0KDQotLQ0KSm9zZXBoIExvcmVuem8gSGFsbA0KQ2hpZWYgVGVjaG5vbG9naXN0 DQpDZW50ZXIgZm9yIERlbW9jcmFjeSAmIFRlY2hub2xvZ3kNCjE2MzQgSSBTVCBOVyBTVEUgMTEw MA0KV2FzaGluZ3RvbiBEQyAyMDAwNi00MDExDQoocCkgMjAyLTQwNy04ODI1DQooZikgMjAyLTYz Ny0wOTY4DQpqb2VAY2R0Lm9yZw0KUEdQOiBodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXkN CmZpbmdlcnByaW50OiAzQ0EyIDhEN0IgOUY2RCBEQkQzIDRCMTAgIDE2MDcgNUY4NiA2OTg3IDQw QTkgQTg3MQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2FhZyBtYWlsaW5nIGxpc3QNCnNhYWdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2FhZw0K From nobody Fri Jun 19 08:58:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEBF1A9126 for ; Fri, 19 Jun 2015 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZWtwgtNZLCU for ; Fri, 19 Jun 2015 08:58:19 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542DF1A9120 for ; Fri, 19 Jun 2015 08:58:19 -0700 (PDT) Received: by laka10 with SMTP id a10so76931570lak.0 for ; Fri, 19 Jun 2015 08:58:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=i/tMU45CRceEp21nmWmjLcf4dJ+Pb4bjFWcZTFtMKIM=; b=gPPuzUJ+R7NqFZXKbiZ2b5SxMNrge4595bMB99tdxmWZllQUC1MXTN/pa+aoLqkKbt a0g/uQbdt4e06mgUsUOWrrtB0Mpm5UYLVaLWiGdG8MjwDv4XjkiUdUI030LbLyQVw5kt gsRXECmwhJD1RiC1wA8Ubg2d5+iSX2o7Zw4IufsMQnU7VEh0gbOzCwuQkDAHsCqtZKqz wrz4P8squ/gPM/FZaLPhM2Me5lA4wVWWBlwkKbHv9DAsoKLRxQHaXp33ZFMPWjPPA3cw m3MtTLas6nSvVToa0nEe0C8EV7YC+E44nDXlCtSyqxfvBORRqxL/dPr32WhwZHY62Mp1 eDRQ== X-Gm-Message-State: ALoCoQlqPNWG8UKQ0qSPBt9ExOHHWMXKDrkOcAjNqaFsix6zWW3aZIFaufrQFJl+2XWcZNAgEFez X-Received: by 10.112.140.137 with SMTP id rg9mr18532163lbb.101.1434729497764; Fri, 19 Jun 2015 08:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.154.5 with HTTP; Fri, 19 Jun 2015 08:57:57 -0700 (PDT) In-Reply-To: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> From: Joseph Lorenzo Hall Date: Fri, 19 Jun 2015 11:57:57 -0400 Message-ID: To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 15:58:21 -0000 On Fri, Jun 19, 2015 at 10:07 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > > > I would at least like this to acknowledge that it's possible to do filt= ering at the endpoint. As you can imagine, I would argue another term for c= ontent filtering is censorship. best, Joe > > Hi Joe, > > Indeed, it is possible to filter at the endpoint. However, a mobile opera= tor utilising licenced spectrum must adhere to regulations set by the gover= nment licensor, which include content filtering, or risk fines/licence susp= ension. The rise in end-to-end encryption may well change this situation; a= s if the regulators cannot constrain access via the operator network, it is= likely they will look to other means. I'm in discussion with our legal and= regulatory teams and aim to present on this at the workshop. Text that expresses the intent you've described here I think would be useful if Natasha's text is pulled in. > > As you can imagine, I would argue another term for content filtering is= censorship. > > Fair point, but we should focus on the technical options (e.g. endpoint v= s. network filters) for the scope of this workshop. Totally understood. (workshop? or I-D?) > All best > Kevin > > Kevin Smith, Vodafone R&D > > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Joseph Lorenzo Hal= l > Sent: 19 June 2015 14:10 > To: Natasha Rooney > Cc: saag@ietf.org > Subject: Re: [saag] Ubiquitous Encryption: content filtering > > I would at least like this to acknowledge that it's possible to do filter= ing at the endpoint. As you can imagine, I would argue another term for con= tent filtering is censorship. best, Joe > > On Thu, Jun 18, 2015 at 3:58 AM, Natasha Rooney wrote: > > Hi all, > > > > I have a new submission for the Ubiquitous Encryption draft. I must > > admit, this one is a little controversial, and certainly is not > > something I believe in. However, I had a good think about it, and > > figured that this is an "effect" of ubiquitous encryption, and maybe > > would be beneficial for the draft. I am not expecting anything comes > > out of adding it past education for members of the IETF community that > > this is an issue for some organisations, governments and maybe users. > > Please feel free to tweet me if you want to discuss personal views! Any= way, here we go: > > > > > > 2.3.X Content Filtering > > Law agencies may request Service Providers to block access to > > particular sites such as online betting and gambling, sites promoting > > anorexia, or access to dating sites. Content filtering in the mobile > > network usually occurs in the core network. A proxy is installed which > > analyses the transport metadata of the content users are viewing and > > either filters content based on a blacklist of sites or based on the > > user=E2=80=99s pre-defined profile (e.g. for age sensitive content). Al= though > > filtering can be done by many methods one common method occurs when a > > DNS lookup reveals a URL which appears on a government or recognised > > block-list. The subsequent requests to that domain will be re-routed > > to a proxy which checks whether the full url matches a blocked url on > > the list, and will return a 404 if a match is found. All other requests= should complete. > > > > Even in encrypted connections transport and lower layer metadata is > > able to be viewed so for many systems content filtering should be able = to continue. > > Cases when they may not work is when TLS proxies are being used which > > obscure metadata with the proxy metadata, and future versions in HTTP > > and TCP may encrypt metadata again stopping content filtering software > > from working (this is currently not the case and has not been standardi= sed). > > > > Some sites involve a mixture of universal and age-sensitive content > > and filtering software in these cases may use more granular > > (application layer) metadata to analyse and block; this will not work o= n encrypted content. > > > > > > I do have a few questions about what I have written, maybe someone can > > answer: > > [1] Does HTTP2 multiplexing do anything to content filtering software, = i.e. > > when sending multiple requests for one webpage (loading images in > > particular). I don=E2=80=99t think it does it=E2=80=99s just that my br= ain isn=E2=80=99t > > working this afternoon... > > [2] Is it fair to mention future versions of HTTP and TCP when nothing > > has been standardised yet? I don=E2=80=99t think so in which case maybe= this > > should be removed. > > > > Hope this didn=E2=80=99t ruin everyones morning! Thanks! > > > > Natasha > > > > > > Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) > > 7730 > > 219 765 | @thisNatasha | Skype: nrooney@gsm.org Tokyo, Japan > > > > > > This email and its attachments are intended for the above named only > > and may be confidential. If they have come to you in error you must > > take no action based on them, nor must you copy or show them to > > anyone; please reply to this email or call +44 207 356 0600 and highlig= ht the error. > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > > > -- > Joseph Lorenzo Hall > Chief Technologist > Center for Democracy & Technology > 1634 I ST NW STE 1100 > Washington DC 20006-4011 > (p) 202-407-8825 > (f) 202-637-0968 > joe@cdt.org > PGP: https://josephhall.org/gpg-key > fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 From nobody Fri Jun 19 09:46:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79951AC431 for ; Fri, 19 Jun 2015 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBnp2o9cZZo1 for ; Fri, 19 Jun 2015 09:46:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BD11AC42D for ; Fri, 19 Jun 2015 09:46:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8ED82BE88; Fri, 19 Jun 2015 17:46:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OmXq0vQMjpB; Fri, 19 Jun 2015 17:46:09 +0100 (IST) Received: from [192.168.3.222] (173-8-161-213-SFBA.hfc.comcastbusiness.net [173.8.161.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6CEDBE80; Fri, 19 Jun 2015 17:45:56 +0100 (IST) Message-ID: <55844743.4030300@cs.tcd.ie> Date: Fri, 19 Jun 2015 17:45:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Smith, Kevin, (R&D) Vodafone Group" , Natasha Rooney References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:46:14 -0000 Hi Kevin, Natasha, On 19/06/15 15:07, Smith, Kevin, (R&D) Vodafone Group wrote: > Indeed, it is possible to filter at the endpoint. However, a mobile > operator utilising licenced spectrum must adhere to regulations set > by the government licensor, which include content filtering, or risk > fines/licence suspension. Just to note that IETF is not in the same position as mobile operators here. Please see RFC 2804 for a good example of that kind of difference (but note 2804 deals with a different topic). That's not to say what the IETF consensus on such filtering/censorship might or might not be - I don't think we've asked and I expect there'd be a robust debate if we do, as there was for 2804. So even if thing-X is required by some local regulator, that does not by itself mean that the IETF needs to care about thing-X. I'm sure this is familiar to many long time IETF participants, but it may well not be commonly understood by some others who would consider the argument Kevin makes above as a winning argument. Cheers, S. PS: The mailing list archive for discussion that lead to 2804 is still around [1] and many of the arguments made then would still be relevant were we to delve further into this topic, or any other local-regulator vs. big-I Internet type thing. [1] https://www.ietf.org/mail-archive/web/raven/current/maillist.html From nobody Fri Jun 19 17:32:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D211B2BD4 for ; Fri, 19 Jun 2015 17:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfxjoW-or4eB for ; Fri, 19 Jun 2015 17:32:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C831B2BD8 for ; Fri, 19 Jun 2015 17:31:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z66gz-0005Zt-MQ; Sat, 20 Jun 2015 00:31:30 +0000 Date: Sat, 20 Jun 2015 09:31:28 +0900 Message-ID: From: Randy Bush To: "Smith, Kevin, (R&D) Vodafone Group" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Request for review: new version 'Network Management of Encrypted Traffic' X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:32:23 -0000 > Issues can be raised on this thread or via [2]. the ietf mantra is that we do our work on mailing lists randy From nobody Fri Jun 19 17:34:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5E1B2BDA for ; Fri, 19 Jun 2015 17:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClMnyn0cz-lL for ; Fri, 19 Jun 2015 17:34:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936291B2BD0 for ; Fri, 19 Jun 2015 17:34:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z66k1-0005aY-UH; Sat, 20 Jun 2015 00:34:38 +0000 Date: Sat, 20 Jun 2015 09:34:36 +0900 Message-ID: From: Randy Bush To: "Smith, Kevin, (R&D) Vodafone Group" In-Reply-To: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:34:42 -0000 > a mobile operator utilising licenced spectrum must adhere to > regulations set by the government licensor out of range error. see rfc 2804 randy From nobody Mon Jun 22 07:42:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A81ACDA3 for ; Mon, 22 Jun 2015 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BipgcpSEGqkq for ; Mon, 22 Jun 2015 07:42:22 -0700 (PDT) Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD0A1A1A19 for ; Mon, 22 Jun 2015 07:42:22 -0700 (PDT) Received: by vnbg7 with SMTP id g7so517645vnb.11 for ; Mon, 22 Jun 2015 07:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dTDOl7hUo4tiEeUtNyrifwP5X9hkN6Ik3kjaAh5IV84=; b=JU/Y+tP/SPUsQShmsOE9Zvny/ltno9kKRFlILeqMn75fYlVjzd7WRclRdo+FXMyYq2 UYqlcB/YBCEmGAiRYw/tYCZL9ECcvba/E4m/p1lGgNk4DVQRZT91KrHSI22nTyonJXfi j/TpqD0ie4IPBFgN17aNIuEzcxCnn9+zseVEGRKva8Q1oqhIq6BZAxTOu0feaEL1gsft W/dlw6Fqbg2Ru38dV/yPDme6RzqQ2Tj97NgzeGgybIZHjgt7RmXNYzACxZ1ozfjXkAuj Igpj1itn+Ng5EK9xOfnhQIDPuIpFGMfubWP4+au8zlC9S9VtYTo+LFSbhUQH6fKHUf2e mxTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dTDOl7hUo4tiEeUtNyrifwP5X9hkN6Ik3kjaAh5IV84=; b=NDUW0WCTAlj6FLOkeqKgUQxhyn+MhJRt2c0m4pJiVUWBnDlPiz6qPcsZvJ/6+J5/AH NKgk44cKRX4BA9y1j0JjNie3HqSsxHDbng+sx5d+HdjmysvgR/XcgRD/tKPjmGae8dZD VjJwbF2dDkkC90E6KqC394LzvNpJkCQx8ddEWknYt7YxLHTrkYW7y4dmm8N5NnIZC1+8 gnbW5ie1OpOtmsk2d8xUy/l2tcuEPfE/UWoF2PP67ONpZuhMc/DL2m/NCK4NXIMI5gIy 0Z4/y2qaxgTmrM5ydYyLUidavcU5fZ2xh47VkUwor37lFbkBjYf6ZcYdE+1DiRqgbpQt yfPA== X-Gm-Message-State: ALoCoQnn+mmb7JMZVSB5+Buob+jQbaxKLwHm16kh9i2dwVGNeRiEZ8nFvY/NpAEe4pVYyFD34mmn MIME-Version: 1.0 X-Received: by 10.52.26.5 with SMTP id h5mr752241vdg.3.1434984141638; Mon, 22 Jun 2015 07:42:21 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Mon, 22 Jun 2015 07:42:21 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jun 2015 15:42:21 +0100 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Request for review: new version 'Network Management of Encrypted Traffic' X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 14:42:23 -0000 On 20 June 2015 at 01:31, Randy Bush wrote: >> Issues can be raised on this thread or via [2]. > > the ietf mantra is that we do our work on mailing lists Or IETF's Trac, surely? From nobody Mon Jun 22 09:23:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FC01A87C8 for ; Mon, 22 Jun 2015 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIAe6HJAPn0d for ; Mon, 22 Jun 2015 09:22:59 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4591B3014 for ; Mon, 22 Jun 2015 09:22:23 -0700 (PDT) Received: by wiwl6 with SMTP id l6so42245834wiw.0 for ; Mon, 22 Jun 2015 09:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dNLtUjPMPuVq+kftIiF2xzavsbr2tr0Ed3oIIUBsauQ=; b=AWE1/1UUQdUMsYbANkuGtTZ5CbJV7+ygWFhHyOln8qJ+NMbNmWYdH5y6OqETh+rGGx s0WpQxU+FoymJ/eim6ADvOuaLUMK3cU5Uv0M6hmIa4Z5OGKx4U5GC4gzasfKZOvdDkCy Eyxfi6I+MBTlqVg/Asu6zodoOMv+ZQsiFjFG6yI+Ah5xw5SclLIRSbMqULSiA/QCs4yN 1vTziI7/LxcZa/S130syrLlWAab00Ilx/wcYvoHXetDeVxVyzzpnWjdSZOjHiLH1tDAD JBub9wY70E5uOknWQfBR0Tgw3paKi75+Ka7jgePbOd2pEKnuXku1K64oULPSW2NsoVeG D6FA== X-Received: by 10.194.79.73 with SMTP id h9mr51992174wjx.125.1434990141918; Mon, 22 Jun 2015 09:22:21 -0700 (PDT) Received: from [10.4.35.113] ([80.179.9.115]) by mx.google.com with ESMTPSA id di9sm18001975wib.16.2015.06.22.09.22.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 09:22:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Mon, 22 Jun 2015 19:22:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Laurie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Request for review: new version 'Network Management of Encrypted Traffic' X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 16:23:01 -0000 > On Jun 22, 2015, at 5:42 PM, Ben Laurie wrote: >=20 > On 20 June 2015 at 01:31, Randy Bush wrote: >>> Issues can be raised on this thread or via [2]. >>=20 >> the ietf mantra is that we do our work on mailing lists >=20 > Or IETF's Trac, surely? Trac is just a tool you can use if you want, much like GitHub, but = it=E2=80=99s mostly rigged to send notifications of changes to the = relevant mailing list so you get both covered. This draft is an individual submission, so there=E2=80=99s no trac for = it. Yoav From nobody Mon Jun 22 11:52:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889321A1BF4; Mon, 22 Jun 2015 11:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apZdMKA7pXru; Mon, 22 Jun 2015 11:52:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC8D1A1BE4; Mon, 22 Jun 2015 11:52:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F90D282FB9; Mon, 22 Jun 2015 18:52:40 +0000 (UTC) Date: Mon, 22 Jun 2015 18:52:40 +0000 From: Viktor Dukhovni To: Elwyn Davies Message-ID: <20150622185239.GU14121@mournblade.imrryr.org> References: <558851A5.20803@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558851A5.20803@dial.pipex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: draft-ietf-dane-ops.all@tools.ietf.org, General area reviewing team , saag@ietf.org, dane@ietf.org Subject: Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 18:52:43 -0000 On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote: > Summary: Almost ready. There are a couple of minor issues, and I think > the authors need to reassess whether all the cases where RFC 2119 keyworrds > are actually protocol requirements as opposed to operation best practice > recommendations. Thanks, will double-check the SHOULDS/MUSTS/... > s3: I am not a security expert, but I suspect you may get some pushback on > not making TLS 1.2 mandatory. We'll see what happens. The most widely deployed use of DANE is with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like an unnecessary restriction for an opportunistic protocol. However, non-support of TLS 1.2 is getting increasingly less common, so if push comes to shove, we can "require" TLS 1.2. Of course with no Internet Police to enforce this, the requirement will likely make little difference in practice. > > TLS clients and servers using DANE SHOULD support the > > "Server Name Indication" (SNI) extension of TLS. > > Under what circumstances would it be reasonable for a DANE/TLSA server not > to support SNI? Maybe I could see that a single domain server could do > without it. That's the primary use case, a server with a single certificate, and a "3 1 1" TLSA record has no need to support SNI. It can just respond with the same default certificate, regardless of the SNI extension value sent by the client. > I think this needs to be spelt out - earlier text seems to > indicate that SNI support was pretty much mandatory.... Ah! Later I see that > s5.1 gives a case where SNI is not mandatory - a forward pointer would help. Thanks, will try to make the text more consistent throughout. > s4.1: I am not clear that this section adds any value to the discussion in > s4. Why should the protocol designer be less inclined to use PKIX-xx rather > than DANE-xx when the protocol supports an OS mode as opposed to just fully > authenticated or fully authenticated plus cleartext modes? The basic principle is based on RFC7435. The issue is that PKIX is more brittle, the client and server must happen to agree on a mutually trusted CA, but with OS the client is just trying to protect the communication at the request of the server, and would otherwise be willing to use cleartext or unauthenticated TLS. Use of fragile mechanisms (like public CA authentication for some unspecified set of trusted CAs) is not sufficiently reliable. Since the OS client is basing the decision to employ DANE on the presence of TLSA RRs in DNS, no additional security is gained via the PKIX usages unless they are the only ones supported by the application protocol (the attacker who compromises DNS can just inject "3 1 1" records instead). So DANE-xx is more reliable at no security loss. Thus PKIX-xx is just a needless opportunity to fail that should be avoided. > Nits/editorial comments: > ===================== Will review those... thanks. > s17.2: I can't decide whether I would like RFC6781 to be normative. It would > of course be a downref. This is always going to be a problem since the > draft is combining operational considerations and protocol updates. The > one explicit reference indicates you have to know something about how to run > DNSSEC to run DANE - in practice I think you have to know a great deal about > how to run DNSSEC if you are going to run DANE so I would be inclined to > make this normative (and maybe refer to it in the introduction as well). Not sure what if anything to do about that. -- Viktor. From nobody Mon Jun 22 13:25:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FF01AD072 for ; Mon, 22 Jun 2015 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU-nAK_UevqN for ; Mon, 22 Jun 2015 13:25:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CD41AD06D for ; Mon, 22 Jun 2015 13:25:29 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53303 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z78HY-0005qz-Lf for saag@ietf.org; Mon, 22 Jun 2015 16:25:28 -0400 Message-ID: <55886F38.4030906@bbn.com> Date: Mon, 22 Jun 2015 16:25:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: saag@ietf.org References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> In-Reply-To: <55844743.4030300@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:25:31 -0000 Stephen, > ... > > So even if thing-X is required by some local regulator, that does not > by itself mean that the IETF needs to care about thing-X. > > I'm sure this is familiar to many long time IETF participants, but it > may well not be commonly understood by some others who would consider > the argument Kevin makes above as a winning argument. On purely technical grounds, an argument for filtering in the "middle" is reasonable. It's much easier for a mobile operator, an ISP, or an enterprise IT organization to perform content filtering at an intermediate point than to try t o do so in every end point device. That's a major reason why enterprise IT folks prefer perimeter firewalls over endpoint firewalls. It's very difficult and expensive to manage (security) software on a large number of user devices, and it's even worse when those devices are diverse (e.g., Windows vs. Mac vs. Lunix or iOS vs. Android, vs. ...). So, from an engineering perspective, the argument about the conflict between end-to-end encryption and operator (including enterprise IT staff) access to traffic is a valid consideration, irrespective of the telecom-regulator argument. Steve From nobody Mon Jun 22 14:12:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1581A8754 for ; Mon, 22 Jun 2015 14:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THzbtuIfvXSD for ; Mon, 22 Jun 2015 14:12:11 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 356B21A1B49 for ; Mon, 22 Jun 2015 14:12:11 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id C20A75940A5; Mon, 22 Jun 2015 14:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gPTZd71F3sl/By RAZxOiuuvCRjo=; b=YYa+A973yRnSPWc6jlS6PCsiYtUXfc0TiJNx9Y1RX8FiGa 4PkrzgaJU/Uz0fTkeWHOd1kIfu0PxIXCX6rrqxQBChnYOkZFrhInKi9US71t3IC1 wNwBzJHPDYHZgxnelKa6VFPTJOCgQbLcU3iCMoDbhlnwXtCqCLoXdSJTLgPSs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id F211559409E; Mon, 22 Jun 2015 14:12:09 -0700 (PDT) Date: Mon, 22 Jun 2015 16:12:08 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20150622211207.GM6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55886F38.4030906@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:12:12 -0000 On Mon, Jun 22, 2015 at 04:25:28PM -0400, Stephen Kent wrote: > On purely technical grounds, an argument for filtering in the "middle" > is reasonable. It's much easier for a mobile operator, [...] > > So, from an engineering perspective, the argument about the conflict > between end-to-end encryption and operator (including enterprise IT > staff) access to traffic is a valid consideration, irrespective of the > telecom-regulator argument. But it isn't just a matter of engineering the protocol. There are security problems involved in making this happen (like: how do you express to the user that there is one (or more!) middle box filtering and/or modifying their traffic? how do users get to opt out? how is scope limited? (e.g., how do you prevent the device/operator from MITMing the user when the user is NOT using the operator's network?)). And anyways, operators already get to do this by simply forcing users to use devices from the operators (modified to have MITM CA trust anchors). What new technology is being requested here, regardless of whether we'd publish it (though the current position as to that is clear: no; but the IETF consensus can always change)? Nico -- From nobody Mon Jun 22 14:24:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350971ACD82 for ; Mon, 22 Jun 2015 14:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0Q8KHBNPaum for ; Mon, 22 Jun 2015 14:24:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965C71AC42D for ; Mon, 22 Jun 2015 14:24:06 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (10.160.96.16) with Microsoft SMTP Server (TLS) id 15.1.195.15; Mon, 22 Jun 2015 21:24:05 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0195.005; Mon, 22 Jun 2015 21:24:04 +0000 From: Christian Huitema To: Nico Williams , Stephen Kent Thread-Topic: [saag] Ubiquitous Encryption: content filtering Thread-Index: AQHQqZyDVZfM/qjQ1ki7JjpGF/YhdJ2zz0uAgAAQJoCAACwngIAE9FYAgAANCgCAAACBMA== Date: Mon, 22 Jun 2015 21:24:04 +0000 Message-ID: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> In-Reply-To: <20150622211207.GM6117@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cryptonector.com; dkim=none (message not signed) header.d=none; x-originating-ip: [131.107.159.254] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0654; 5:Zn2a1XgwQgKIc8tyw5VMHbZETK+ZwbdHBgg91c3ff78ZHDAaKs2cnH5mHawxfxW0HIsLL7vPqB+aqefsdTTKjsPTyCLBZWcPHbB9FE64kNxQCXzzsoiF1npDL7lNLqFb1RQqjwBFVsdVgJDW4tzewg==; 24:YWakQ3E3gn5AhwrjXkDaLPgKPgirmSk/rzq98068ai0wl/DbzyTeIxe7OZIOjOGqQJ79K0WHVEezhutwgxVrD4hURsaIM6+Dh77eoMPqlwY=; 20:bO5jVeCVQN6XP/LwcFCWH41hhejoqKQsh08VIrcw7o6C2pNgYpJfHTBT488J4+mpbxdfLxpJOzvwii+ZSwpwzA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42143001); SRVR:DM2PR0301MB0654; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:DM2PR0301MB0654; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0654; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(54356999)(99286002)(33656002)(2900100001)(92566002)(122556002)(102836002)(77096005)(40100003)(5001770100001)(2950100001)(5001960100002)(62966003)(77156002)(106116001)(2656002)(86362001)(87936001)(46102003)(189998001)(93886004)(76576001)(76176999)(86612001)(5002640100001)(66066001)(5003600100002)(74316001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2015 21:24:04.2495 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0654 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:24:08 -0000 On Monday, June 22, 2015, at 2:12 PM, Nico Williams wrote: > .. > But it isn't just a matter of engineering the protocol. There are securi= ty > problems involved in making this happen (like: how do you express to the = user > that there is one (or more!) middle box filtering and/or modifying their = traffic? > how do users get to opt out? how is scope limited? (e.g., how do you pr= event > the device/operator from MITMing the user when the user is NOT using the > operator's network?)). And that's a good reason for not engineering a specific hole in our protoco= ls! > And anyways, operators already get to do this by simply forcing users to = use > devices from the operators (modified to have MITM CA trust anchors). Except, we really want to close that particular hole, don't we? I don't kno= w which particular combination of caching, logs and third party referrals w= e will end up standardizing, but we have to assume that the security stack = will eventually detect this kind of meddling, and expose it. At a minimum, = this is going to be a significant PR issue for any telco playing that game. Generic content filtering is not compatible with encryption. That's pretty = clear. But if I followed the debates correctly, the actual requirement is s= ite blocking, not generic content filtering. The per site filtering can act= ually be performed without an MITM attack. If the site uses its own IP addr= esses, then the operators can filter those IP addresses. If the site used a= shared address, then the TLS packets contain a clear text SNI, and firewal= l magic could drop these connections. I am not very happy about the clear text SNI, but it does not seem to be go= ing away any time soon. -- Christian Huitema From nobody Mon Jun 22 14:46:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFCA1A01FC for ; Mon, 22 Jun 2015 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHlXkQ3ZOIoR for ; Mon, 22 Jun 2015 14:46:54 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A48A71A011D for ; Mon, 22 Jun 2015 14:46:54 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 7A22D202047; Mon, 22 Jun 2015 14:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=elukEHf2q8dnSI LzaTIIA1eLV/U=; b=WADWvfzFqZjRS3YGnV5h+/fEarQw16FsrOos9ELk25hpcg Wrb/Txn0Q9KInEXZ2Hqdlw+kMugQFf0gwAz+jygkM565hyHRZ4J/PsEcsLU3EhO6 yUb4VuaQoTRpDu2dzdYIBUdxFs9MlwzrJq8LBlrhYWZUWqfEceDKSqUZOg2yk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 866E5202015; Mon, 22 Jun 2015 14:46:53 -0700 (PDT) Date: Mon, 22 Jun 2015 16:46:51 -0500 From: Nico Williams To: Christian Huitema Message-ID: <20150622214650.GN6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:46:55 -0000 On Mon, Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote: > On Monday, June 22, 2015, at 2:12 PM, Nico Williams wrote: > > .. > > But it isn't just a matter of engineering the protocol. There are security > > problems involved in making this happen (like: [...] > > And that's a good reason for not engineering a specific hole in our protocols! Or at least being very careful about it. > > And anyways, operators already get to do this by simply forcing users to use > > devices from the operators (modified to have MITM CA trust anchors). > > Except, we really want to close that particular hole, don't we? I Authorized MITMing is fundamentally a part of any hierarchical distributed, public key authentication system when the user does not have full control of their user agent. We can detect it in some cases when it's unwanted, but if it is "authorized" (by the "owner" of the device) then it's going to happen. All the more reason to ask why we're even discussing this. > don't know which particular combination of caching, logs and third > party referrals we will end up standardizing, but we have to assume > that the security stack will eventually detect this kind of meddling, > and expose it. At a minimum, this is going to be a significant PR > issue for any telco playing that game. Maybe. I assume many operators are doing this now, so whatever PR problems might result from starting to filter, they are in the past for many operators. Nico -- From nobody Mon Jun 22 15:13:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015B1B29D5 for ; Mon, 22 Jun 2015 15:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju3bpUPEhAyW for ; Mon, 22 Jun 2015 15:13:38 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA7B1B29D1 for ; Mon, 22 Jun 2015 15:13:37 -0700 (PDT) Received: by wgck11 with SMTP id k11so25688993wgc.0 for ; Mon, 22 Jun 2015 15:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4fYArviHOypYJbcFNCnzmHiH3AGmwQBd/Wlnow5k834=; b=F99qUYK0ufWYj92VYqiJa4GD9mHQxZnd6oJYUywgbwwLrBW5xEhY2qF6QiSN9cT5oo lNahE/eZr0d4WQ+StXAD+QgmoKBFWgExqre7d/zVPgdaE6A3fMI6K5zWCRXrruYodwEI PsUkqpL9d9okw5FR5sOxoWdQZdafutcBWNxrx643i137ry7v3b/x7VeRrlVPue+yHJkF 0NGYyoMqNURCrokPxAnJgFN4xNclrCY6l40ps12VYB6LIEg2XfsyYo4hTapUCftglnWG /fmxLgPx9x1HjL4ZQJj9NZwy7mdvvfU7eqjugu4GZ4GbxRQz0eQ6sdiJTDWB93bpRCBh LNGw== MIME-Version: 1.0 X-Received: by 10.180.9.111 with SMTP id y15mr35743286wia.18.1435011216657; Mon, 22 Jun 2015 15:13:36 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Mon, 22 Jun 2015 15:13:36 -0700 (PDT) In-Reply-To: <20150622214650.GN6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <20150622214650.GN6117@localhost> Date: Mon, 22 Jun 2015 15:13:36 -0700 Message-ID: From: Ted Hardie To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c24888d1546305192295cb Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 22:13:40 -0000 --001a11c24888d1546305192295cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 22, 2015 at 2:46 PM, Nico Williams wrote: > On Mon, Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote: > > > Authorized MITMing is fundamentally a part of any hierarchical > distributed, public key authentication system when the user does not > have full control of their user agent. We can detect it in some cases > when it's unwanted, but if it is "authorized" (by the "owner" of the > device) then it's going to happen. > > =E2=80=8BI'm a little confused by the quotes around both authorized and own= er in the statement above. If a user has caused her device to use a proxy for a specific protocol by configuration, that user has authorized that proxy's activities. If the user has instead initiated flows with the expectation that they are going to the named service, rather than a proxy, then any monkey in the middle is not authorized by the user. Those activities are taking place to further the interests of other parties. For interception devices in a wireless network, those interests might include inspection of the traffic type so that QoS may be assigned; transcoding; content deletion; content insertion; and so on. All the more reason to ask why we're even discussing this. > > > don't know which particular combination of caching, logs and third > > party referrals we will end up standardizing, but we have to assume > > that the security stack will eventually detect this kind of meddling, > > and expose it. At a minimum, this is going to be a significant PR > > issue for any telco playing that game. > > Maybe. I assume many operators are doing this now, so whatever PR > problems might result from starting to filter, they are in the past for > many operators. > > =E2=80=8BAs others have mentioned, things change when you shift from interc= epting unencrypted channels to intercepting encrypted ones, as you are making a much larger effort to impersonate the service. That may be a difference of degree, but it looks like a difference in kind.=E2=80=8B =E2=80=8Bregards, Ted=E2=80=8B > Nico > -- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11c24888d1546305192295cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 22, 2015 at 2:46 PM= , Nico Williams <nico@cryptonector.com> wrote:
On Mon= , Jun 22, 2015 at 09:24:04PM +0000, Christian Huitema wrote:
>
Authorized MITMing is fundamentally a part of any hierarchical
distributed, public key authentication system when the user does not
have full control of their user agent.=C2=A0We can detect it in some cases<= br>
when it's unwanted, but if it is "authorized" (by the "o= wner" of the
device) then it's going to happen.


=E2=80=8BI'm a little confused by t= he quotes around both authorized and owner in the statement above.=C2=A0 If= a user has caused her device to use a proxy for a specific protocol by con= figuration, that user has authorized that proxy's activities.=C2=A0 If = the user has instead initiated flows with the expectation that they are goi= ng to the named service, rather than a proxy, then any monkey in the middle= is not authorized by the user.=C2=A0

Those activities are taking p= lace to further the interests of other parties.=C2=A0 For interception devi= ces in a wireless network, those interests might include inspection of the = traffic type so that QoS may be assigned; transcoding; content deletion; co= ntent insertion; and so on.=C2=A0

All the more reason to ask why we're even discussing this.

> don't know which particular combination of caching, logs and third=
> party referrals we will end up standardizing, but we have to assume > that the security stack will eventually detect this kind of meddling,<= br> > and expose it. At a minimum, this is going to be a significant PR
> issue for any telco playing that game.

Maybe.=C2=A0 I assume many operators are doing this now, so whatever= PR
problems might result from starting to filter, they are in the past for
many operators.


=E2=80=8BAs others have mentioned, things change when= you shift from intercepting unencrypted channels to intercepting encrypted= ones, as you are making a much larger effort to impersonate the service.= =C2=A0 That may be a difference of degree, but it looks like a difference i= n kind.=E2=80=8B

=E2=80=8Bregards,

Ted=E2=80=8B


=C2=A0
Nico
--

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a11c24888d1546305192295cb-- From nobody Mon Jun 22 15:41:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5721A701D for ; Mon, 22 Jun 2015 15:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfDEMFRQw2c4 for ; Mon, 22 Jun 2015 15:41:29 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98A1A6FFB for ; Mon, 22 Jun 2015 15:41:29 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id DB8112004F4E0; Mon, 22 Jun 2015 15:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AijFMAIizA5hEG x9Om0y7/EfcCM=; b=iOJ1b7+u4Kmzg/2nlzUoJlwz2fQTT94rpZJJR2BBTYCd2k n3CGOv62NsAPXKNdVD2ZiiMxk3uTHbkz5vZ8SJpV7bCOmerKTBAEmhheqmW/Igaq pUvhQYs9RbKlsjHmC+eAKVxzQ/FANfr+LcydnsTow5Nl5I+dc5q45wPZ+Q0gs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 729DA2004F4E7; Mon, 22 Jun 2015 15:41:28 -0700 (PDT) Date: Mon, 22 Jun 2015 17:41:27 -0500 From: Nico Williams To: Ted Hardie Message-ID: <20150622224126.GO6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <20150622214650.GN6117@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 22:41:30 -0000 On Mon, Jun 22, 2015 at 03:13:36PM -0700, Ted Hardie wrote: > On Mon, Jun 22, 2015 at 2:46 PM, Nico Williams > wrote: > > Authorized MITMing is fundamentally a part of any hierarchical > > distributed, public key authentication system when the user does not > > have full control of their user agent. We can detect it in some cases > > > when it's unwanted, but if it is "authorized" (by the "owner" of the > > device) then it's going to happen. > > > > > I'm a little confused by the quotes around both authorized and owner in > the statement above. If a user has caused her device to use a proxy for a > specific protocol by configuration, that user has authorized that proxy's > activities. If the user has instead initiated flows with the expectation > that they are going to the named service, rather than a proxy, then any > monkey in the middle is not authorized by the user. I used scare quotes because who the owner is, and whether the unwanted behavior is authorized may not be obvious at first glance. The user may not be the device's "owner" in some sense. E.g., the device may be locked, thus the user may not have permission to remove MITM CA certs from the device's trust anchors, and so on. The user may have paid for the device and think they are the owner, but effectively they aren't when the device is locked and the vendor and/or operator are contractually (or otherwise legally) free to insert MITM CA certs into the device's trust anchor set. > > Maybe. I assume many operators are doing this now, so whatever PR > > problems might result from starting to filter, they are in the past for > > many operators. > > As others have mentioned, things change when you shift from intercepting > unencrypted channels to intercepting encrypted ones, as you are making a > much larger effort to impersonate the service. That may be a difference of > degree, but it looks like a difference in kind. No doubt! And I don't disagree. I was merely pointing out facts. (Namely: the operators are barking up the wrong tree; they already have the protocol features that they need and are merely [perhaps] missing the tools and/or legal framework to do what they think they are being required to do.) In any case, I agree with Stephen F. that regulated operators aren't likely to get more than they already have because the IETF shouldn't be catering to these needs for all the reasons that Stephen alluded to. (Among others: regulations in different localities may conflict in such a way as to leave the IETF with no clear way forward to satisfy them all.) Nico -- From nobody Mon Jun 22 21:36:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2F1A012D for ; Mon, 22 Jun 2015 21:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLvX8KBzTaRA for ; Mon, 22 Jun 2015 21:36:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2F31A0121 for ; Mon, 22 Jun 2015 21:36:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z7FwP-0006ne-Ok; Tue, 23 Jun 2015 04:36:09 +0000 Date: Tue, 23 Jun 2015 13:36:08 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <55886F38.4030906@bbn.com> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 04:36:15 -0000 > On purely technical grounds, an argument for filtering in the "middle" > is reasonable. It's much easier for a mobile operator, an ISP, or an > enterprise IT organization to perform content filtering at an > intermediate point than to try to do so in every end point device. > That's a major reason why enterprise IT folks prefer perimeter > firewalls over endpoint firewalls. It's very difficult and expensive > to manage (security) software on a large number of user devices, and > it's even worse when those devices are diverse (e.g., Windows vs. Mac > vs. Lunix or iOS vs. Android, vs. ...). and that is working out so well, see OPM disaster can you say soft gooey inside? randy From nobody Mon Jun 22 21:44:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A61A0275 for ; Mon, 22 Jun 2015 21:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MBDxZhmv2E6 for ; Mon, 22 Jun 2015 21:44:31 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159B51A0270 for ; Mon, 22 Jun 2015 21:44:31 -0700 (PDT) Received: by qged89 with SMTP id d89so60051046qge.0 for ; Mon, 22 Jun 2015 21:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/7dOzq8qQK9ZXrj+AoTMNeSBsyndAmhYaqJQc3D5r+M=; b=U2Zmk/nsQMpN0GcmZNUQvJJWLtRpTo0nCYueOtagVswNDwU15eKmXL5982/BenqjWK 3I8T/E6IV/1dhbiwn4axsHG5gpkgaNnA7/IpYwOlTqcdPyTwg2Azek1a1sfaETONE+VY joTd4PKYQ/425Cmx/0HEi9V0CpDolFk/Bl4JQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/7dOzq8qQK9ZXrj+AoTMNeSBsyndAmhYaqJQc3D5r+M=; b=W9pnnkzCPrHTjz4FyGcN0n7rOYNSRVNTtc12UqvsUTbtCoCiyMJGKFkIZvFQ/n43O/ Tpx6q+VJBGQaqmu6fKKoI6dV5Wl9gtAUYuvl7n1R2DPyBXVcT412mSEclbWqM2mMwFGD WUcsa9gSaFeDhHNssaY4tjyqO34pL1vxfd8WjE/F/pFTC37KxaLWGS6jOcT7Ay37Ix9h xPCSNTt38X9lK7p9u1CoNK7e/dG4z+/CGyQ40eTXrvG7m9+9pb/rwN2BOWavkyfGhsGx lKoZT042KKj/lLfSXoYCG7ACdYU7jSuNdQROWbFdLrlVV+SbovQKLzlewvq3MmX/Lmgq iSGA== X-Gm-Message-State: ALoCoQlO7hi+UJz0OOb04oqAy79aOxkwD4jHqXmXEqrTvG4gOwC/RtRarOXy2yKlqVap65KS5ZPu X-Received: by 10.55.56.213 with SMTP id f204mr69622899qka.78.1435034670308; Mon, 22 Jun 2015 21:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.51.103 with HTTP; Mon, 22 Jun 2015 21:44:10 -0700 (PDT) In-Reply-To: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> From: Tom Ritter Date: Mon, 22 Jun 2015 23:44:10 -0500 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 04:44:32 -0000 On 22 June 2015 at 16:24, Christian Huitema wrote: > If the site used a shared address, then the TLS packets contain a clear text SNI, and firewall magic could drop these connections. > > I am not very happy about the clear text SNI, but it does not seem to be going away any time soon. Many of us aren't, as it's been used at the nation level for censorship. We're working on TLS 1.3, and our hope now is that it will have the capability to do encrypted SNI through the use of pre-shared keys provided over (e.g.) DNS or a prior connection. DNS leaks it also, but it's already possible to configure a local unbound instance to talk to a remote resolver over TLS; so that protocol a way forward for DNS Privacy (which is also being worked on) that already has some running code. -tom From nobody Tue Jun 23 01:47:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753801A9238 for ; Tue, 23 Jun 2015 01:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HX9lT1MDYX3 for ; Tue, 23 Jun 2015 01:47:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::604]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB46D1A9239 for ; Tue, 23 Jun 2015 01:47:29 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1036.eurprd04.prod.outlook.com (10.162.26.145) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 08:47:13 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 08:47:13 +0000 From: Natasha Rooney To: Tom Ritter Thread-Topic: [saag] Ubiquitous Encryption: content filtering Thread-Index: AQHQqZyD4d9shmwZoUiA42dbZLPz/J2zz0uAgAAQJoCAACwngIAE9FYAgAANCgCAAANWAIAAevYAgABD5wA= Date: Tue, 23 Jun 2015 08:47:13 +0000 Message-ID: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ritter.vg; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.31.90.49] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1036; 5:bNVPZx87pEiIXPI6h1V9XNpiFLmrWSDvIeUNGiZ6BB7Fxf2bzHPX5+oTVU0XHLJ0RugufdclWgkDdurMtG3180Q+bMxbHFpYpc3q6JxCbHPlZN1j0i13Jakz6h1a54uwv94QTIDfOuqdTNj4qbrnpg==; 24:1XJCdcIvAm5e/ATnjuxIhEpB+NEc+wHhEmNV4rt3KDe6L8UMzBIC7WQzrEgXlbBx+l689ln/XMb+/5OhVKVy+gfAZABGo4Q7lsvXjuUNKXk=; 20:aczuh0QSm8S8kKWGVJCHSxmLnnGNO6M1CvgvYce+oJu3Ps2RIGp9tn86rTEFsz/lvNlt54cY5UTSZglHiNdeYA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:HE1PR04MB1036; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1036; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(5890100001)(50226001)(46102003)(93886004)(16236675004)(62966003)(122556002)(77156002)(83716003)(66066001)(189998001)(102836002)(110136002)(2900100001)(77096005)(5001960100002)(2950100001)(15975445007)(106116001)(82746002)(19617315012)(33656002)(57306001)(87936001)(2656002)(76176999)(92566002)(40100003)(5002640100001)(36756003)(19580405001)(86362001)(19580395003)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1036; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_DE85F7A6A8F648FA8AAAEF8ECE17B73Egsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 08:47:13.7066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1036 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 212.31.90.49 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1036.eurprd04.prod.outlook.com Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 08:47:40 -0000 --_000_DE85F7A6A8F648FA8AAAEF8ECE17B73Egsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGd1eXMgZm9yIHRoaXMgLSBhbmQgc29ycnkgZm9yIHRoZSBvbi1saXN0IHRlY2ggY2hl Y2s6IGJ1dCwgaXNu4oCZdCBTTkkgY29uZmlndXJlZCBieSB0aGUgY29udGVudCBzZXJ2ZXIuIFNv LCBpZiBJIGhhdmUgcnVuIGh0dHBzOi8vZXZpbC5jb20sIGNhbuKAmXQgSSBqdXN0LCBub3QgdXNl IFNOST8NCg0KTmF0YXNoYQ0KDQoNCk5hdGFzaGEgUm9vbmV5IHwgV2ViIFRlY2hub2xvZ2lzdCB8 IEdTTUEgfCBucm9vbmV5QGdzbWEuY29tPG1haWx0bzpucm9vbmV5QGdzbWEuY29tPiB8ICs0NCAo MCkgNzczMCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6IG5yb29uZXlAZ3NtLm9yZzxt YWlsdG86bnJvb25leUBnc20ub3JnPg0KVG9reW8sIEphcGFuDQoNCg0KT24gSnVuIDIzLCAyMDE1 LCBhdCA2OjQ0IEFNLCBUb20gUml0dGVyIDx0b21Acml0dGVyLnZnPG1haWx0bzp0b21Acml0dGVy LnZnPj4gd3JvdGU6DQoNCk9uIDIyIEp1bmUgMjAxNSBhdCAxNjoyNCwgQ2hyaXN0aWFuIEh1aXRl bWEgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbTxtYWlsdG86aHVpdGVtYUBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpJZiB0aGUgc2l0ZSB1c2VkIGEgc2hhcmVkIGFkZHJlc3MsIHRoZW4gdGhlIFRMUyBw YWNrZXRzIGNvbnRhaW4gYSBjbGVhciB0ZXh0IFNOSSwgYW5kIGZpcmV3YWxsIG1hZ2ljIGNvdWxk IGRyb3AgdGhlc2UgY29ubmVjdGlvbnMuDQoNCkkgYW0gbm90IHZlcnkgaGFwcHkgYWJvdXQgdGhl IGNsZWFyIHRleHQgU05JLCBidXQgaXQgZG9lcyBub3Qgc2VlbSB0byBiZSBnb2luZyBhd2F5IGFu eSB0aW1lIHNvb24uDQoNCk1hbnkgb2YgdXMgYXJlbid0LCBhcyBpdCdzIGJlZW4gdXNlZCBhdCB0 aGUgbmF0aW9uIGxldmVsIGZvcg0KY2Vuc29yc2hpcC4gV2UncmUgd29ya2luZyBvbiBUTFMgMS4z LCBhbmQgb3VyIGhvcGUgbm93IGlzIHRoYXQgaXQgd2lsbA0KaGF2ZSB0aGUgY2FwYWJpbGl0eSB0 byBkbyBlbmNyeXB0ZWQgU05JIHRocm91Z2ggdGhlIHVzZSBvZiBwcmUtc2hhcmVkDQprZXlzIHBy b3ZpZGVkIG92ZXIgKGUuZy4pIEROUyBvciBhIHByaW9yIGNvbm5lY3Rpb24uDQoNCkROUyBsZWFr cyBpdCBhbHNvLCBidXQgaXQncyBhbHJlYWR5IHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSBhIGxvY2Fs DQp1bmJvdW5kIGluc3RhbmNlIHRvIHRhbGsgdG8gYSByZW1vdGUgcmVzb2x2ZXIgb3ZlciBUTFM7 IHNvIHRoYXQNCnByb3RvY29sIGEgd2F5IGZvcndhcmQgZm9yIEROUyBQcml2YWN5ICh3aGljaCBp cyBhbHNvIGJlaW5nIHdvcmtlZCBvbikNCnRoYXQgYWxyZWFkeSBoYXMgc29tZSBydW5uaW5nIGNv ZGUuDQoNCi10b20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQoNCg0KVGhp cyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5h bWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlv dSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVz dCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBl bWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuDQo= --_000_DE85F7A6A8F648FA8AAAEF8ECE17B73Egsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: <1A0AD171CD895B47AB3E7A1A5098980F@eurprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIGd1eXMgZm9yIHRoaXMg LSBhbmQgc29ycnkgZm9yIHRoZSBvbi1saXN0IHRlY2ggY2hlY2s6IGJ1dCwgaXNu4oCZdCBTTkkg Y29uZmlndXJlZCBieSB0aGUgY29udGVudCBzZXJ2ZXIuIFNvLCBpZiBJIGhhdmUgcnVuDQo8YSBo cmVmPSJodHRwczovL2V2aWwuY29tIiBjbGFzcz0iIj5odHRwczovL2V2aWwuY29tPC9hPiwgY2Fu 4oCZdCBJIGp1c3QsIG5vdCB1c2UgU05JPzxiciBjbGFzcz0iIj4NCjxkaXYgYXBwbGUtY29udGVu dC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFdlYiBU ZWNobm9sb2dpc3QgfCZuYnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNv bSIgY2xhc3M9IiI+DQpucm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDApJm5ic3A7Nzcz MCAyMTkgNzY1IHwgQHRoaXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5y b29uZXlAZ3NtLm9yZyIgY2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBjbGFz cz0iIj4NClRva3lvLCBKYXBhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiBKdW4gMjMsIDIwMTUsIGF0IDY6NDQgQU0sIFRvbSBSaXR0ZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzp0b21Acml0dGVyLnZnIiBjbGFzcz0iIj50b21Acml0dGVyLnZnPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj5PbiAyMiBKdW5lIDIwMTUgYXQgMTY6MjQsIENocmlzdGlhbiBIdWl0 ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBtaWNyb3NvZnQuY29tIiBjbGFzcz0iIj5o dWl0ZW1hQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5JZiB0aGUgc2l0ZSB1c2VkIGEgc2hhcmVkIGFkZHJl c3MsIHRoZW4gdGhlIFRMUyBwYWNrZXRzIGNvbnRhaW4gYSBjbGVhciB0ZXh0IFNOSSwgYW5kIGZp cmV3YWxsIG1hZ2ljIGNvdWxkIGRyb3AgdGhlc2UgY29ubmVjdGlvbnMuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSBhbSBub3QgdmVyeSBoYXBweSBhYm91dCB0aGUgY2xlYXIgdGV4dCBT TkksIGJ1dCBpdCBkb2VzIG5vdCBzZWVtIHRvIGJlIGdvaW5nIGF3YXkgYW55IHRpbWUgc29vbi48 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpNYW55IG9mIHVzIGFy ZW4ndCwgYXMgaXQncyBiZWVuIHVzZWQgYXQgdGhlIG5hdGlvbiBsZXZlbCBmb3I8YnIgY2xhc3M9 IiI+DQpjZW5zb3JzaGlwLiBXZSdyZSB3b3JraW5nIG9uIFRMUyAxLjMsIGFuZCBvdXIgaG9wZSBu b3cgaXMgdGhhdCBpdCB3aWxsPGJyIGNsYXNzPSIiPg0KaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBk byBlbmNyeXB0ZWQgU05JIHRocm91Z2ggdGhlIHVzZSBvZiBwcmUtc2hhcmVkPGJyIGNsYXNzPSIi Pg0Ka2V5cyBwcm92aWRlZCBvdmVyIChlLmcuKSBETlMgb3IgYSBwcmlvciBjb25uZWN0aW9uLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkROUyBsZWFrcyBpdCBhbHNvLCBidXQgaXQncyBh bHJlYWR5IHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSBhIGxvY2FsPGJyIGNsYXNzPSIiPg0KdW5ib3Vu ZCBpbnN0YW5jZSB0byB0YWxrIHRvIGEgcmVtb3RlIHJlc29sdmVyIG92ZXIgVExTOyBzbyB0aGF0 PGJyIGNsYXNzPSIiPg0KcHJvdG9jb2wgYSB3YXkgZm9yd2FyZCBmb3IgRE5TIFByaXZhY3kgKHdo aWNoIGlzIGFsc28gYmVpbmcgd29ya2VkIG9uKTxiciBjbGFzcz0iIj4NCnRoYXQgYWxyZWFkeSBo YXMgc29tZSBydW5uaW5nIGNvZGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLXRvbTxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9yZyIgY2xhc3M9IiI+c2FhZ0BpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NhYWc8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2ZvbnQt c2l6ZToxMXB4O2NvbG9yOiM5OTk5OTk7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmO2NvbG9yOiM5OTk5OTk7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiBBcmlhbDsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItbGF0aW47IG1zby1i aWRpLWZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVO LVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tR0I7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1T QSI+VGhpcw0KIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUg YWJvdmUgbmFtZWQgb25seSBhbmQgbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhleSBoYXZlIGNv bWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8gYWN0aW9uIGJhc2VkIG9uIHRoZW0s IG5vciBtdXN0IHlvdSBjb3B5IG9yIHNob3cgdGhlbSB0byBhbnlvbmU7IHBsZWFzZSByZXBseSB0 byB0aGlzIGVtYWlsIG9yIGNhbGwgJiM0Mzs0NCAyMDcgMzU2IDA2MDANCiBhbmQgaGlnaGxpZ2h0 IHRoZSBlcnJvci4gPC9zcGFuPjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DE85F7A6A8F648FA8AAAEF8ECE17B73Egsmacom_-- From nobody Tue Jun 23 01:59:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883741A92B3 for ; Tue, 23 Jun 2015 01:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0cfn7iVznRn for ; Tue, 23 Jun 2015 01:59:05 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589581A92B8 for ; Tue, 23 Jun 2015 01:59:05 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so9766485wic.0 for ; Tue, 23 Jun 2015 01:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bk6g1hOODlVS6DYZ77XI7rUEKE5cBynwNq7ALvIfdnA=; b=prd/JSMDoHQbEmj1TpQTVhVxEzxzGtu0TV0wggcnUVSiZiWNvVoK50K2oGRQtdFRzH MYhdsPxCWQln5ljpn1JoEsmLPEmRzEc/+W4TqfTMm9zjgxdzGgcMIiyggIIkCFqsJdAI sqOCy4R0hVQPTj/uYkw0V5qrXrn85eka/6/uQFeLFzEht4NKJA4WVsuwBcOmJwKpvVQo dxLbshhez1BaiG0sknHK9aZk3JiM0qHa0fgyjKaXU9K+UlrjuKrzSZKEOJEivQA2nQBQ c2Nz1AyhoNOh4q2HdZbitAx67mc78+bgRTmZ2kuymVnHPkVdcFyXuHJ3T+o2mrGaba7V tSWg== MIME-Version: 1.0 X-Received: by 10.180.106.73 with SMTP id gs9mr1404267wib.1.1435049944046; Tue, 23 Jun 2015 01:59:04 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Tue, 23 Jun 2015 01:59:03 -0700 (PDT) In-Reply-To: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> Date: Tue, 23 Jun 2015 04:59:03 -0400 Message-ID: From: Kathleen Moriarty To: Natasha Rooney Content-Type: multipart/alternative; boundary=f46d04428fce265f7205192b9a6e Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 08:59:07 -0000 --f46d04428fce265f7205192b9a6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the discussion on this, it's helpful to get this right for documentation purposes. I'd split out MiTM activities of this sort for enterprises vs. the same done at the service provider level because of employee agreements. I also choose not to go to many sites from behind a firewall and hope others do too when signaled that there is a certificate mismatch. On Tue, Jun 23, 2015 at 4:47 AM, Natasha Rooney wrote: > Thanks guys for this - and sorry for the on-list tech check: but, isn=E2= =80=99t > SNI configured by the content server. So, if I have run https://evil.com, > can=E2=80=99t I just, not use SNI? > > Natasha > > > Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan > > > On Jun 23, 2015, at 6:44 AM, Tom Ritter wrote: > > On 22 June 2015 at 16:24, Christian Huitema wrote= : > > If the site used a shared address, then the TLS packets contain a clear > text SNI, and firewall magic could drop these connections. > > I am not very happy about the clear text SNI, but it does not seem to be > going away any time soon. > > > Many of us aren't, as it's been used at the nation level for > censorship. We're working on TLS 1.3, and our hope now is that it will > have the capability to do encrypted SNI through the use of pre-shared > keys provided over (e.g.) DNS or a prior connection. > > DNS leaks it also, but it's already possible to configure a local > unbound instance to talk to a remote resolver over TLS; so that > protocol a way forward for DNS Privacy (which is also being worked on) > that already has some running code. > > -tom > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > This email and its attachments are intended for the above named only and > may be confidential. If they have come to you in error you must take no > action based on them, nor must you copy or show them to anyone; please > reply to this email or call +44 207 356 0600 and highlight the error. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --=20 Best regards, Kathleen --f46d04428fce265f7205192b9a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the discussion on this, it's helpful to get= this right for documentation purposes.=C2=A0 I'd split out MiTM activi= ties of this sort for enterprises vs. the same done at the service provider= level because of employee agreements.=C2=A0 I also choose not to go to man= y sites from behind a firewall and hope others do too when signaled that th= ere is a certificate mismatch.

On Tue, Jun 23, 2015 at 4:47 AM, Natasha Rooney <nrooney= @gsma.com> wrote:
Thanks guys for this - and sorry for the on-list tech check: but, isn=E2=80= =99t SNI configured by the content server. So, if I have run https://evil.com, can=E2= =80=99t I just, not use SNI?

Natasha


Natasha Rooney | Web Technologist |=C2=A0GSMA | nrooney@gsma.com | +44 (0)=C2=A07730 219 765 |= @thisNatasha | Skype:=C2=A0nrooney@gsm.org=C2=A0
Tokyo, Japan


On Jun 23, 2015, at 6:44 AM, Tom Ritter <tom@ritter.vg> wrote:

On 22 June 2015 at 16:24, Christian Huitema <huitema@microsoft.com> wrote:
If the site used a shared address, then the TLS p= ackets contain a clear text SNI, and firewall magic could drop these connec= tions.

I am not very happy about the clear text SNI, but it does not seem to be go= ing away any time soon.

Many of us aren't, as it's been used at the nation level for
censorship. We're working on TLS 1.3, and our hope now is that it will<= br> have the capability to do encrypted SNI through the use of pre-shared
keys provided over (e.g.) DNS or a prior connection.

DNS leaks it also, but it's already possible to configure a local
unbound instance to talk to a remote resolver over TLS; so that
protocol a way forward for DNS Privacy (which is also being worked on)
that already has some running code.

-tom

_______________________________________________
saag mailing list
saag@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/saag

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag




--

Best regards,
Ka= thleen
--f46d04428fce265f7205192b9a6e-- From nobody Tue Jun 23 02:20:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00C1AC3BC for ; Tue, 23 Jun 2015 02:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdtOJpjv6Zui for ; Tue, 23 Jun 2015 02:20:46 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A254D1AC3B8 for ; Tue, 23 Jun 2015 02:20:45 -0700 (PDT) Received: by wiwl6 with SMTP id l6so60314830wiw.0 for ; Tue, 23 Jun 2015 02:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Sbu+MSuxDq1fAtgxqvAWVaF9/Er0EaPsGbXDrhROCI=; b=SHE6C1r7nJ+o6TOrk03LdfDICdiRvQ4E8ImyI6U9jP9LZr2/E4xP7PYZJGCfBdE63Q w+EOXGmNHVgH1spIoc8cL0E7WmsXbpyO+qfA7iGgCOKLQ7COfj8SrzPfwvAS7mDa74iv UTSlxcN+o9e7d5eNaqdTxpOfpp5Mnwh6f6CTm/YcHRhYbvLE0yI4oErvjSlEvzEnZy29 u843c7TseH+ApKdWdVY6C7GxEnqiUdmXjmDigbMBKyHH3/jB7w3hYkiNZZ1my8Xolftm JUIarGmkUMT+HBkGpyYEibHBmP/3uvPVE7LMkMKv2UdP1LZFIcRK8VZG1pW6ZnXKma3n A7xg== X-Received: by 10.194.61.212 with SMTP id s20mr57991422wjr.18.1435051244428; Tue, 23 Jun 2015 02:20:44 -0700 (PDT) Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id m4sm34710914wjb.37.2015.06.23.02.20.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jun 2015 02:20:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: Date: Tue, 23 Jun 2015 12:20:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <627A7DEB-9BD0-46FA-A4D8-BB448C2BCB16@gmail.com> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 09:20:47 -0000 > On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty = wrote: >=20 > Thanks for the discussion on this, it's helpful to get this right for = documentation purposes. I'd split out MiTM activities of this sort for = enterprises vs. the same done at the service provider level because of = employee agreements. I also choose not to go to many sites from behind = a firewall and hope others do too when signaled that there is a = certificate mismatch. I=E2=80=99m not sure if that distinction is meaningful. The technology = for interception is the same whether it is used to scan downloaded files = for malware or to scan Facebook posts for insufficient appreciation of = our Dear Leader. Employees in a corporate environment are supposedly informed, but = corporate computers and devices may come pre-installed with the = interception certificate. Even as a conscientious vendor, there is no = way I can enforce that corporate IT properly informs the employees.=20 Similarly, we=E2=80=99ve seen interception used at service providers at = the behest of governments. In some countries devices come pre-installed = with the government interception certificate. This makes it transparent = to the citizens. Again, it would be nice if citizens at least knew this = was happening, but those governments tend to not be =E2=80=9Cnice=E2=80=9D= . At least ISPs don=E2=80=99t have the power to manipulate the = endpoints (though in the early days of broadband they would ask you to = install a =E2=80=9Cdialer=E2=80=9D - if I were a more suspicious = person=E2=80=A6), but they do when they work for the government.=20 Ideally a solution would reveal the presence of a MITM to both client = and server. All solutions discussed thus far can reveal things to the = client, but do nothing for the server. I would like to have servers such = as financial institutions and medical services be able to enforce a = policy where they don=E2=80=99t provide a service through a middlebox. = Doing it now requires installing their own client on the user=E2=80=99s = machine, which seems to be a trend in mobile, but is not something we = should require. Yoav= From nobody Tue Jun 23 02:48:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C50E1AC40B for ; Tue, 23 Jun 2015 02:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyoGEAZmIi8U for ; Tue, 23 Jun 2015 02:48:46 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6F31AC405 for ; Tue, 23 Jun 2015 02:48:45 -0700 (PDT) Received: by wiga1 with SMTP id a1so100854282wig.0 for ; Tue, 23 Jun 2015 02:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MIG4iBuxUN6if6MivfXk6jc089pvYjHQ+KZr5uDDAUg=; b=M+yXSYYW0ZkUjYLMhuCnBkVPKlOBb0stcawx5AfZjJ+vcdu05BiTtVXH54tghCMaqS H6OYwfz74KSQocPpx8MQIfFNkdMRoHxpoa5pRMtTQMIiGE8m3iE7jr8vU6I+yZ8VViQ1 Cw2yh6kG3jGMJkL9h+cD1X+B6nRMx0oDXt+LZcznLdYcm1VwB7yuAiVPPEGF09QBqPJL 2QG0nSdkF/j59O5Ft1vmkT3mjyR4d9HxDR1cXQMF1immXhmQuMh3K0PMgeaCoG3SYHso lBHFsrk4HFep+/qKuMBg8EO47CiaYg3v9wxGUonEXGVJzwZ5bZ2UMgEK8DZ/iVyobzP5 9HmQ== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr1789238wiz.78.1435052924373; Tue, 23 Jun 2015 02:48:44 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Tue, 23 Jun 2015 02:48:44 -0700 (PDT) In-Reply-To: <627A7DEB-9BD0-46FA-A4D8-BB448C2BCB16@gmail.com> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <627A7DEB-9BD0-46FA-A4D8-BB448C2BCB16@gmail.com> Date: Tue, 23 Jun 2015 05:48:44 -0400 Message-ID: From: Kathleen Moriarty To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d0442806eca90b705192c4b70 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 09:48:48 -0000 --f46d0442806eca90b705192c4b70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2015 at 5:20 AM, Yoav Nir wrote: > > > On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Thanks for the discussion on this, it's helpful to get this right for > documentation purposes. I'd split out MiTM activities of this sort for > enterprises vs. the same done at the service provider level because of > employee agreements. I also choose not to go to many sites from behind a > firewall and hope others do too when signaled that there is a certificate > mismatch. > > I=E2=80=99m not sure if that distinction is meaningful. The technology fo= r > interception is the same whether it is used to scan downloaded files for > malware or to scan Facebook posts for insufficient appreciation of our De= ar > Leader. > Sure, I'm aware the same technique is sometimes used for both scenarios, but not always. It's easy for a company with an agreement to set up a proxy that has 2 TLS sessions, one between the user and proxy and the other from the proxy to the destination site. Other techniques have been used (see UTA's TLS attack RFC - 7457) at the service provider level, including stopping the STARTTLS negotiation. Some have used techniques that are less visible to the user. As problems are fixed in the protocol, what is done shifts of course. > Employees in a corporate environment are supposedly informed, but > corporate computers and devices may come pre-installed with the > interception certificate. Even as a conscientious vendor, there is no way= I > can enforce that corporate IT properly informs the employees. > I'm sure this varies between regions. I just think enterprises can be more deliberate about it with user agreements and not worry about error messages. Sure, the sam thing can be done in a pre-installed way, but a user can check the certs if they know enough. > > Similarly, we=E2=80=99ve seen interception used at service providers at t= he behest > of governments. In some countries devices come pre-installed with the > government interception certificate. This makes it transparent to the > citizens. Again, it would be nice if citizens at least knew this was > happening, but those governments tend to not be =E2=80=9Cnice=E2=80=9D. = At least ISPs > don=E2=80=99t have the power to manipulate the endpoints (though in the e= arly days > of broadband they would ask you to install a =E2=80=9Cdialer=E2=80=9D - i= f I were a more > suspicious person=E2=80=A6), but they do when they work for the governmen= t. > Yes and that's scary. I think the distinction is acceptability of the approach in environments like work, since your time is paid for. Documenting this in two stages would be good as approaches to resolve may be different. The TLS 1.3 work to use pre-shared keys negotiated via DNS should certainly help on this angle. Enterprises may choose to block access to some sites, where other options might be used by governments or others trying to MiTM traffic. > > Ideally a solution would reveal the presence of a MITM to both client and > server. That would be good. > All solutions discussed thus far can reveal things to the client, but do > nothing for the server. I would like to have servers such as financial > institutions and medical services be able to enforce a policy where they > don=E2=80=99t provide a service through a middlebox. Doing it now require= s > installing their own client on the user=E2=80=99s machine, which seems to= be a > trend in mobile, but is not something we should require. > > Yoav Thanks, Katheen --=20 Best regards, Kathleen --f46d0442806eca90b705192c4b70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 23, 2015 at 5:20 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On Jun 23, 2015, at 11:59 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> = wrote:
>
> Thanks for the discussion on this, it's helpful to get this right = for documentation purposes.=C2=A0 I'd split out MiTM activities of this= sort for enterprises vs. the same done at the service provider level becau= se of employee agreements.=C2=A0 I also choose not to go to many sites from= behind a firewall and hope others do too when signaled that there is a cer= tificate mismatch.

I=E2=80=99m not sure if that distinction is meaningful. The technolo= gy for interception is the same whether it is used to scan downloaded files= for malware or to scan Facebook posts for insufficient appreciation of our= Dear Leader.

Sure, I'm aware the s= ame technique is sometimes used for both scenarios, but not always.=C2=A0 I= t's easy for a company with an agreement to set up a proxy that has 2 T= LS sessions, one between the user and proxy and the other from the proxy to= the destination site.=C2=A0 Other techniques have been used (see UTA's= TLS attack RFC - 7457) at the service provider level, including stopping t= he STARTTLS negotiation.

Some have used techniques= that are less visible to the user.=C2=A0 As problems are fixed in the prot= ocol, what is done shifts of course.



Employees in a corporate environment are supposedly informed, but corporate= computers and devices may come pre-installed with the interception certifi= cate. Even as a conscientious vendor, there is no way I can enforce that co= rporate IT properly informs the employees.

<= div>I'm sure this varies between regions.=C2=A0 I just think enterprise= s can be more deliberate about it with user agreements and not worry about = error messages.=C2=A0 Sure, the sam thing can be done in a pre-installed wa= y, but a user can check the certs if they know enough.
=C2=A0

Similarly, we=E2=80=99ve seen interception used at service providers at the= behest of governments. In some countries devices come pre-installed with t= he government interception certificate. This makes it transparent to the ci= tizens. Again, it would be nice if citizens at least knew this was happenin= g, but those governments tend to not be =E2=80=9Cnice=E2=80=9D.=C2=A0 At le= ast ISPs don=E2=80=99t have the power to manipulate the endpoints (though i= n the early days of broadband they would ask you to install a =E2=80=9Cdial= er=E2=80=9D - if I were a more suspicious person=E2=80=A6), but they do whe= n they work for the government.

Yes and= that's scary.=C2=A0 I think the distinction is acceptability of the ap= proach in environments like work, since your time is paid for.=C2=A0 Docume= nting this in two stages would be good as approaches to resolve may be diff= erent.=C2=A0 The TLS 1.3 work to use pre-shared keys negotiated via DNS sho= uld certainly help on this angle.=C2=A0 Enterprises may choose to block acc= ess to some sites, where other options might be used by governments or othe= rs trying to MiTM traffic.
=C2=A0

Ideally a solution would reveal the presence of a MITM to both client and s= erver.

That would be good.=C2=A0
All solutions discussed thus far can reveal things to the clie= nt, but do nothing for the server. I would like to have servers such as fin= ancial institutions and medical services be able to enforce a policy where = they don=E2=80=99t provide a service through a middlebox. Doing it now requ= ires installing their own client on the user=E2=80=99s machine, which seems= to be a trend in mobile, but is not something we should require.

Yoav

Thanks,
Kathee= n=C2=A0



--

Best regards,
Kath= leen
--f46d0442806eca90b705192c4b70-- From nobody Tue Jun 23 05:32:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B19D1A000A for ; Tue, 23 Jun 2015 05:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcYUjXpoEC-O for ; Tue, 23 Jun 2015 05:32:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0651.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::651]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE82B1A0004 for ; Tue, 23 Jun 2015 05:32:39 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 12:32:23 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 12:32:23 +0000 From: Natasha Rooney To: saag Thread-Topic: [saag] Ubiquitous Encryption: content filtering Thread-Index: AQHQqZyD4d9shmwZoUiA42dbZLPz/J2zz0uAgAAQJoCAACwngIAE9FYAgAANCgCAAANWAIAAevYAgABD5wCAAANQgIAABgoAgAAH1wCAAC24AA== Date: Tue, 23 Jun 2015 12:32:23 +0000 Message-ID: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <627A7DEB-9BD0-46FA-A4D8-BB448C2BCB16@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.31.90.49] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:+EgLiHdLp3s1QUVY+mFdy8AsZ3Lw1ttfZb6N30z7UWVhTJ5sfwB1V/n176S/lDLAE2XBKVhOW12NagMYeYrw2kpjWRIW8PjnQxvRQJDI4YfCHIXpe2kpJIP64k4d7PcLJ4Ttu5RMPthFzUr45e6oMA==; 24:tEqIgIS1YDLCPPxC9Iam/oClOmodaG7xQ8Cia9OBB4mtiJUTtDN3VZuICxbDq1OR2HQfn13BxEap7B6RVtIlLV//l6L8XFCXR3eWOe0N+ZQ=; 20:n3AYCASYqs2P31SP6BAvBUQHj6srgrhIsprs6bann6LRON0YMf36D/lgnYrmIjZsp2rti4NDAi6LgUCFjrQWaw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(51704005)(53754006)(51914003)(24454002)(377454003)(16236675004)(87936001)(2656002)(57306001)(36756003)(5890100001)(102836002)(2950100001)(122556002)(82746002)(50226001)(77096005)(5002640100001)(2900100001)(189998001)(40100003)(92566002)(46102003)(450100001)(77156002)(62966003)(66066001)(110136002)(76176999)(107886002)(5001960100002)(86362001)(93886004)(83716003)(33656002)(19580405001)(50986999)(19580395003)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_A03F39DEEFF04769B21837816296BB02gsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 12:32:23.2008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 212.31.90.49 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1033.eurprd04.prod.outlook.com Archived-At: Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 12:32:44 -0000 --_000_A03F39DEEFF04769B21837816296BB02gsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsIQ0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cyBvbiB0aGlzLiBJIHJld3JvdGUgc29t ZSBpdGVtcyBnaXZlbiBzb21lIGZlZWRiYWNrIEkgcmVjZWl2ZWQgKEpvZTogSSBhbSB3b3JyaWVk IHRoYXQgSSBkaWRu4oCZdCBleHBhbmQgb24geW91ciBwb2ludHMgZW5vdWdoLCBwbGVhc2UgbGV0 IG1lIGtub3cgaWYgSSBzaG91bGQgYWRkIHNvbWV0aGluZyEpOg0KDQoNCjIuMy5YIENvbnRlbnQg RmlsdGVyaW5nDQpTZXJ2aWNlIFByb3ZpZGVycyBtYXksIGZyb20gdGltZSB0byB0aW1lLCBiZSBy ZXF1ZXN0ZWQgYnkgbGF3IGFnZW5jaWVzIHRvIGJsb2NrIGFjY2VzcyB0byBwYXJ0aWN1bGFyIHNp dGVzIHN1Y2ggYXMgb25saW5lIGJldHRpbmcgYW5kIGdhbWJsaW5nLCBzaXRlcyBwcm9tb3Rpbmcg YW5vcmV4aWEsIG9yIGFjY2VzcyB0byBkYXRpbmcgc2l0ZXMuKjEgQ29udGVudCBGaWx0ZXJpbmcg Y2FuIGFsc28gaGFwcGVuIGF0IHRoZSBlbmRwb2ludHMuDQoNCkNvbnRlbnQgZmlsdGVyaW5nIGlu IHRoZSBtb2JpbGUgbmV0d29yayB1c3VhbGx5IG9jY3VycyBpbiB0aGUgY29yZSBuZXR3b3JrLiBB IHByb3h5IGlzIGluc3RhbGxlZCB3aGljaCBhbmFseXNlcyB0aGUgdHJhbnNwb3J0IG1ldGFkYXRh IG9mIHRoZSBjb250ZW50IHVzZXJzIGFyZSB2aWV3aW5nIGFuZCBlaXRoZXIgZmlsdGVycyBjb250 ZW50IGJhc2VkIG9uIGEgYmxhY2tsaXN0IG9mIHNpdGVzIG9yIGJhc2VkIG9uIHRoZSB1c2Vy4oCZ cyBwcmUtZGVmaW5lZCBwcm9maWxlIChlLmcuIGZvciBhZ2Ugc2Vuc2l0aXZlIGNvbnRlbnQpLiBB bHRob3VnaCBmaWx0ZXJpbmcgY2FuIGJlIGRvbmUgYnkgbWFueSBtZXRob2RzIG9uZSBjb21tb24g bWV0aG9kIG9jY3VycyB3aGVuIGEgRE5TIGxvb2t1cCByZXZlYWxzIGEgVVJMIHdoaWNoIGFwcGVh cnMgb24gYSBnb3Zlcm5tZW50IG9yIHJlY29nbmlzZWQgYmxvY2stbGlzdC4gVGhlIHN1YnNlcXVl bnQgcmVxdWVzdHMgdG8gdGhhdCBkb21haW4gd2lsbCBiZSByZS1yb3V0ZWQgdG8gYSBwcm94eSB3 aGljaCBjaGVja3Mgd2hldGhlciB0aGUgZnVsbCB1cmwgbWF0Y2hlcyBhIGJsb2NrZWQgdXJsIG9u IHRoZSBsaXN0LCBhbmQgd2lsbCByZXR1cm4gYSA0MDQgaWYgYSBtYXRjaCBpcyBmb3VuZC4gQWxs IG90aGVyIHJlcXVlc3RzIHNob3VsZCBjb21wbGV0ZS4NCg0KRXZlbiBpbiBlbmNyeXB0ZWQgY29u bmVjdGlvbnMgdHJhbnNwb3J0IGFuZCBsb3dlciBsYXllciBtZXRhZGF0YSBpcyBhYmxlIHRvIGJl IHZpZXdlZCBzbyBmb3IgbWFueSBzeXN0ZW1zIGNvbnRlbnQgZmlsdGVyaW5nIHNob3VsZCBiZSBh YmxlIHRvIGNvbnRpbnVlLiBDYXNlcyB3aGVuIHRoZXkgbWF5IG5vdCB3b3JrIGlzIHdoZW4gVExT IHByb3hpZXMgYXJlIGJlaW5nIHVzZWQgd2hpY2ggb2JzY3VyZSBtZXRhZGF0YSB3aXRoIHRoZSBw cm94eSBtZXRhZGF0YSwgYW5kIGZ1dHVyZSB2ZXJzaW9ucyBpbiBIVFRQIGFuZCBUQ1AgbWF5IGVu Y3J5cHQgbWV0YWRhdGEgYWdhaW4gc3RvcHBpbmcgY29udGVudCBmaWx0ZXJpbmcgc29mdHdhcmUg ZnJvbSB3b3JraW5nICh0aGlzIGlzIGN1cnJlbnRseSBub3QgdGhlIGNhc2UgYW5kIGhhcyBub3Qg YmVlbiBzdGFuZGFyZGlzZWQpLiAqMg0KDQpTb21lIHNpdGVzIGludm9sdmUgYSBtaXh0dXJlIG9m IHVuaXZlcnNhbCBhbmQgYWdlLXNlbnNpdGl2ZSBjb250ZW50IGFuZCBmaWx0ZXJpbmcgc29mdHdh cmUgaW4gdGhlc2UgY2FzZXMgbWF5IHVzZSBtb3JlIGdyYW51bGFyIChhcHBsaWNhdGlvbiBsYXll cikgbWV0YWRhdGEgdG8gYW5hbHlzZSBhbmQgYmxvY2s7IHRoaXMgd2lsbCBub3Qgd29yayBvbiBl bmNyeXB0ZWQgY29udGVudC4NCg0KDQpJIHdhbnRlZCB0byBhZGQgdHdvIG1vcmUgc2VudGVuY2Vz LCBidXQgYW4gSUVURmVyIGdhdmUgbWUgc29tZSBhZHZpY2UgdG9kYXkgdG8gc2F5IHRoYXQgSSBz aG91bGQgb25seSBzdGF0ZSBmYWN0cywgYW5kIG5vdCBhbnkgbGVhZGluZyBvciBwcmVzdW1wdGl2 ZSBpdGVtcywgaW4gc3VjaCBhIHN1Ym1pc3Npb24uIEluIHdoaWNoIGNhc2UgSSByZW1vdmVkIHRo ZXNlIHR3byBzZW50ZW5jZXMsIGJ1dCB5b3UgbWF5IGZpbmQgaXQgYmVuZWZpdCB0byBpbmNsdWRl IHRoZW06DQoNCg0KICAqICAgIlNvbWUgbW9iaWxlIG9wZXJhdG9ycyB1dGlsaXNpbmcgbGljZW5j ZWQgc3BlY3RydW0gbXVzdCBhZGhlcmUgdG8gcmVndWxhdGlvbnMgc2V0IGJ5IHRoZSBnb3Zlcm5t ZW50IGxpY2Vuc29yLCB3aGljaCBpbmNsdWRlIGNvbnRlbnQgZmlsdGVyaW5nLCBvciByaXNrIGZp bmVzL2xpY2VuY2Ugc3VzcGVuc2lvbiIgYXQgKjENCiAgKiAgICJSZWd1bGF0b3JzIHRoYXQgaW1w b3NlIHRoZXNlIGNlbnNvcnNoaXAgcnVsZXMgbWF5IGxvb2sgZm9yIG90aGVyIG1lYW5zIGlmIGN1 cnJlbnQgbWV0aG9kcyBzdG9wIHdvcmtpbmcuIiBhdCAqMi4NCg0KQWxzbywgSSBhbSBoYXBweSBp biBrbm93aW5nIHRoYXQgSUVURiB3b27igJl0IHdvcmsgb24gbWl0aWdhdGluZyBhbnkgc29ydCBv ZiBjZW5zb3JzaGlwLCBqdXN0IHRoYXQgdGhpcyBleGlzdHMgYXMgYSByZWZlcmVuY2UuIEkgYWxz byBsaWtlZCB0aGUgaWRlYSBvZiByZXR1cm5pbmcgaW5mb3JtYXRpb24gdG8gdGhlIHVzZXIgYWJv dXQgd2hhdCBpcyBoYXBwZW5pbmcgc28gdGhleSBjYW4gbWFrZSBkZWNpc2lvbnMgYWJvdXQgdGhl aXIgYnJvd3NlciwgcHJvdmlkZXIsIG9yIHdobyB0aGV54oCZcmUgdm90aW5nIGZvciEgQ29tbWVu dHMgYWx3YXlzIHdlbGNvbWUgLSB0aGFua3MgZm9yIHRoZSByZXNwb25zZXMgc28gZmFyIQ0KDQpO YXRhc2hhDQoNCg0KTmF0YXNoYSBSb29uZXkgfCBXZWIgVGVjaG5vbG9naXN0IHwgR1NNQSB8IG5y b29uZXlAZ3NtYS5jb208bWFpbHRvOm5yb29uZXlAZ3NtYS5jb20+IHwgKzQ0ICgwKSA3NzMwIDIx OSA3NjUgfCBAdGhpc05hdGFzaGEgfCBTa3lwZTogbnJvb25leUBnc20ub3JnPG1haWx0bzpucm9v bmV5QGdzbS5vcmc+DQpUb2t5bywgSmFwYW4NCg0KDQpPbiBKdW4gMjMsIDIwMTUsIGF0IDExOjQ4 IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQpP biBUdWUsIEp1biAyMywgMjAxNSBhdCA1OjIwIEFNLCBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWls LmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQo+IE9uIEp1biAyMywg MjAxNSwgYXQgMTE6NTkgQU0sIEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCj4NCj4gVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzLCBpdCdzIGhlbHBm dWwgdG8gZ2V0IHRoaXMgcmlnaHQgZm9yIGRvY3VtZW50YXRpb24gcHVycG9zZXMuICBJJ2Qgc3Bs aXQgb3V0IE1pVE0gYWN0aXZpdGllcyBvZiB0aGlzIHNvcnQgZm9yIGVudGVycHJpc2VzIHZzLiB0 aGUgc2FtZSBkb25lIGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGxldmVsIGJlY2F1c2Ugb2YgZW1w bG95ZWUgYWdyZWVtZW50cy4gIEkgYWxzbyBjaG9vc2Ugbm90IHRvIGdvIHRvIG1hbnkgc2l0ZXMg ZnJvbSBiZWhpbmQgYSBmaXJld2FsbCBhbmQgaG9wZSBvdGhlcnMgZG8gdG9vIHdoZW4gc2lnbmFs ZWQgdGhhdCB0aGVyZSBpcyBhIGNlcnRpZmljYXRlIG1pc21hdGNoLg0KDQpJ4oCZbSBub3Qgc3Vy ZSBpZiB0aGF0IGRpc3RpbmN0aW9uIGlzIG1lYW5pbmdmdWwuIFRoZSB0ZWNobm9sb2d5IGZvciBp bnRlcmNlcHRpb24gaXMgdGhlIHNhbWUgd2hldGhlciBpdCBpcyB1c2VkIHRvIHNjYW4gZG93bmxv YWRlZCBmaWxlcyBmb3IgbWFsd2FyZSBvciB0byBzY2FuIEZhY2Vib29rIHBvc3RzIGZvciBpbnN1 ZmZpY2llbnQgYXBwcmVjaWF0aW9uIG9mIG91ciBEZWFyIExlYWRlci4NCg0KU3VyZSwgSSdtIGF3 YXJlIHRoZSBzYW1lIHRlY2huaXF1ZSBpcyBzb21ldGltZXMgdXNlZCBmb3IgYm90aCBzY2VuYXJp b3MsIGJ1dCBub3QgYWx3YXlzLiAgSXQncyBlYXN5IGZvciBhIGNvbXBhbnkgd2l0aCBhbiBhZ3Jl ZW1lbnQgdG8gc2V0IHVwIGEgcHJveHkgdGhhdCBoYXMgMiBUTFMgc2Vzc2lvbnMsIG9uZSBiZXR3 ZWVuIHRoZSB1c2VyIGFuZCBwcm94eSBhbmQgdGhlIG90aGVyIGZyb20gdGhlIHByb3h5IHRvIHRo ZSBkZXN0aW5hdGlvbiBzaXRlLiAgT3RoZXIgdGVjaG5pcXVlcyBoYXZlIGJlZW4gdXNlZCAoc2Vl IFVUQSdzIFRMUyBhdHRhY2sgUkZDIC0gNzQ1NykgYXQgdGhlIHNlcnZpY2UgcHJvdmlkZXIgbGV2 ZWwsIGluY2x1ZGluZyBzdG9wcGluZyB0aGUgU1RBUlRUTFMgbmVnb3RpYXRpb24uDQoNClNvbWUg aGF2ZSB1c2VkIHRlY2huaXF1ZXMgdGhhdCBhcmUgbGVzcyB2aXNpYmxlIHRvIHRoZSB1c2VyLiAg QXMgcHJvYmxlbXMgYXJlIGZpeGVkIGluIHRoZSBwcm90b2NvbCwgd2hhdCBpcyBkb25lIHNoaWZ0 cyBvZiBjb3Vyc2UuDQoNCg0KDQpFbXBsb3llZXMgaW4gYSBjb3Jwb3JhdGUgZW52aXJvbm1lbnQg YXJlIHN1cHBvc2VkbHkgaW5mb3JtZWQsIGJ1dCBjb3Jwb3JhdGUgY29tcHV0ZXJzIGFuZCBkZXZp Y2VzIG1heSBjb21lIHByZS1pbnN0YWxsZWQgd2l0aCB0aGUgaW50ZXJjZXB0aW9uIGNlcnRpZmlj YXRlLiBFdmVuIGFzIGEgY29uc2NpZW50aW91cyB2ZW5kb3IsIHRoZXJlIGlzIG5vIHdheSBJIGNh biBlbmZvcmNlIHRoYXQgY29ycG9yYXRlIElUIHByb3Blcmx5IGluZm9ybXMgdGhlIGVtcGxveWVl cy4NCg0KSSdtIHN1cmUgdGhpcyB2YXJpZXMgYmV0d2VlbiByZWdpb25zLiAgSSBqdXN0IHRoaW5r IGVudGVycHJpc2VzIGNhbiBiZSBtb3JlIGRlbGliZXJhdGUgYWJvdXQgaXQgd2l0aCB1c2VyIGFn cmVlbWVudHMgYW5kIG5vdCB3b3JyeSBhYm91dCBlcnJvciBtZXNzYWdlcy4gIFN1cmUsIHRoZSBz YW0gdGhpbmcgY2FuIGJlIGRvbmUgaW4gYSBwcmUtaW5zdGFsbGVkIHdheSwgYnV0IGEgdXNlciBj YW4gY2hlY2sgdGhlIGNlcnRzIGlmIHRoZXkga25vdyBlbm91Z2guDQoNCg0KU2ltaWxhcmx5LCB3 ZeKAmXZlIHNlZW4gaW50ZXJjZXB0aW9uIHVzZWQgYXQgc2VydmljZSBwcm92aWRlcnMgYXQgdGhl IGJlaGVzdCBvZiBnb3Zlcm5tZW50cy4gSW4gc29tZSBjb3VudHJpZXMgZGV2aWNlcyBjb21lIHBy ZS1pbnN0YWxsZWQgd2l0aCB0aGUgZ292ZXJubWVudCBpbnRlcmNlcHRpb24gY2VydGlmaWNhdGUu IFRoaXMgbWFrZXMgaXQgdHJhbnNwYXJlbnQgdG8gdGhlIGNpdGl6ZW5zLiBBZ2FpbiwgaXQgd291 bGQgYmUgbmljZSBpZiBjaXRpemVucyBhdCBsZWFzdCBrbmV3IHRoaXMgd2FzIGhhcHBlbmluZywg YnV0IHRob3NlIGdvdmVybm1lbnRzIHRlbmQgdG8gbm90IGJlIOKAnG5pY2XigJ0uICBBdCBsZWFz dCBJU1BzIGRvbuKAmXQgaGF2ZSB0aGUgcG93ZXIgdG8gbWFuaXB1bGF0ZSB0aGUgZW5kcG9pbnRz ICh0aG91Z2ggaW4gdGhlIGVhcmx5IGRheXMgb2YgYnJvYWRiYW5kIHRoZXkgd291bGQgYXNrIHlv dSB0byBpbnN0YWxsIGEg4oCcZGlhbGVy4oCdIC0gaWYgSSB3ZXJlIGEgbW9yZSBzdXNwaWNpb3Vz IHBlcnNvbuKApiksIGJ1dCB0aGV5IGRvIHdoZW4gdGhleSB3b3JrIGZvciB0aGUgZ292ZXJubWVu dC4NCg0KWWVzIGFuZCB0aGF0J3Mgc2NhcnkuICBJIHRoaW5rIHRoZSBkaXN0aW5jdGlvbiBpcyBh Y2NlcHRhYmlsaXR5IG9mIHRoZSBhcHByb2FjaCBpbiBlbnZpcm9ubWVudHMgbGlrZSB3b3JrLCBz aW5jZSB5b3VyIHRpbWUgaXMgcGFpZCBmb3IuICBEb2N1bWVudGluZyB0aGlzIGluIHR3byBzdGFn ZXMgd291bGQgYmUgZ29vZCBhcyBhcHByb2FjaGVzIHRvIHJlc29sdmUgbWF5IGJlIGRpZmZlcmVu dC4gIFRoZSBUTFMgMS4zIHdvcmsgdG8gdXNlIHByZS1zaGFyZWQga2V5cyBuZWdvdGlhdGVkIHZp YSBETlMgc2hvdWxkIGNlcnRhaW5seSBoZWxwIG9uIHRoaXMgYW5nbGUuICBFbnRlcnByaXNlcyBt YXkgY2hvb3NlIHRvIGJsb2NrIGFjY2VzcyB0byBzb21lIHNpdGVzLCB3aGVyZSBvdGhlciBvcHRp b25zIG1pZ2h0IGJlIHVzZWQgYnkgZ292ZXJubWVudHMgb3Igb3RoZXJzIHRyeWluZyB0byBNaVRN IHRyYWZmaWMuDQoNCg0KSWRlYWxseSBhIHNvbHV0aW9uIHdvdWxkIHJldmVhbCB0aGUgcHJlc2Vu Y2Ugb2YgYSBNSVRNIHRvIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIuDQoNClRoYXQgd291bGQgYmUg Z29vZC4NCkFsbCBzb2x1dGlvbnMgZGlzY3Vzc2VkIHRodXMgZmFyIGNhbiByZXZlYWwgdGhpbmdz IHRvIHRoZSBjbGllbnQsIGJ1dCBkbyBub3RoaW5nIGZvciB0aGUgc2VydmVyLiBJIHdvdWxkIGxp a2UgdG8gaGF2ZSBzZXJ2ZXJzIHN1Y2ggYXMgZmluYW5jaWFsIGluc3RpdHV0aW9ucyBhbmQgbWVk aWNhbCBzZXJ2aWNlcyBiZSBhYmxlIHRvIGVuZm9yY2UgYSBwb2xpY3kgd2hlcmUgdGhleSBkb27i gJl0IHByb3ZpZGUgYSBzZXJ2aWNlIHRocm91Z2ggYSBtaWRkbGVib3guIERvaW5nIGl0IG5vdyBy ZXF1aXJlcyBpbnN0YWxsaW5nIHRoZWlyIG93biBjbGllbnQgb24gdGhlIHVzZXLigJlzIG1hY2hp bmUsIHdoaWNoIHNlZW1zIHRvIGJlIGEgdHJlbmQgaW4gbW9iaWxlLCBidXQgaXMgbm90IHNvbWV0 aGluZyB3ZSBzaG91bGQgcmVxdWlyZS4NCg0KWW9hdg0KDQpUaGFua3MsDQpLYXRoZWVuDQoNCg0K DQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0KDQoNClRoaXMgZW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZCBtYXkg YmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3IgeW91IG11 c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hv dyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQg MjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0K --_000_A03F39DEEFF04769B21837816296BB02gsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgYWxsIQ0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGZvciB0aGUgY29t bWVudHMgb24gdGhpcy4gSSByZXdyb3RlIHNvbWUgaXRlbXMgZ2l2ZW4gc29tZSBmZWVkYmFjayBJ IHJlY2VpdmVkIChKb2U6IEkgYW0gd29ycmllZCB0aGF0IEkgZGlkbuKAmXQgZXhwYW5kIG9uIHlv dXIgcG9pbnRzIGVub3VnaCwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgc2hvdWxkIGFkZCBzb21l dGhpbmchKTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEzLjMzMzMzMzMzMzMzMzMzMnB4OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRl LXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPjIuMy5YIENvbnRlbnQgRmlsdGVyaW5nPC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzMzMzMzMzMzMzMzMnB4 OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNz PSIiPlNlcnZpY2UgUHJvdmlkZXJzIG1heSwgZnJvbSB0aW1lIHRvIHRpbWUsIGJlIHJlcXVlc3Rl ZCBieSBsYXcgYWdlbmNpZXMgdG8gYmxvY2sgYWNjZXNzJm5ic3A7dG8gcGFydGljdWxhciBzaXRl cyBzdWNoIGFzIG9ubGluZSBiZXR0aW5nIGFuZCBnYW1ibGluZywNCiBzaXRlcyBwcm9tb3Rpbmcg YW5vcmV4aWEsIG9yIGFjY2VzcyB0byBkYXRpbmcgc2l0ZXMuKjEgQ29udGVudCBGaWx0ZXJpbmcg Y2FuIGFsc28gaGFwcGVuIGF0IHRoZSBlbmRwb2ludHMuPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTMuMzMzMzMzMzMzMzMzMzMycHg7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsg d2hpdGUtc3BhY2U6IHByZS13cmFwOyIgY2xhc3M9IiI+Q29udGVudCBmaWx0ZXJpbmcgaW4gdGhl IG1vYmlsZSBuZXR3b3JrIHVzdWFsbHkgb2NjdXJzIGluIHRoZSBjb3JlIG5ldHdvcmsuIEEgcHJv eHkgaXMgaW5zdGFsbGVkIHdoaWNoIGFuYWx5c2VzIHRoZSB0cmFuc3BvcnQgbWV0YWRhdGEgb2YN CiB0aGUgY29udGVudCB1c2VycyBhcmUgdmlld2luZyBhbmQgZWl0aGVyIGZpbHRlcnMgY29udGVu dCBiYXNlZCBvbiBhIGJsYWNrbGlzdCBvZiBzaXRlcyBvciBiYXNlZCBvbiB0aGUgdXNlcuKAmXMg cHJlLWRlZmluZWQgcHJvZmlsZSAoZS5nLiBmb3IgYWdlIHNlbnNpdGl2ZSBjb250ZW50KS4gQWx0 aG91Z2ggZmlsdGVyaW5nIGNhbiBiZSBkb25lIGJ5IG1hbnkgbWV0aG9kcyBvbmUgY29tbW9uIG1l dGhvZCBvY2N1cnMgd2hlbiBhIEROUyBsb29rdXAgcmV2ZWFscw0KIGEgVVJMIHdoaWNoIGFwcGVh cnMgb24gYSBnb3Zlcm5tZW50IG9yIHJlY29nbmlzZWQgYmxvY2stbGlzdC4gVGhlIHN1YnNlcXVl bnQgcmVxdWVzdHMgdG8gdGhhdCBkb21haW4gd2lsbCBiZSByZS1yb3V0ZWQgdG8gYSBwcm94eSB3 aGljaCBjaGVja3Mgd2hldGhlciB0aGUgZnVsbCB1cmwgbWF0Y2hlcyBhIGJsb2NrZWQgdXJsIG9u IHRoZSBsaXN0LCBhbmQgd2lsbCByZXR1cm4gYSA0MDQgaWYgYSBtYXRjaCBpcyBmb3VuZC4gQWxs IG90aGVyIHJlcXVlc3RzDQogc2hvdWxkIGNvbXBsZXRlLjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzMzMzMzMzMzMzMzJweDsgdmVydGljYWwtYWxp Z246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj5FdmVuIGluIGVu Y3J5cHRlZCBjb25uZWN0aW9ucyB0cmFuc3BvcnQgYW5kIGxvd2VyIGxheWVyIG1ldGFkYXRhIGlz IGFibGUgdG8gYmUgdmlld2VkIHNvIGZvciBtYW55IHN5c3RlbXMgY29udGVudA0KIGZpbHRlcmlu ZyBzaG91bGQgYmUgYWJsZSB0byBjb250aW51ZS4gQ2FzZXMgd2hlbiB0aGV5IG1heSBub3Qgd29y ayBpcyB3aGVuIFRMUyBwcm94aWVzIGFyZSBiZWluZyB1c2VkIHdoaWNoIG9ic2N1cmUgbWV0YWRh dGEgd2l0aCB0aGUgcHJveHkgbWV0YWRhdGEsIGFuZCBmdXR1cmUgdmVyc2lvbnMgaW4gSFRUUCBh bmQgVENQIG1heSBlbmNyeXB0IG1ldGFkYXRhIGFnYWluIHN0b3BwaW5nIGNvbnRlbnQgZmlsdGVy aW5nIHNvZnR3YXJlIGZyb20gd29ya2luZw0KICh0aGlzIGlzIGN1cnJlbnRseSBub3QgdGhlIGNh c2UgYW5kIGhhcyBub3QgYmVlbiBzdGFuZGFyZGlzZWQpLiZuYnNwOyoyPC9zcGFuPjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsiIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNv bGFzOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzMzMzMzMzMzMzMzMy cHg7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyIgY2xh c3M9IiI+U29tZSBzaXRlcyBpbnZvbHZlIGEgbWl4dHVyZSBvZiB1bml2ZXJzYWwgYW5kIGFnZS1z ZW5zaXRpdmUgY29udGVudCBhbmQgZmlsdGVyaW5nIHNvZnR3YXJlIGluIHRoZXNlIGNhc2VzIG1h eQ0KIHVzZSBtb3JlIGdyYW51bGFyIChhcHBsaWNhdGlvbiBsYXllcikgbWV0YWRhdGEgdG8gYW5h bHlzZSBhbmQgYmxvY2s7IHRoaXMgd2lsbCBub3Qgd29yayBvbiBlbmNyeXB0ZWQgY29udGVudC48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzMzMzMzMzMzMzMzJweDsgdmVydGljYWwt YWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFj ZT0iQXJpYWwiIGNsYXNzPSIiPkkgd2FudGVkIHRvIGFkZCB0d28gbW9yZSBzZW50ZW5jZXMsIGJ1 dCBhbiBJRVRGZXIgZ2F2ZSBtZSBzb21lIGFkdmljZSB0b2RheSB0byBzYXkgdGhhdCBJIHNob3Vs ZCBvbmx5IHN0YXRlIGZhY3RzLCBhbmQgbm90IGFueSBsZWFkaW5nIG9yJm5ic3A7cHJlc3VtcHRp dmUmbmJzcDtpdGVtcywgaW4gc3VjaCBhIHN1Ym1pc3Npb24uIEluIHdoaWNoIGNhc2UgSSByZW1v dmVkIHRoZXNlIHR3byBzZW50ZW5jZXMsDQogYnV0IHlvdSBtYXkgZmluZCBpdCBiZW5lZml0IHRv IGluY2x1ZGUgdGhlbTo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQg ZmFjZT0iQXJpYWwiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8dWwgY2xhc3M9Ik1haWxPdXRsaW5lIj4NCjxsaSBjbGFzcz0iIj48Zm9udCBm YWNlPSJBcmlhbCIgY2xhc3M9IiI+JnF1b3Q7U29tZSBtb2JpbGUgb3BlcmF0b3JzIHV0aWxpc2lu ZyBsaWNlbmNlZCBzcGVjdHJ1bSBtdXN0IGFkaGVyZSB0byByZWd1bGF0aW9ucyBzZXQgYnkgdGhl IGdvdmVybm1lbnQgbGljZW5zb3IsIHdoaWNoIGluY2x1ZGUgY29udGVudCBmaWx0ZXJpbmcsIG9y IHJpc2sgZmluZXMvbGljZW5jZSBzdXNwZW5zaW9uJnF1b3Q7IGF0ICoxPC9mb250PjwvbGk+PGxp IGNsYXNzPSIiPjxmb250IGZhY2U9IkFyaWFsIiBjbGFzcz0iIj4mcXVvdDtSZWd1bGF0b3JzIHRo YXQgaW1wb3NlIHRoZXNlIGNlbnNvcnNoaXAgcnVsZXMgbWF5IGxvb2sgZm9yIG90aGVyIG1lYW5z IGlmIGN1cnJlbnQgbWV0aG9kcyBzdG9wIHdvcmtpbmcuJnF1b3Q7IGF0ICoyLjwvZm9udD48L2xp PjwvdWw+DQo8L2Rpdj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIg Y2xhc3M9IiI+QWxzbywgSSBhbSBoYXBweSBpbiBrbm93aW5nIHRoYXQgSUVURiB3b27igJl0IHdv cmsgb24gbWl0aWdhdGluZyBhbnkgc29ydCBvZiBjZW5zb3JzaGlwLCBqdXN0IHRoYXQgdGhpcyBl eGlzdHMgYXMgYSByZWZlcmVuY2UuIEkgYWxzbyBsaWtlZCB0aGUgaWRlYSBvZiByZXR1cm5pbmcg aW5mb3JtYXRpb24gdG8gdGhlIHVzZXIgYWJvdXQgd2hhdCBpcyBoYXBwZW5pbmcgc28gdGhleQ0K IGNhbiBtYWtlIGRlY2lzaW9ucyBhYm91dCB0aGVpciBicm93c2VyLCBwcm92aWRlciwgb3Igd2hv IHRoZXnigJlyZSB2b3RpbmcgZm9yISBDb21tZW50cyBhbHdheXMgd2VsY29tZSAtIHRoYW5rcyBm b3IgdGhlIHJlc3BvbnNlcyBzbyBmYXIhPC9kaXY+DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVk PSJ0cnVlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgYXBwbGUtY29udGVu dC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPk5hdGFzaGE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhIFJvb25leSB8IFdlYiBUZWNobm9sb2dpc3QgfCZu YnNwO0dTTUEgfCA8YSBocmVmPSJtYWlsdG86bnJvb25leUBnc21hLmNvbSIgY2xhc3M9IiI+DQpu cm9vbmV5QGdzbWEuY29tPC9hPiB8ICYjNDM7NDQgKDApJm5ic3A7NzczMCAyMTkgNzY1IHwgQHRo aXNOYXRhc2hhIHwgU2t5cGU6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm5yb29uZXlAZ3NtLm9yZyIg Y2xhc3M9IiI+bnJvb25leUBnc20ub3JnPC9hPiZuYnNwOzxiciBjbGFzcz0iIj4NClRva3lvLCBK YXBhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBKdW4gMjMsIDIwMTUsIGF0IDExOjQ4IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj5rYXRo bGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNs YXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+ PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgSnVuIDIzLCAy MDE1IGF0IDU6MjAgQU0sIFlvYXYgTmlyIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8 YSBocmVmPSJtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPnluaXIuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPHNw YW4gY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KJmd0OyBPbiBKdW4gMjMsIDIwMTUsIGF0IDExOjU5 IEFNLCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 IFRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24gb24gdGhpcywgaXQncyBoZWxwZnVsIHRvIGdldCB0 aGlzIHJpZ2h0IGZvciBkb2N1bWVudGF0aW9uIHB1cnBvc2VzLiZuYnNwOyBJJ2Qgc3BsaXQgb3V0 IE1pVE0gYWN0aXZpdGllcyBvZiB0aGlzIHNvcnQgZm9yIGVudGVycHJpc2VzIHZzLiB0aGUgc2Ft ZSBkb25lIGF0IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGxldmVsIGJlY2F1c2Ugb2YgZW1wbG95ZWUg YWdyZWVtZW50cy4mbmJzcDsgSSBhbHNvIGNob29zZSBub3QgdG8NCiBnbyB0byBtYW55IHNpdGVz IGZyb20gYmVoaW5kIGEgZmlyZXdhbGwgYW5kIGhvcGUgb3RoZXJzIGRvIHRvbyB3aGVuIHNpZ25h bGVkIHRoYXQgdGhlcmUgaXMgYSBjZXJ0aWZpY2F0ZSBtaXNtYXRjaC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8L3NwYW4+SeKAmW0gbm90IHN1cmUgaWYgdGhhdCBkaXN0aW5jdGlvbiBp cyBtZWFuaW5nZnVsLiBUaGUgdGVjaG5vbG9neSBmb3IgaW50ZXJjZXB0aW9uIGlzIHRoZSBzYW1l IHdoZXRoZXIgaXQgaXMgdXNlZCB0byBzY2FuIGRvd25sb2FkZWQgZmlsZXMgZm9yIG1hbHdhcmUg b3IgdG8gc2NhbiBGYWNlYm9vayBwb3N0cyBmb3IgaW5zdWZmaWNpZW50IGFwcHJlY2lhdGlvbiBv ZiBvdXIgRGVhciBMZWFkZXIuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U3VyZSwgSSdtIGF3YXJl IHRoZSBzYW1lIHRlY2huaXF1ZSBpcyBzb21ldGltZXMgdXNlZCBmb3IgYm90aCBzY2VuYXJpb3Ms IGJ1dCBub3QgYWx3YXlzLiZuYnNwOyBJdCdzIGVhc3kgZm9yIGEgY29tcGFueSB3aXRoIGFuIGFn cmVlbWVudCB0byBzZXQgdXAgYSBwcm94eSB0aGF0IGhhcyAyIFRMUyBzZXNzaW9ucywgb25lIGJl dHdlZW4gdGhlIHVzZXIgYW5kIHByb3h5IGFuZCB0aGUgb3RoZXIgZnJvbSB0aGUgcHJveHkgdG8g dGhlIGRlc3RpbmF0aW9uDQogc2l0ZS4mbmJzcDsgT3RoZXIgdGVjaG5pcXVlcyBoYXZlIGJlZW4g dXNlZCAoc2VlIFVUQSdzIFRMUyBhdHRhY2sgUkZDIC0gNzQ1NykgYXQgdGhlIHNlcnZpY2UgcHJv dmlkZXIgbGV2ZWwsIGluY2x1ZGluZyBzdG9wcGluZyB0aGUgU1RBUlRUTFMgbmVnb3RpYXRpb24u PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Tb21lIGhhdmUgdXNlZCB0ZWNobmlxdWVzIHRoYXQgYXJlIGxlc3MgdmlzaWJsZSB0byB0aGUg dXNlci4mbmJzcDsgQXMgcHJvYmxlbXMgYXJlIGZpeGVkIGluIHRoZSBwcm90b2NvbCwgd2hhdCBp cyBkb25lIHNoaWZ0cyBvZiBjb3Vyc2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTti b3JkZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4N CkVtcGxveWVlcyBpbiBhIGNvcnBvcmF0ZSBlbnZpcm9ubWVudCBhcmUgc3VwcG9zZWRseSBpbmZv cm1lZCwgYnV0IGNvcnBvcmF0ZSBjb21wdXRlcnMgYW5kIGRldmljZXMgbWF5IGNvbWUgcHJlLWlu c3RhbGxlZCB3aXRoIHRoZSBpbnRlcmNlcHRpb24gY2VydGlmaWNhdGUuIEV2ZW4gYXMgYSBjb25z Y2llbnRpb3VzIHZlbmRvciwgdGhlcmUgaXMgbm8gd2F5IEkgY2FuIGVuZm9yY2UgdGhhdCBjb3Jw b3JhdGUgSVQgcHJvcGVybHkgaW5mb3JtcyB0aGUNCiBlbXBsb3llZXMuPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SSdtIHN1cmUgdGhpcyB2YXJpZXMgYmV0d2VlbiByZWdpb25zLiZuYnNwOyBJIGp1 c3QgdGhpbmsgZW50ZXJwcmlzZXMgY2FuIGJlIG1vcmUgZGVsaWJlcmF0ZSBhYm91dCBpdCB3aXRo IHVzZXIgYWdyZWVtZW50cyBhbmQgbm90IHdvcnJ5IGFib3V0IGVycm9yIG1lc3NhZ2VzLiZuYnNw OyBTdXJlLCB0aGUgc2FtIHRoaW5nIGNhbiBiZSBkb25lIGluIGEgcHJlLWluc3RhbGxlZCB3YXks IGJ1dCBhIHVzZXIgY2FuIGNoZWNrIHRoZSBjZXJ0cyBpZg0KIHRoZXkga25vdyBlbm91Z2guPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRo OjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxl OnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KU2ltaWxhcmx5LCB3ZeKA mXZlIHNlZW4gaW50ZXJjZXB0aW9uIHVzZWQgYXQgc2VydmljZSBwcm92aWRlcnMgYXQgdGhlIGJl aGVzdCBvZiBnb3Zlcm5tZW50cy4gSW4gc29tZSBjb3VudHJpZXMgZGV2aWNlcyBjb21lIHByZS1p bnN0YWxsZWQgd2l0aCB0aGUgZ292ZXJubWVudCBpbnRlcmNlcHRpb24gY2VydGlmaWNhdGUuIFRo aXMgbWFrZXMgaXQgdHJhbnNwYXJlbnQgdG8gdGhlIGNpdGl6ZW5zLiBBZ2FpbiwgaXQgd291bGQg YmUgbmljZSBpZiBjaXRpemVucw0KIGF0IGxlYXN0IGtuZXcgdGhpcyB3YXMgaGFwcGVuaW5nLCBi dXQgdGhvc2UgZ292ZXJubWVudHMgdGVuZCB0byBub3QgYmUg4oCcbmljZeKAnS4mbmJzcDsgQXQg bGVhc3QgSVNQcyBkb27igJl0IGhhdmUgdGhlIHBvd2VyIHRvIG1hbmlwdWxhdGUgdGhlIGVuZHBv aW50cyAodGhvdWdoIGluIHRoZSBlYXJseSBkYXlzIG9mIGJyb2FkYmFuZCB0aGV5IHdvdWxkIGFz ayB5b3UgdG8gaW5zdGFsbCBhIOKAnGRpYWxlcuKAnSAtIGlmIEkgd2VyZSBhIG1vcmUgc3VzcGlj aW91cyBwZXJzb27igKYpLA0KIGJ1dCB0aGV5IGRvIHdoZW4gdGhleSB3b3JrIGZvciB0aGUgZ292 ZXJubWVudC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ZZXMgYW5kIHRoYXQncyBzY2FyeS4mbmJz cDsgSSB0aGluayB0aGUgZGlzdGluY3Rpb24gaXMgYWNjZXB0YWJpbGl0eSBvZiB0aGUgYXBwcm9h Y2ggaW4gZW52aXJvbm1lbnRzIGxpa2Ugd29yaywgc2luY2UgeW91ciB0aW1lIGlzIHBhaWQgZm9y LiZuYnNwOyBEb2N1bWVudGluZyB0aGlzIGluIHR3byBzdGFnZXMgd291bGQgYmUgZ29vZCBhcyBh cHByb2FjaGVzIHRvIHJlc29sdmUgbWF5IGJlIGRpZmZlcmVudC4mbmJzcDsgVGhlIFRMUyAxLjMg d29yaw0KIHRvIHVzZSBwcmUtc2hhcmVkIGtleXMgbmVnb3RpYXRlZCB2aWEgRE5TIHNob3VsZCBj ZXJ0YWlubHkgaGVscCBvbiB0aGlzIGFuZ2xlLiZuYnNwOyBFbnRlcnByaXNlcyBtYXkgY2hvb3Nl IHRvIGJsb2NrIGFjY2VzcyB0byBzb21lIHNpdGVzLCB3aGVyZSBvdGhlciBvcHRpb25zIG1pZ2h0 IGJlIHVzZWQgYnkgZ292ZXJubWVudHMgb3Igb3RoZXJzIHRyeWluZyB0byBNaVRNIHRyYWZmaWMu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQp O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIi Pg0KSWRlYWxseSBhIHNvbHV0aW9uIHdvdWxkIHJldmVhbCB0aGUgcHJlc2VuY2Ugb2YgYSBNSVRN IHRvIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIuDQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGF0IHdvdWxkIGJlIGdvb2Qu Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LWNv bG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQpBbGwgc29sdXRpb25zIGRpc2N1c3NlZCB0aHVzIGZhciBjYW4gcmV2ZWFsIHRoaW5n cyB0byB0aGUgY2xpZW50LCBidXQgZG8gbm90aGluZyBmb3IgdGhlIHNlcnZlci4gSSB3b3VsZCBs aWtlIHRvIGhhdmUgc2VydmVycyBzdWNoIGFzIGZpbmFuY2lhbCBpbnN0aXR1dGlvbnMgYW5kIG1l ZGljYWwgc2VydmljZXMgYmUgYWJsZSB0byBlbmZvcmNlIGEgcG9saWN5IHdoZXJlIHRoZXkgZG9u 4oCZdCBwcm92aWRlIGEgc2VydmljZSB0aHJvdWdoIGEgbWlkZGxlYm94Lg0KIERvaW5nIGl0IG5v dyByZXF1aXJlcyBpbnN0YWxsaW5nIHRoZWlyIG93biBjbGllbnQgb24gdGhlIHVzZXLigJlzIG1h Y2hpbmUsIHdoaWNoIHNlZW1zIHRvIGJlIGEgdHJlbmQgaW4gbW9iaWxlLCBidXQgaXMgbm90IHNv bWV0aGluZyB3ZSBzaG91bGQgcmVxdWlyZS48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48 Zm9udCBjb2xvcj0iIzg4ODg4OCIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KWW9hdjwvZm9udD48 L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5LYXRoZWVuJm5ic3A7 PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGVhcj0iYWxsIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQotLSA8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkthdGhsZWVuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxwIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTFweDtjb2xvcjojOTk5 OTk5OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsc2Fucy1z ZXJpZjtjb2xvcjojOTk5OTk5OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQXJpYWw7IG1zby1m YXJlYXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJnF1 b3Q7QXJpYWwmcXVvdDs7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IEVOLUdCOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPlRoaXMNCiBlbWFpbCBhbmQg aXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5k IG1heSBiZSBjb25maWRlbnRpYWwuIElmIHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5 b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBv ciBzaG93IHRoZW0gdG8gYW55b25lOyBwbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxs ICYjNDM7NDQgMjA3IDM1NiAwNjAwDQogYW5kIGhpZ2hsaWdodCB0aGUgZXJyb3IuIDwvc3Bhbj48 L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A03F39DEEFF04769B21837816296BB02gsmacom_-- From nobody Tue Jun 23 06:04:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3CF1A0393 for ; Tue, 23 Jun 2015 06:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21t2jCbFYomU for ; Tue, 23 Jun 2015 06:04:50 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::687]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEA31A0383 for ; Tue, 23 Jun 2015 06:04:49 -0700 (PDT) Received: from HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) by HE1PR04MB1033.eurprd04.prod.outlook.com (10.162.26.142) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:04:29 +0000 Received: from HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) by HE1PR04MB1033.eurprd04.prod.outlook.com ([10.162.26.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 13:04:29 +0000 From: Natasha Rooney To: saag Thread-Topic: IETF93 Agenda Thread-Index: AQHQrbUjKID5TphZOku02lxeaH2UFg== Date: Tue, 23 Jun 2015 13:04:29 +0000 Message-ID: <39CD4C86-0C30-44A6-BB6C-2BD36C49FA9F@gsma.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.31.90.49] x-microsoft-exchange-diagnostics: 1; HE1PR04MB1033; 5:2DRaJWdA37+mhQOb3P6RTTy7kxJurPbJ7RTmORBlzkQgFCeSKyqUvBfcQ2Zerv6168ouAI5GAxrD921FGHmGTo+Yli+g08YJTpt0SXWxoGfTf2rqXhqvSjeoCl0xmCGeaz8+SPBr5dwpzxJOykpaLw==; 24:/4aLLebkPLp38Iti9mE5+9n3aE/jIqPIEiqtJsnv+hkP/L+bwNUlxv3k4y2Ed+i5xKCcrfiTpJb/noxnGsf55PtG4IA13hYT9D3/UTmdutM=; 20:58srp0mp8IukYD/yCT5o9+RutYEWd3l9w0JBZ3sHsIOdmGYtVe9Dqte+yl7eWaKCL6qy+vTJwnmLe/WIxMSkug== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR04MB1033; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:HE1PR04MB1033; BCL:0; PCL:0; RULEID:; SRVR:HE1PR04MB1033; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(54094003)(53754006)(16236675004)(87936001)(2656002)(229853001)(15975445007)(57306001)(36756003)(5890100001)(102836002)(122556002)(82746002)(50226001)(77096005)(5002640100001)(19617315012)(2900100001)(189998001)(40100003)(92566002)(46102003)(450100001)(77156002)(62966003)(66066001)(110136002)(107886002)(5001960100002)(86362001)(83716003)(33656002)(19580405001)(50986999)(19580395003)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR04MB1033; H:HE1PR04MB1033.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_39CD4C860C3044A6BB6C2BD36C49FA9Fgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 13:04:29.6852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR04MB1033 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: HE1PR04MB1033.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 212.31.90.49 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: HE1PR04MB1033.eurprd04.prod.outlook.com Archived-At: Subject: [saag] IETF93 Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:04:51 -0000 --_000_39CD4C860C3044A6BB6C2BD36C49FA9Fgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all! I have a mildly leading question: at the next IETF93 will (or may there?) t= here be a section on the SAAG agenda covering the following: [1] Ubiquitous Encryption Draft (http://www.ietf.org/id/draft-mm-wg-effect-= encrypt-01.txt) [2] Network management of encrypted traffic (https://datatracker.ietf.org/d= oc/draft-smith-encrypted-traffic-management/) [3] Confidentiality in the Face of Pervasive Surveillance (https://datatrac= ker.ietf.org/doc/draft-iab-privsec-confidentiality-mitigations/)? I sent some stuff to [1] so would love to discuss them with people there. I= wonder if other people would find this useful? If not I am happy with cont= inuing on the mailing list! Thanks all! Natasha Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org Tokyo, Japan This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_39CD4C860C3044A6BB6C2BD36C49FA9Fgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hello all!

I have a mildly leading question: at the next IETF93 will (= or may there?) there be a section on the SAAG agenda covering the following= :

[1] Ubiquitous Encryption Draft (http://www.ietf.org/i= d/draft-mm-wg-effect-encrypt-01.txt)
[2] Network management of encrypted traffic (https://datatracker.ietf.org/doc/draft-smith-encrypted-traf= fic-management/)
[3] Confidentiality in the Face of Pervasive Surv= eillance (https://datatracker.ietf.org/doc/draf= t-iab-privsec-confidentiality-mitigations/)?

I sent some stuff to [1] so would love to discuss them with= people there. I wonder if other people would find this useful? If not I am= happy with continuing on the mailing list!

Thanks all!

Natasha


Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 (0) 7730 219 765 | @thisNatasha | Skype= : nrooney@gsm.org&nb= sp;
Tokyo, Japan


This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_39CD4C860C3044A6BB6C2BD36C49FA9Fgsmacom_-- From nobody Tue Jun 23 06:42:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55C21B2C11; Tue, 23 Jun 2015 06:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0vEbZOO0dAe; Tue, 23 Jun 2015 06:42:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DEF1B2C16; Tue, 23 Jun 2015 06:42:28 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A07C6282FD0; Tue, 23 Jun 2015 13:42:27 +0000 (UTC) Date: Tue, 23 Jun 2015 13:42:27 +0000 From: Viktor Dukhovni To: dane@ietf.org, saag@ietf.org Message-ID: <20150623134227.GZ14121@mournblade.imrryr.org> References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> <558953F3.5040503@dial.pipex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <558953F3.5040503@dial.pipex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:42:30 -0000 On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote: > >Since the OS client is basing the decision to employ DANE on the > >presence of TLSA RRs in DNS, no additional security is gained via > >the PKIX usages unless they are the only ones supported by the > >application protocol (the attacker who compromises DNS can just > >inject "3 1 1" records instead). So DANE-xx is more reliable > >at no security loss. Thus PKIX-xx is just a needless opportunity > >to fail that should be avoided. > > Maybe I have misunderstood how OS is intended to behave. I thought I > understood that if the client was able to handle OS and it was not able to > authenticate the server then it would potentially try for encryption only. No, that is not the case. With opportunistic DANE TLS, when usable secure (i.e. DNSSEC validated) TLSA records are present, but authentication fails, there is typically no fallback to unauthenticated TLS (mitigate downgrade attacks), for example: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2 > Is the problem that there is a difference between there being no > authentication available for a domain and an attempted authentication > failing (aside from any explicit policy declared by server or client) when > using OS? Yes, when no usable secure DANE TLSA records are absent, unauthenticated TLS is used if possible, and if not perhaps even cleartext. However, when TLSA records are published authentication must succeed. Thus PKIX-xx auth are to be avoided, because outside the browser space, there is no pre-ordained canon of trusted CAs, and in any case there is no value in using them when DANE-xx usages are also supported. For most application protocols there should be a clear statement of which of the two pairs apply (DANE-xx or PKIX-xx) and the other pair should not be used. -- Viktor. From nobody Tue Jun 23 08:19:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055AD1B2D1E for ; Tue, 23 Jun 2015 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp8S9rcuObft for ; Tue, 23 Jun 2015 08:19:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAF11B2D26 for ; Tue, 23 Jun 2015 08:19:26 -0700 (PDT) Received: (qmail 24603 invoked from network); 23 Jun 2015 15:19:35 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jun 2015 15:19:35 -0000 Date: 23 Jun 2015 15:19:02 -0000 Message-ID: <20150623151902.89304.qmail@ary.lan> From: "John Levine" To: saag@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 15:19:39 -0000 I can't find in the archives whether the ubiquitous encryption discussion has looked at the knotty issues of spam filtering. It's a really hard problem -- filtering is essential to keep mail usable, both due to the sheer volume of the spam and the need to keep phishing and malware away from recipients. You can do some filtering on the envelope, but there's no substitute for looking at the contents of the message. All of the middlebox issues apply, it's much easier to do the filtering on a large shared server than at endpoints. Partly that's because the endpoints often have limited bandwidth and compute power (think phones) and partly it's because effective filtering needs to consult shared frequently updated lists of malware signatures and malicious urls. R's, John From nobody Tue Jun 23 08:22:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E771B2D28 for ; Tue, 23 Jun 2015 08:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5YEjQcxFOrx for ; Tue, 23 Jun 2015 08:22:44 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2171B2CD8 for ; Tue, 23 Jun 2015 08:22:44 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so12729601wgb.2 for ; Tue, 23 Jun 2015 08:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kWtcimb4iXou45xCOTcle+VTxaYxDeRtlEvMfxF4e9k=; b=ppcKp1/KiC8fDxw1DKTOwhQbByZYjNedpt0mgQQAVTyHPlT5szw3Ihte/+Lbjl7fz1 fgA8dbTt2dTyaGZenSOZ8sAc/jfoLv9qFSmb/NS/V88PNVDkyz8DoLvTrT8rzKXOLtnv qRehnmGXjBRggN3wQEkY81Th08lXy3sKhiR+g4DS1q5/umJiHEiEpinL9WiltiV/+Cj1 aXVlqKpbsTGfFvIfmuhbbksP1Q5DmO21mxWm0ql5OFomMb3IuaQ8TR99UFdtrwDvrBGC iIQYW9f9TIXvoca7sU1H2MWJxGPEF8E2kPorByt3UNJT2FGzqTVW3VOmxyyfXoMNh58d NgHg== MIME-Version: 1.0 X-Received: by 10.194.75.132 with SMTP id c4mr8527806wjw.80.1435072963067; Tue, 23 Jun 2015 08:22:43 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Tue, 23 Jun 2015 08:22:42 -0700 (PDT) In-Reply-To: <20150623151902.89304.qmail@ary.lan> References: <20150623151902.89304.qmail@ary.lan> Date: Tue, 23 Jun 2015 11:22:42 -0400 Message-ID: From: Kathleen Moriarty To: John Levine Content-Type: multipart/alternative; boundary=047d7bb04b7c30c2c4051930f66e Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 15:22:47 -0000 --047d7bb04b7c30c2c4051930f66e Content-Type: text/plain; charset=UTF-8 Hi John, There is some text in the draft. If we missed anything or didn't go into enough detail yet, contributions are welcome, especially if you are active in this area. Thank you! On Tue, Jun 23, 2015 at 11:19 AM, John Levine wrote: > I can't find in the archives whether the ubiquitous encryption > discussion has looked at the knotty issues of spam filtering. > > It's a really hard problem -- filtering is essential to keep mail > usable, both due to the sheer volume of the spam and the need to keep > phishing and malware away from recipients. You can do some filtering > on the envelope, but there's no substitute for looking at the contents > of the message. > > All of the middlebox issues apply, it's much easier to do the > filtering on a large shared server than at endpoints. Partly that's > because the endpoints often have limited bandwidth and compute power > (think phones) and partly it's because effective filtering needs to > consult shared frequently updated lists of malware signatures and > malicious urls. > > R's, > John > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen --047d7bb04b7c30c2c4051930f66e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

There is some text in the draf= t. If we missed anything or didn't go into enough detail yet, contribut= ions are welcome, especially if you are active in this area.

=
Thank you!

On Tue, Jun 23, 2015 at 11:19 AM, John Levine <johnl@taugh.= com> wrote:
I can't fin= d in the archives whether the ubiquitous encryption
discussion has looked at the knotty issues of spam filtering.

It's a really hard problem -- filtering is essential to keep mail
usable, both due to the sheer volume of the spam and the need to keep
phishing and malware away from recipients.=C2=A0 You can do some filtering<= br> on the envelope, but there's no substitute for looking at the contents<= br> of the message.

All of the middlebox issues apply, it's much easier to do the
filtering on a large shared server than at endpoints.=C2=A0 Partly that'= ;s
because the endpoints often have limited bandwidth and compute power
(think phones) and partly it's because effective filtering needs to
consult shared frequently updated lists of malware signatures and
malicious urls.

R's,
John

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag



--

Best regards,
Kath= leen
--047d7bb04b7c30c2c4051930f66e-- From nobody Tue Jun 23 08:30:29 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E92C1ACDD9 for ; Tue, 23 Jun 2015 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEVaIq2j-YIL for ; Tue, 23 Jun 2015 08:30:19 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0C31ACDD6 for ; Tue, 23 Jun 2015 08:30:19 -0700 (PDT) Received: (qmail 25880 invoked from network); 23 Jun 2015 15:30:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6517.55897b95.k1506; bh=PtDYRZY9Aau7YKRTn4OwBU82LQRDoh7t6ZujEGH7M5w=; b=Vl53Q//MjMeM371JupBZtkz89dC1kiyemtxrmPIc2R7Cv4ZsZPJihAQftGwHj7X3Na4oZqY2c0PTIt4VOQ849GMTVaXBRwMWQFfKQQ5qObuvmXBPa1HzDS16CGcKq04LSg13Isc9ezqVxLpSIo68s+b/Z7VgFHBm98ROn4d2OlTtpN+eRuPddAB0eOLqUT3tqGZ21cTJSbt+hLjTK6Z419H7kHYTOrEafjN7zexi4Dkpy7qrS/zQ7BZLobFhpAov DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=6517.55897b95.k1506; bh=PtDYRZY9Aau7YKRTn4OwBU82LQRDoh7t6ZujEGH7M5w=; b=G0/lEtvPnuq5F1OrNKfsm546mIyUNuTuNisO2diT1zv5TeE1fX63f2D3oOmbM/s0LglEXxlPPv/yGf5/NeeB+xZO3B3qjK06mYY07RKB2Sm8cyQ8tK3UBkq9P/92Dxk+95ZMiXiNyXJREJ4irCPpt/jnelGqApOmUiprowpyOwv2uYG1Avsztvnyn6h7uuGwjetFtoZlXcxgZv4DSajASdxgy+B3zlDYj/48UxPwW9j7UvhGeGRTp70oPgvyz3Em Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 23 Jun 2015 15:30:29 -0000 Date: 23 Jun 2015 12:30:15 -0300 Message-ID: From: "John R Levine" To: "Kathleen Moriarty" In-Reply-To: References: <20150623151902.89304.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 15:30:21 -0000 > There is some text in the draft. If we missed anything or didn't go into > enough detail yet, contributions are welcome, especially if you are active > in this area. I guess I count as active in this area. Will send text when I'm not pretending to pay attention in an ICANN session. R's, John PS: Editorial nit: "SPAM" is pink meat, "spam" is unwanted messages. > > Thank you! > > On Tue, Jun 23, 2015 at 11:19 AM, John Levine wrote: > >> I can't find in the archives whether the ubiquitous encryption >> discussion has looked at the knotty issues of spam filtering. >> >> It's a really hard problem -- filtering is essential to keep mail >> usable, both due to the sheer volume of the spam and the need to keep >> phishing and malware away from recipients. You can do some filtering >> on the envelope, but there's no substitute for looking at the contents >> of the message. >> >> All of the middlebox issues apply, it's much easier to do the >> filtering on a large shared server than at endpoints. Partly that's >> because the endpoints often have limited bandwidth and compute power >> (think phones) and partly it's because effective filtering needs to >> consult shared frequently updated lists of malware signatures and >> malicious urls. >> >> R's, >> John >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jun 23 09:11:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96881ACDE7 for ; Tue, 23 Jun 2015 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7wJq5sqFsBj for ; Tue, 23 Jun 2015 09:11:56 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFB61ACDE6 for ; Tue, 23 Jun 2015 09:11:56 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AC50D2C80A0; Tue, 23 Jun 2015 09:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Z153r4pkbX5ljM qBVtRdCL9mZJs=; b=nWT3H9756d7mXLuMkgs3G2nBM606vli5T0JBvTeH+MckMe LeSBxRbKeOTW7n4vWtE3qZeRDv3wjTBhRPHZSeQXMcdC1GVQ0viStB1uA9sUmfxe SwD+ZBnJoCJPT1huyecTwkUNQUca4nG+4axronGbsbiVm1NGbkY///b66GI2A= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 226952C8094; Tue, 23 Jun 2015 09:11:55 -0700 (PDT) Date: Tue, 23 Jun 2015 11:11:53 -0500 From: Nico Williams To: John Levine Message-ID: <20150623161153.GV6117@localhost> References: <20150623151902.89304.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150623151902.89304.qmail@ary.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 16:11:56 -0000 On Tue, Jun 23, 2015 at 03:19:02PM -0000, John Levine wrote: > I can't find in the archives whether the ubiquitous encryption > discussion has looked at the knotty issues of spam filtering. > > It's a really hard problem -- filtering is essential to keep mail > usable, both due to the sheer volume of the spam and the need to keep > phishing and malware away from recipients. You can do some filtering > on the envelope, but there's no substitute for looking at the contents > of the message. > > All of the middlebox issues apply, it's much easier to do the > filtering on a large shared server than at endpoints. [...] I agree. E-mail is different from web. From nobody Tue Jun 23 11:47:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02201A8AFE for ; Tue, 23 Jun 2015 11:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyfJRGlolcRU for ; Tue, 23 Jun 2015 11:47:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513A11A90FD for ; Tue, 23 Jun 2015 11:47:32 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51355 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z7TEI-00099m-Oy; Tue, 23 Jun 2015 14:47:30 -0400 Message-ID: <5589A9C2.40802@bbn.com> Date: Tue, 23 Jun 2015 14:47:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nico Williams References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> In-Reply-To: <20150622211207.GM6117@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 18:47:34 -0000 Nico, > On Mon, Jun 22, 2015 at 04:25:28PM -0400, Stephen Kent wrote: >> On purely technical grounds, an argument for filtering in the "middle" >> is reasonable. It's much easier for a mobile operator, [...] >> >> So, from an engineering perspective, the argument about the conflict >> between end-to-end encryption and operator (including enterprise IT >> staff) access to traffic is a valid consideration, irrespective of the >> telecom-regulator argument. > But it isn't just a matter of engineering the protocol. There are > security problems involved in making this happen (like: how do you > express to the user that there is one (or more!) middle box filtering > and/or modifying their traffic? how do users get to opt out? how is > scope limited? (e.g., how do you prevent the device/operator from > MITMing the user when the user is NOT using the operator's network?)). I didn't say that there were god/easy solutions here. I just noted that, from an engineering (not regulatory) perspective, there were legitimate concerns that should be noted. > And anyways, operators already get to do this by simply forcing users to > use devices from the operators (modified to have MITM CA trust anchors). > What new technology is being requested here, regardless of whether > we'd publish it (though the current position as to that is clear: no; > but the IETF consensus can always change)? Not all "operators" have the ability to impose such constraints. In my work environment the parent company is very much a Windows shop. But, they have been persuaded that forcing Mac users to adopt their preferred OS is not a viable solution (i.e., valuable personnel would likely depart). Steve From nobody Tue Jun 23 12:16:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFC21A1A9B for ; Tue, 23 Jun 2015 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz9HAVe3BReP for ; Tue, 23 Jun 2015 12:16:15 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6CB1A1A96 for ; Tue, 23 Jun 2015 12:16:15 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 3ABDC3600FA; Tue, 23 Jun 2015 12:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2u1AC95ckxRCzh 0gJ3cONFdE8sg=; b=O/pBNcx7WqAwz2PhWTbZk0j/qNwRuIxSJZKZzBg86s6C6D gKxbbbvq3o9xQKBn59rIltJvOqM47BarlPBp8iCfPqx63EK/vacwGXjTcjvriTb5 G9Gryfe2ueP2VR9c/d6xXpGh8DipvihZshEmD1Ap0PZXbnER9lFKro76cm/g8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id E008F360124; Tue, 23 Jun 2015 12:16:13 -0700 (PDT) Date: Tue, 23 Jun 2015 14:16:12 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20150623191610.GW6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <5589A9C2.40802@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5589A9C2.40802@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 19:16:16 -0000 On Tue, Jun 23, 2015 at 02:47:30PM -0400, Stephen Kent wrote: > I didn't say that there were god/easy solutions here. I just noted > that, from an engineering (not regulatory) perspective, there were > legitimate concerns that should be noted. OK. > >And anyways, operators already get to do this by simply forcing users to > >use devices from the operators (modified to have MITM CA trust anchors). > >What new technology is being requested here, regardless of whether > >we'd publish it (though the current position as to that is clear: no; > >but the IETF consensus can always change)? > > Not all "operators" have the ability to impose such constraints. In > my work environment the parent company is very much a Windows shop. > But, they have been persuaded that forcing Mac users to adopt their > preferred OS is not a viable solution (i.e., valuable personnel would > likely depart). The differences between a commercial network operator and a corporate network are mostly about scale and policies to be enforced. A corporate network typically has stringent policies about exfiltration of data that a commercial network operator does not. But ignoring those differences, you're right that there are great similarities. As I said, hierarchical PK authentication schemes permit MITMing by authorized entities, which makes me wonder: what else is desired? I can think of some things, such as lighter-weight key exchange and authentication [of authorized proxies to clients], and perhaps making authorized MITMs work with channel binding. But I've asked and no one mentioned any such things. Also, using PKIX has some benefits, such as allowing a proxy to present as close to the real thing to user agents as possible, with only subject public keys and issuers being different (this allows user agents to correctly diagnose issues such as expired certs). Options for your corporate network: - Give the personnel company-owned Macs with the companies trust anchors. The empolyees will have to carry these in addition to any personal devices, and they'll complain, but look, these options are quickly become de rigeur, so if they want to decamp for less secure pastures, *let them*. - Make the personnel use RDP-type remote access solutions and stop caring what they use as a client. Conversely, don't let them use personal devices on corporate networks. Provide a corporate wifi for guests and employee devices where you won't MITM but might still filter and/or log sites visited and so on. Employees can bring their own network where available (e.g., LTE); they'll probably be paying for that regardless. - Make the personnel use SSH/mosh jumpservers, with keystroke and screen logging, and output rate limits (to slow down exfiltration). This is fairly standard fare, but also mostly outside the scope of what IETF participants are likely to care to standardize. Nico -- From nobody Tue Jun 23 12:32:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6774D1A1BF8 for ; Tue, 23 Jun 2015 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA0k30C8pJpz for ; Tue, 23 Jun 2015 12:32:07 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6A41A1BDF for ; Tue, 23 Jun 2015 12:32:06 -0700 (PDT) Received: by lbbwc1 with SMTP id wc1so13175594lbb.2 for ; Tue, 23 Jun 2015 12:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HfgUnd6h2ZXatGY23JtPGHnr15SyC+KiKfeIt5ERQHk=; b=g9WF+BbJsWNnKQ9dbdCXco6TRSbXP7DiDG6gVdzjx6xyWuxaj8A8YxKMEgDmBOVEhz kZzRfAd1p+nLQd2FszwqLiJb19Eo7sn4AAyJ7oiu+1Q0E5cyPFt9QPmFQP0W/0yaVX4U kbIUL/hUN9ttmiRlWCACwqaFVTlo48fbF299a96WhNJMIRPSxYqvT0cpMSklAuRrNYK8 30pJr2p4HLbFrBFhz6iCbyRx+aJ49DzqUPt2VmndZmMLPqXPXYR+zUGti1KXDAEio8tm 13UDtKWgpo/H4PUo2h9E2zBF2HrBb5fOXfi/WSZuHht3/QYPilFQ/vNx1poTV0CbnMa5 mkVw== MIME-Version: 1.0 X-Received: by 10.112.40.99 with SMTP id w3mr25202677lbk.55.1435087925395; Tue, 23 Jun 2015 12:32:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 23 Jun 2015 12:32:05 -0700 (PDT) In-Reply-To: <20150623191610.GW6117@localhost> References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> <5589A9C2.40802@bbn.com> <20150623191610.GW6117@localhost> Date: Tue, 23 Jun 2015 15:32:05 -0400 X-Google-Sender-Auth: 1AeH_svpJnOgC7Sfr9vwjChN3WU Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11336f9603c6dc051934725c Archived-At: Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 19:32:09 -0000 --001a11336f9603c6dc051934725c Content-Type: text/plain; charset=UTF-8 Responding to various parts of the thread: Q: What is the difference between filtering and censorship? A: The person who decides to impose it. Filtering is actually an essential tool for use of the modern Internet. Without filtering there is no mechanism to control abuse. Today I received five junk calls. The time is rapidly approaching when I get rid of the telephone line completely. There is simply too much spam. The fact that the Russian Business Network has put a machine on the net does not mean that any machine I own need be able to connect to it. I don't want their IP address to be reachable, I don't want their DNS names to resolve. So the ability to perform filtering is an essential part of every end-to-end encryption mechanism. But giving control over that filtering to the government is not. When I was at university there was a club for thugs who went round smashing up restaurants for fun. One of the members of that club is now the UK Prime Minister. I am damned if I am going to let the likes of him decide what anyone can access. The question is who has control and who is empowered. I am firmly of the opinion that ubiquitous end-to-end encryption is only viable if it is accompanied by a robust and easy to use mechanism that allows for a gap in the stack. If I publish a key for phill@hallambaker.com it will be the key of a service in the cloud that performs anti-malware filtering. Use of the end-to-end key will be reserved to people who are expressly authorized to use it. --001a11336f9603c6dc051934725c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responding to various parts of = the thread:

Q: What is the difference between filtering and censorship?
A: The person who decides to impose it.

Filtering is actua= lly an essential tool for use of the modern Internet. Without filtering the= re is no mechanism to control abuse.

Today I received five junk calls. The time i= s rapidly approaching when I get rid of the telephone line completely. Ther= e is simply too much spam.

The fact that the Russian Business Network has put a m= achine on the net does not mean that any machine I own need be able to conn= ect to it. I don't want their IP address to be reachable, I don't w= ant their DNS names to resolve.=C2=A0

<= /div>
So the ability to perform filtering is an e= ssential part of every end-to-end encryption mechanism. But giving control = over that filtering to the government is not. When I was at university ther= e was a club for thugs who went round smashing up restaurants for fun. One = of the members of that club is now the UK Prime Minister. I am damned if I = am going to let the likes of him decide what anyone can access.

The question is w= ho has control and who is empowered.

I am firmly of the opinion that ubiquitous e= nd-to-end encryption is only viable if it is accompanied by a robust and ea= sy to use mechanism that allows for a gap in the stack. If I publish a key = for phill@hallambaker.com it w= ill be the key of a service in the cloud that performs anti-malware filteri= ng. Use of the end-to-end key will be reserved to people who are expressly = authorized to use it.


--001a11336f9603c6dc051934725c-- From nobody Tue Jun 23 17:09:01 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9AA1B2A44 for ; Tue, 23 Jun 2015 17:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9jCus-CPnDi for ; Tue, 23 Jun 2015 17:08:58 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B131B2A40 for ; Tue, 23 Jun 2015 17:08:58 -0700 (PDT) Received: by qged89 with SMTP id d89so9102531qge.0 for ; Tue, 23 Jun 2015 17:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=PoJ4ylpktJqQmmX3OVecqb3Mr5Lm0NjQkX2sFZOfVz4=; b=s0FjHs1HchNJ4/ZSxC47akrN8jNtfpSk5SbsBotiwu1QYluIrK+SKrRiTM6/DEpcHP H7/C4IfFEQkT2ciWaM7SWhH8syyiLWjwPf7PBi/a8pbbpnaWbLyMvIMnMlAihad8SqNU bXjC0RTiCU9lz5+2UBA3mciETVWoNQi0IJSPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PoJ4ylpktJqQmmX3OVecqb3Mr5Lm0NjQkX2sFZOfVz4=; b=NoeIve8Y1sMvBNlQf2VI3KZtCs5335Z4RRfThMVfHMbfTBlzo+Turr4HGI6RB9rTFU WQFfhP2Yd/J8VXbDE5G6zIHcnTHm3cSqihM5SKDSDhkoXl2i/gfAHg4IplJEg4J/vcnr TiBh8dOJW/wrcHh/FlwAeS2bsnfeAT6xuenup45AWmLi0kZklD1E7E/wWhJOaArgWCEZ tgYbmrnxG4JU+GyBZYIchLSWRukn7W29xHqiOUlGEEN2fzzrq+qn6ru+R59l6Cn78oHC L0OYD/DcOLdNfFwO6pacRvzwnyyyR/o0cBVXBlLK+TuD4KU9FzIkUEVP9zJ3uqHiTWoF Rq0w== X-Gm-Message-State: ALoCoQknPEvhUh/CcnQHdRpOP/gOBSjkVVAIZlV7chAmXlcWoZW225bNVNOFrACqQtg0iW0lkowk X-Received: by 10.140.29.55 with SMTP id a52mr46977999qga.25.1435104537837; Tue, 23 Jun 2015 17:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.51.103 with HTTP; Tue, 23 Jun 2015 17:08:38 -0700 (PDT) In-Reply-To: References: <99DC814A-2B7D-4802-A1C7-399E77F37BD7@gsma.com> <55844743.4030300@cs.tcd.ie> <55886F38.4030906@bbn.com> <20150622211207.GM6117@localhost> From: Tom Ritter Date: Tue, 23 Jun 2015 17:08:38 -0700 Message-ID: To: Natasha Rooney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: content filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 00:08:59 -0000 On 23 June 2015 at 01:47, Natasha Rooney wrote: > Thanks guys for this - and sorry for the on-list tech check: but, isn=E2= =80=99t SNI > configured by the content server. So, if I have run https://evil.com, can= =E2=80=99t > I just, not use SNI? No. While you can indeed disable SNI on your server, that will make no difference if clients send your name in the SNI. What you need to do to protect against filtering is configure clients to not send SNI. Which would never be done (because the connection would fail) unless the client knows the connection to the server in question will succeed without it. -tom From nobody Thu Jun 25 05:26:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E361A024C for ; Thu, 25 Jun 2015 05:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWKJMQBIqF0s for ; Thu, 25 Jun 2015 05:26:26 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CD11A023E for ; Thu, 25 Jun 2015 05:26:11 -0700 (PDT) Received: by wgqq4 with SMTP id q4so61185633wgq.1 for ; Thu, 25 Jun 2015 05:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5aL7cMkboK+abRWj8E2ZesqAztI71J14IKW13OmtPtQ=; b=JNbP/bJGgW6uzgg9hQJkLBYkfwOFRamQ1Md9a+uc6hnnRz9FzC3siSkRnV/C/Nisgd fmgqtvedpjUC1g2znBSRKcyToiqg0Ei9nBaewAR2NAjOE1Tasmkw9p/n2csrJ73bDjKI NzQPdxRSsWLoagIoK+uC+ugg2EWERcF/KTkTNG8S//RC9qyWpiw7wn4dtu3VjYOWi6vN L23sDZE+6g3Kol6CpwOAYBR+tWx78PyD7+jmffFkW2qRKdRaP4NV+tPw8Lvj0rypjY35 ODnZYmxFZX4PTM7ZrPsEnS1llPsEi/v8kgRXP2RbPM5Tut1xSi/mPI/CZeC2gpHCVreC NLSQ== MIME-Version: 1.0 X-Received: by 10.180.96.167 with SMTP id dt7mr338626wib.80.1435235170650; Thu, 25 Jun 2015 05:26:10 -0700 (PDT) Received: by 10.28.188.134 with HTTP; Thu, 25 Jun 2015 05:26:10 -0700 (PDT) In-Reply-To: <39CD4C86-0C30-44A6-BB6C-2BD36C49FA9F@gsma.com> References: <39CD4C86-0C30-44A6-BB6C-2BD36C49FA9F@gsma.com> Date: Thu, 25 Jun 2015 08:26:10 -0400 Message-ID: From: Kathleen Moriarty To: Natasha Rooney Content-Type: multipart/alternative; boundary=f46d043c0700840ef5051956ba2d Archived-At: Cc: saag Subject: Re: [saag] IETF93 Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 12:26:29 -0000 --f46d043c0700840ef5051956ba2d Content-Type: text/plain; charset=UTF-8 Hi Natasha, Sorry for my delay in response, I've been traveling. I'll leave this one up to Stephen as one of the drafts is mine and it might be a conflict for me to just say yes here. He's on vacation, but will be back soon enough. Thank you for the suggestion. On Tue, Jun 23, 2015 at 9:04 AM, Natasha Rooney wrote: > Hello all! > > I have a mildly leading question: at the next IETF93 will (or may > there?) there be a section on the SAAG agenda covering the following: > > [1] Ubiquitous Encryption Draft ( > http://www.ietf.org/id/draft-mm-wg-effect-encrypt-01.txt) > [2] Network management of encrypted traffic ( > https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/ > ) > [3] Confidentiality in the Face of Pervasive Surveillance ( > https://datatracker.ietf.org/doc/draft-iab-privsec-confidentiality-mitigations/ > )? > > I sent some stuff to [1] so would love to discuss them with people > there. I wonder if other people would find this useful? If not I am happy > with continuing on the mailing list! > > Thanks all! > > Natasha > > > Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com | +44 > (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org > Tokyo, Japan > > > This email and its attachments are intended for the above named only and > may be confidential. If they have come to you in error you must take no > action based on them, nor must you copy or show them to anyone; please > reply to this email or call +44 207 356 0600 and highlight the error. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Best regards, Kathleen --f46d043c0700840ef5051956ba2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Natasha,

Sorry for my delay in respo= nse, I've been traveling.=C2=A0 I'll leave this one up to Stephen a= s one of the drafts is mine and it might be a conflict for me to just say y= es here.=C2=A0 He's on vacation, but will be back soon enough.

Thank you for the suggestion.

On Tue, Jun 23, 2015 at 9:04 AM, N= atasha Rooney <nrooney@gsma.com> wrote:
Hello all!

I have a mildly leading question: at the next IETF93 will (or may ther= e?) there be a section on the SAAG agenda covering the following:

[2]=C2=A0Network management of encrypted traffic (https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-= management/)
[3]=C2=A0Confidentiality in the Face of Pervasive=C2=A0Surveillance (<= a href=3D"https://datatracker.ietf.org/doc/draft-iab-privsec-confidentialit= y-mitigations/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ia= b-privsec-confidentiality-mitigations/)?

I sent some stuff to [1] so would love to discuss them with people the= re. I wonder if other people would find this useful? If not I am happy with= continuing on the mailing list!

Thanks all!

Natasha


Natasha Rooney | Web Technologist |=C2=A0GSMA | nrooney@gsma.com | +44 (0)=C2=A07730 219 765 |= @thisNatasha | Skype:=C2=A0nrooney@gsm.org=C2=A0
Tokyo, Japan


This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag




--

Best regards,
Ka= thleen
--f46d043c0700840ef5051956ba2d-- From nobody Sun Jun 28 08:41:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3AF1A00B1; Tue, 23 Jun 2015 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYJWuk5t-7yu; Tue, 23 Jun 2015 05:41:24 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7DB1A0039; Tue, 23 Jun 2015 05:41:24 -0700 (PDT) Received: from 4.6.9.9.c.3.f.6.1.7.6.6.5.a.4.d.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:d4a5:6671:6f3c:9964]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Z7NVt-0002vP-FP; Tue, 23 Jun 2015 13:41:17 +0100 Message-ID: <558953F3.5040503@dial.pipex.com> Date: Tue, 23 Jun 2015 13:41:23 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> In-Reply-To: <20150622185239.GU14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 08:41:29 -0700 Cc: draft-ietf-dane-ops.all@tools.ietf.org, General area reviewing team , saag@ietf.org, dane@ietf.org Subject: Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 12:41:27 -0000 Hi, Viktor. Thanks for the quick response. I'll wait for the revised draft to revisit the RFC 2118 stuff. I think the TLS1.2 point and the reference to RFC6781 probably need to be discussed with Stephen as your AD. I can't see that you can operate DANE without a good understanding of how to operate DNSSEC (particularly on the rekeying aspects) and you explicitly call out timeout issues discussed in RFC6781. Whether this needs to administrative hassle of the downref is another matter. There is a bit about the OS issue in line below. Cheers, Elwyn On 22/06/2015 19:52, Viktor Dukhovni wrote: > On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote: > >> Summary: Almost ready. There are a couple of minor issues, and I think >> the authors need to reassess whether all the cases where RFC 2119 keyworrds >> are actually protocol requirements as opposed to operation best practice >> recommendations. > Thanks, will double-check the SHOULDS/MUSTS/... > >> s3: I am not a security expert, but I suspect you may get some pushback on >> not making TLS 1.2 mandatory. > We'll see what happens. The most widely deployed use of DANE is > with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like > an unnecessary restriction for an opportunistic protocol. However, > non-support of TLS 1.2 is getting increasingly less common, so if > push comes to shove, we can "require" TLS 1.2. Of course with no > Internet Police to enforce this, the requirement will likely make > little difference in practice. > >>> TLS clients and servers using DANE SHOULD support the >>> "Server Name Indication" (SNI) extension of TLS. >> Under what circumstances would it be reasonable for a DANE/TLSA server not >> to support SNI? Maybe I could see that a single domain server could do >> without it. > That's the primary use case, a server with a single certificate, > and a "3 1 1" TLSA record has no need to support SNI. It can just > respond with the same default certificate, regardless of the SNI > extension value sent by the client. > >> I think this needs to be spelt out - earlier text seems to >> indicate that SNI support was pretty much mandatory.... Ah! Later I see that >> s5.1 gives a case where SNI is not mandatory - a forward pointer would help. > Thanks, will try to make the text more consistent throughout. > >> s4.1: I am not clear that this section adds any value to the discussion in >> s4. Why should the protocol designer be less inclined to use PKIX-xx rather >> than DANE-xx when the protocol supports an OS mode as opposed to just fully >> authenticated or fully authenticated plus cleartext modes? > The basic principle is based on RFC7435. The issue is that PKIX > is more brittle, the client and server must happen to agree on a > mutually trusted CA, but with OS the client is just trying to > protect the communication at the request of the server, and would > otherwise be willing to use cleartext or unauthenticated TLS. Use > of fragile mechanisms (like public CA authentication for some > unspecified set of trusted CAs) is not sufficiently reliable. > > Since the OS client is basing the decision to employ DANE on the > presence of TLSA RRs in DNS, no additional security is gained via > the PKIX usages unless they are the only ones supported by the > application protocol (the attacker who compromises DNS can just > inject "3 1 1" records instead). So DANE-xx is more reliable > at no security loss. Thus PKIX-xx is just a needless opportunity > to fail that should be avoided. Maybe I have misunderstood how OS is intended to behave. I thought I understood that if the client was able to handle OS and it was not able to authenticate the server then it would potentially try for encryption only. Is the problem that there is a difference between there being no authentication available for a domain and an attempted authentication failing (aside from any explicit policy declared by server or client) when using OS? Otherwise I can't see that there is a difference between OS and the general case - in either case, using PKIX-xx is reckoned to be fragile and the process takes more resources without gaining anything. I can see the downside, but it appears to be general - is there an upside for OS in positively going for DANE-xx or is the downside further down in the case of OS? Otherwise there doesn't seem to be a lot of point in being more damning for the OS case (apart from it being a current topic of development :-) ). > >> Nits/editorial comments: >> ===================== > Will review those... thanks. > >> s17.2: I can't decide whether I would like RFC6781 to be normative. It would >> of course be a downref. This is always going to be a problem since the >> draft is combining operational considerations and protocol updates. The >> one explicit reference indicates you have to know something about how to run >> DNSSEC to run DANE - in practice I think you have to know a great deal about >> how to run DNSSEC if you are going to run DANE so I would be inclined to >> make this normative (and maybe refer to it in the introduction as well). > Not sure what if anything to do about that. > From nobody Sun Jun 28 08:41:32 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176481B2CD3; Tue, 23 Jun 2015 07:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6G8JT-BoFGh; Tue, 23 Jun 2015 07:58:33 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B271B2C75; Tue, 23 Jun 2015 07:58:33 -0700 (PDT) Received: from 4.6.9.9.c.3.f.6.1.7.6.6.5.a.4.d.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:d4a5:6671:6f3c:9964]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1Z7Peh-0001gw-FR; Tue, 23 Jun 2015 15:58:31 +0100 Message-ID: <5589741C.3020105@dial.pipex.com> Date: Tue, 23 Jun 2015 15:58:36 +0100 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: saag@ietf.org, dane@ietf.org References: <558851A5.20803@dial.pipex.com> <20150622185239.GU14121@mournblade.imrryr.org> <558953F3.5040503@dial.pipex.com> <20150623134227.GZ14121@mournblade.imrryr.org> In-Reply-To: <20150623134227.GZ14121@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 08:41:30 -0700 Subject: Re: [saag] Gen-art LC review of draft-ietf-dane-ops-12 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 14:58:36 -0000 Hi, Viktor. Thanks for clearing up my misunderstanding. I think it would be worth a sentence or two along the lines of what you have written below to clarify why OS is potentially more badly affected by fragile PKIX-xx behaviour. Cheers, Elwyn On 23/06/2015 14:42, Viktor Dukhovni wrote: > On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote: > >>> Since the OS client is basing the decision to employ DANE on the >>> presence of TLSA RRs in DNS, no additional security is gained via >>> the PKIX usages unless they are the only ones supported by the >>> application protocol (the attacker who compromises DNS can just >>> inject "3 1 1" records instead). So DANE-xx is more reliable >>> at no security loss. Thus PKIX-xx is just a needless opportunity >>> to fail that should be avoided. >> Maybe I have misunderstood how OS is intended to behave. I thought I >> understood that if the client was able to handle OS and it was not able to >> authenticate the server then it would potentially try for encryption only. > No, that is not the case. With opportunistic DANE TLS, when usable > secure (i.e. DNSSEC validated) TLSA records are present, but > authentication fails, there is typically no fallback to unauthenticated > TLS (mitigate downgrade attacks), for example: > > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2 > >> Is the problem that there is a difference between there being no >> authentication available for a domain and an attempted authentication >> failing (aside from any explicit policy declared by server or client) when >> using OS? > Yes, when no usable secure DANE TLSA records are absent, unauthenticated > TLS is used if possible, and if not perhaps even cleartext. However, > when TLSA records are published authentication must succeed. Thus > PKIX-xx auth are to be avoided, because outside the browser space, > there is no pre-ordained canon of trusted CAs, and in any case > there is no value in using them when DANE-xx usages are also > supported. For most application protocols there should be a clear > statement of which of the two pairs apply (DANE-xx or PKIX-xx) and > the other pair should not be used. > From nobody Mon Jun 29 07:19:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC91AC427 for ; Mon, 29 Jun 2015 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6VtpZT0IPWV for ; Mon, 29 Jun 2015 07:19:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31B11AC43B for ; Mon, 29 Jun 2015 07:19:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C348ABE3F for ; Mon, 29 Jun 2015 15:19:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjHtB6AY-PuL for ; Mon, 29 Jun 2015 15:19:12 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A552CBDF9 for ; Mon, 29 Jun 2015 15:19:12 +0100 (IST) Message-ID: <559153E0.5050102@cs.tcd.ie> Date: Mon, 29 Jun 2015 15:19:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "saag@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] AD sponsoring draft-josefsson-scrypt-kdf X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:19:27 -0000 Hiya, I've been asked to AD sponsor this draft [1] which seems like a fine enough idea. Please send feedback on that here in the next week or so if you can. I'll likely start an IETF LC after that depending on the response to this. Note that I've not verified the details of the algorithm as given in the draft so if someone is able to do that independent of the authors, that'd be a good thing. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-josefsson-scrypt-kdf/ From nobody Mon Jun 29 07:31:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E291D1ACCD8 for ; Mon, 29 Jun 2015 07:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TYtVDLr5yOh for ; Mon, 29 Jun 2015 07:31:06 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 93DD81ACC92 for ; Mon, 29 Jun 2015 07:31:06 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C04B74B807; Mon, 29 Jun 2015 14:31:05 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id AADB84B806; Mon, 29 Jun 2015 14:31:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1435588265; bh=J+eflQYgNMHBx50CCQ/+3yP44H9+VYZAQSg1oAO9T48=; h=From:To:Subject:Date:References:In-Reply-To:From; b=HuCLzO1jvUNax/ul5FgAloHV3L8yO9zKvfcXv8XQC7BQradm3TjE2ha7bIBfC2pTf kWK9WrCJwecizA9xvxGHXRLZSa6WA91Sj0KLBcseCI1E318quW5qIUkFYdb4kjBrUs D+wvilSZtpbsQObd4GvmS79A64vsHgYAE0qx5ARw= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A53AD98088; Mon, 29 Jun 2015 14:31:05 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 29 Jun 2015 09:31:05 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 29 Jun 2015 09:31:05 -0500 From: "Salz, Rich" To: Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] AD sponsoring draft-josefsson-scrypt-kdf Thread-Index: AQHQsnadNjClaWhd8EWAkuqq4UnStJ3Di2KA Date: Mon, 29 Jun 2015 14:31:04 +0000 Message-ID: <9ffbcf64034746bda380772e3359bda1@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <559153E0.5050102@cs.tcd.ie> In-Reply-To: <559153E0.5050102@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] AD sponsoring draft-josefsson-scrypt-kdf X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:31:08 -0000 > Note that I've not verified the details of the algorithm as given in the = draft so > if someone is able to do that independent of the authors, that'd be a goo= d > thing. OpenSSL has an implementation based on the document. From nobody Mon Jun 29 20:13:23 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8E1B2FCC for ; Mon, 29 Jun 2015 20:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhStRFxxBgRL for ; Mon, 29 Jun 2015 20:13:21 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170041B2FCE for ; Mon, 29 Jun 2015 20:13:21 -0700 (PDT) Received: by lagh6 with SMTP id h6so75824330lag.2 for ; Mon, 29 Jun 2015 20:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wTisPEyRiQ1Q67T3CH87FGLDRpzjPdwKghoVQI64J6Q=; b=D9PVNKATa7byQWNXH3aI6/vUJ1bXUQi+HcTGYgC0qRjyXJPBni0aoS4DlDbWGM+nIC SCdboZJrw18N0B3ojOwDrY2wH66eYRLaYPYg6H6phI7XVSmoEvF8rqa/I54/5r+R3SQ0 0LaNErKte8pWKahw8jTh6Pf1lmgb5PTaGNsJHynfTKzjmQ3l1CRoTQ7wjAsTZCvWQ8Xj YYMjSzJzgiNZ1pE0/nSxZhcie+DuA215AIVADqHGcHnvu4yMNBxlFR7by0dGG5l15rzV oeEPJdlHLItkfFXqH3otWfpeEkodZusQCWJRXiuBWthkE4yPrR61Evta9UJoAv9ELK6g L4TA== MIME-Version: 1.0 X-Received: by 10.112.164.35 with SMTP id yn3mr11965722lbb.91.1435633999523; Mon, 29 Jun 2015 20:13:19 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 29 Jun 2015 20:13:19 -0700 (PDT) In-Reply-To: <20150623151902.89304.qmail@ary.lan> References: <20150623151902.89304.qmail@ary.lan> Date: Mon, 29 Jun 2015 23:13:19 -0400 X-Google-Sender-Auth: 2Hpo5ESsflq3--zI8z0CiAvikeM Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: multipart/alternative; boundary=001a11c3353091b3430519b39687 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 03:13:22 -0000 --001a11c3353091b3430519b39687 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 23, 2015 at 11:19 AM, John Levine wrote: > I can't find in the archives whether the ubiquitous encryption > discussion has looked at the knotty issues of spam filtering. > > It's a really hard problem -- filtering is essential to keep mail > usable, both due to the sheer volume of the spam and the need to keep > phishing and malware away from recipients. You can do some filtering > on the envelope, but there's no substitute for looking at the contents > of the message. > > All of the middlebox issues apply, it's much easier to do the > filtering on a large shared server than at endpoints. Partly that's > because the endpoints often have limited bandwidth and compute power > (think phones) and partly it's because effective filtering needs to > consult shared frequently updated lists of malware signatures and > malicious urls. > I don't think it is actually much of a problem in practice. People just have to be prepared to accept that they probably don't want end-to-end encrypted mail from people they don't know. Once that is accepted, the solutions are fairly straightforward, the publicly visible email encryption key is to the spam filter, after a reply send an end to end key... Main constraint is that you don't want to accept end-to-end encrypted email unless it is signed by someone you know. So the endy mail problem becomes an introduction problem. --001a11c3353091b3430519b39687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 23, 2015 at 11:19 AM, John Levine <johnl@taugh.com> wrote:
I can't find in the arch= ives whether the ubiquitous encryption
discussion has looked at the knotty issues of spam filtering.

It's a really hard problem -- filtering is essential to keep mail
usable, both due to the sheer volume of the spam and the need to keep
phishing and malware away from recipients.=C2=A0 You can do some filtering<= br> on the envelope, but there's no substitute for looking at the contents<= br> of the message.

All of the middlebox issues apply, it's much easier to do the
filtering on a large shared server than at endpoints.=C2=A0 Partly that'= ;s
because the endpoints often have limited bandwidth and compute power
(think phones) and partly it's because effective filtering needs to
consult shared frequently updated lists of malware signatures and
malicious urls.

I don't think it is= actually much of a problem in practice. People just have to be prepared to= accept that they probably don't want end-to-end encrypted mail from pe= ople they don't know. Once that is accepted, the solutions are fairly s= traightforward, the publicly visible email encryption key is to the spam fi= lter, after a reply send an end to end key...

Main= constraint is that you don't want to accept end-to-end encrypted email= unless it is signed by someone you know. So the endy mail problem becomes = an introduction problem.=C2=A0
=C2=A0
--001a11c3353091b3430519b39687-- From nobody Mon Jun 29 23:27:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5931B36E9 for ; Mon, 29 Jun 2015 23:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6sXvrAz99EJ for ; Mon, 29 Jun 2015 23:27:55 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02C31B36E8 for ; Mon, 29 Jun 2015 23:27:55 -0700 (PDT) Received: from mb-aye.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t5U6Roox060542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2015 06:27:51 GMT (envelope-from joelja@bogus.com) To: Phillip Hallam-Baker , John Levine References: <20150623151902.89304.qmail@ary.lan> From: joel jaeggli Message-ID: <559236DF.7080203@bogus.com> Date: Mon, 29 Jun 2015 23:27:43 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cIW6HPPDdDO4itCP1KXPHOA9eIm2jVDnV" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 06:27:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cIW6HPPDdDO4itCP1KXPHOA9eIm2jVDnV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/29/15 8:13 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Tue, Jun 23, 2015 at 11:19 AM, John Levine > wrote: >=20 > I can't find in the archives whether the ubiquitous encryption > discussion has looked at the knotty issues of spam filtering. >=20 > It's a really hard problem -- filtering is essential to keep mail > usable, both due to the sheer volume of the spam and the need to ke= ep > phishing and malware away from recipients. You can do some filteri= ng > on the envelope, but there's no substitute for looking at the conte= nts > of the message. >=20 > All of the middlebox issues apply, it's much easier to do the > filtering on a large shared server than at endpoints. Partly that'= s > because the endpoints often have limited bandwidth and compute powe= r > (think phones) and partly it's because effective filtering needs to= > consult shared frequently updated lists of malware signatures and > malicious urls. >=20 >=20 > I don't think it is actually much of a problem in practice. People just= > have to be prepared to accept that they probably don't want end-to-end > encrypted mail from people they don't know. Once that is accepted, the > solutions are fairly straightforward, the publicly visible email > encryption key is to the spam filter, after a reply send an end to end > key... >=20 > Main constraint is that you don't want to accept end-to-end encrypted > email unless it is signed by someone you know. So the endy mail problem= > becomes an introduction problem.=20 The fact that parties that are known to each other have not in general been mutually authenticated is a, if not the, significant conduit of phishing. >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --cIW6HPPDdDO4itCP1KXPHOA9eIm2jVDnV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlWSNuAACgkQ8AA1q7Z/VrLaLwCeNmuRhYLZVBADNqb9zcIYFyZk rAsAn2uG/GXQQlgEFPz34Ew8geyjn88f =k6vv -----END PGP SIGNATURE----- --cIW6HPPDdDO4itCP1KXPHOA9eIm2jVDnV-- From nobody Mon Jun 29 23:46:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345F21B3702 for ; Mon, 29 Jun 2015 23:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwSrC-VV-Zaq for ; Mon, 29 Jun 2015 23:46:02 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DD21B36FE for ; Mon, 29 Jun 2015 23:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1616; q=dns/txt; s=iport; t=1435646763; x=1436856363; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=GezTC8rCHxmBTvHHNDtGdpzdzc0dFI65MnmPdoLOMNo=; b=JbGB0AuTGagXTzcfDNjQxJMpOtCaXaGqKF6iZI0bdZ1XAANlbYIGu36Z fSG0uPkdr37vWoto2hld+u9t1ww62MMxc260O/rE087uc+Yh46mfMBzsG JHytLZ0XI2UjgXkEdKDqANcVxE6xXebnCtyXmrqbYaFVBkEX3EXwmOZGL 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CDAwCSOpJV/xbLJq1bh2K6EwmHXwKBdBQBAQEBAQEBgQqEIwEBBCNWEAshIQICDwJGBgEMAQcBAYgrs1aWeQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLSoQjEAIBUAeCaIFDAQSUBIIlgVCHYIg2kAUmg3w8gnkBAQE X-IronPort-AV: E=Sophos;i="5.15,375,1432598400"; d="asc'?scan'208";a="567478448" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 30 Jun 2015 06:46:01 +0000 Received: from [10.61.222.239] ([10.61.222.239]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5U6jx6u026602; Tue, 30 Jun 2015 06:45:59 GMT Message-ID: <55923B28.70305@cisco.com> Date: Tue, 30 Jun 2015 08:46:00 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: joel jaeggli , Phillip Hallam-Baker , John Levine References: <20150623151902.89304.qmail@ary.lan> <559236DF.7080203@bogus.com> In-Reply-To: <559236DF.7080203@bogus.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5neJtC3qdodhR93XwET0uVj9Qjm85q272" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 06:46:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5neJtC3qdodhR93XwET0uVj9Qjm85q272 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 6/30/15 8:27 AM, joel jaeggli wrote: >> >> Main constraint is that you don't want to accept end-to-end encrypted >> email unless it is signed by someone you know. So the endy mail proble= m >> becomes an introduction problem.=20 > The fact that parties that are known to each other have not in general > been mutually authenticated is a, if not the, significant conduit of > phishing. > > That is A component but not THE component. When someone gets hacked, the bad guy usually has access to sufficient bonafides to get something through the MSA. To avoid this we would have to go to OOB authentication systems, and that just ain't happening. Eliot --5neJtC3qdodhR93XwET0uVj9Qjm85q272 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVkjspAAoJEIe2a0bZ0nozOSIH/1pSJsYrvpuXz6Yqg0bOYktP BEewQaGjQX4OGKJJh4AxMQQlJHO5AJy02XgxsIhFao7h3w8wpouJRqES18onCSzw 2sXyvQyDo351kKgYroVzShSKed2dJO2BtcQksLb4vD/GIRMsIWlp1yEyaqd9HflW mYbvI4LA7wpek6I3GvTun7/FehdCVDCt5yyVldhqUc5zQEqog2cjSJHrAwfzC4la KcTppFA0yWn3Ti+Jymcyvoase62Y5j/Hw5vThFDRdFq9hc24rL981ZIGbuFr/s47 xT5mqWTk4+r8xfEtO9iAShsGXGfZAjHrRBkOIhWNfZyYanTcsv0SQUx53rXOg4s= =uupy -----END PGP SIGNATURE----- --5neJtC3qdodhR93XwET0uVj9Qjm85q272-- From nobody Tue Jun 30 03:22:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4C1A90C0 for ; Tue, 30 Jun 2015 03:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na5-pUav-3Ko for ; Tue, 30 Jun 2015 03:22:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503F21A904A for ; Tue, 30 Jun 2015 03:22:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65123BE39; Tue, 30 Jun 2015 11:22:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PaMbLMnWWV9; Tue, 30 Jun 2015 11:22:48 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CEB6BBE3F; Tue, 30 Jun 2015 11:22:46 +0100 (IST) Message-ID: <55926DF7.7030200@cs.tcd.ie> Date: Tue, 30 Jun 2015 11:22:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russ Housley , IETF SAAG References: <555FA6C5.5000004@cs.tcd.ie> <7E913E68-968E-40D4-A26E-75B4D438E92F@vigilsec.com> In-Reply-To: <7E913E68-968E-40D4-A26E-75B4D438E92F@vigilsec.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD sponsoring draft-iab-crypto-alg-agility X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 10:22:53 -0000 Hiya, Now that I'm back from me holliers, I had a read of this and I think it captures all the main points made in the list discussion. But I might have missed something, (I see 183 messages on this draft in my local archive of the saag list;-) so if there's something from the discussion that you figure wasn't captured and that ought go into the draft, can you point that out in the next few days? There were places the discussion ranged beyond what ought go into this draft - to be clear, I'm not asking that we re-do all that discussion so please try limit this to stuff that's missing from, or badly wrong in, -05. There's clearly another rev needed, as is indicated in the document itself, but it'd be good if that were basically editorial, e.g. re-structuring to make it flow better. My hope is that the -06 version could be ready for IETF LC if nothing major shows up now as having been missed in -05. Thanks, S. On 04/06/15 23:26, Russ Housley wrote: > Based on the discussion on this thread, I have made many updates. A new version (-05) was just posted: > https://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-05.txt > > The diff from previous version is here: > https://www.ietf.org/rfcdiff?url2=draft-iab-crypto-alg-agility-05 > > Thanks for all of the helpful discussion. > > Russ > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Jun 30 11:43:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04AD1B2B0B for ; Tue, 30 Jun 2015 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nYuVgWR_MJg for ; Tue, 30 Jun 2015 11:43:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E174A1B2B0C for ; Tue, 30 Jun 2015 11:43:00 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t5UIglF2023716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Jun 2015 11:42:51 -0700 Message-ID: <5592E326.4050804@dcrocker.net> Date: Tue, 30 Jun 2015 11:42:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: joel jaeggli , Phillip Hallam-Baker , John Levine References: <20150623151902.89304.qmail@ary.lan> <559236DF.7080203@bogus.com> In-Reply-To: <559236DF.7080203@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 30 Jun 2015 11:42:51 -0700 (PDT) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 18:43:02 -0000 On 6/29/2015 11:27 PM, joel jaeggli wrote: > On 6/29/15 8:13 PM, Phillip Hallam-Baker wrote: >> Main constraint is that you don't want to accept end-to-end encrypted >> email unless it is signed by someone you know. So the endy mail problem >> becomes an introduction problem. > > The fact that parties that are known to each other have not in general > been mutually authenticated is a, if not the, significant conduit of > phishing. There is a very strong tendency to try to characterize one or another underlying aspect of human communication as simple, and therefore to believe that imposing adequate quality control on its conduct is relatively straightforward. As an example, new contacts from individuals with whom one has had no previous contact, constitute an essential component of human communication. The constraint stated at the top of this message would eliminate that capability. (Another problem with the constraint is that, as noted, it ignores various other abuse vectors that are based on exploiting those we already know.) For every line of anti-abuse pursuit or proposed mechanism for controlling it, one should always begin by asking how badly it is Procrustean and whether chopping or stretching online communications that little bit more really is tolerable. When the answer is yes, consider carefully who is making the assessment and what gives them the right to add that (global) restriction... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 30 12:54:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88B1B2C8D for ; Tue, 30 Jun 2015 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg4arzQWn0Sa for ; Tue, 30 Jun 2015 12:54:33 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4FC1B2B29 for ; Tue, 30 Jun 2015 12:54:33 -0700 (PDT) Received: by lagh6 with SMTP id h6so26972938lag.2 for ; Tue, 30 Jun 2015 12:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MBxnZeuChYgV9AeCl0WM5DUx/fDb8iu5Hoblcab5Eh4=; b=lUvdG8jRQnlRPCzUEq8FyARN+TRqQ36C8DZvhvpCtwYeuT27ahNdNH72UfotZepjgS lxwDv55eFafEmlHYQnh0+4ihz3pbnXTkO2eHiAxieIVSg4C2tw9Sfbw2RpY5xCRh0EAB uz63azLMoaGeOa226+B+h4whXWqDqn8LslHgg4eCszQow+/DFdirLPObRVSh8qFcHlZE oAuQJwXCiu8T0/k/b3QAk4ccJto3U0SaaZuiUXjJ6BwyZq8CbkyudHeAps6nV276OO/g FAjsFs48pH3xnSL/pbPV+VuzW90kLN+AQZSUnK9WpSUEdqh7fE4jaiU9izBdQVtSB6bE NSmA== MIME-Version: 1.0 X-Received: by 10.112.164.35 with SMTP id yn3mr15984220lbb.91.1435694071266; Tue, 30 Jun 2015 12:54:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Tue, 30 Jun 2015 12:54:31 -0700 (PDT) In-Reply-To: <559236DF.7080203@bogus.com> References: <20150623151902.89304.qmail@ary.lan> <559236DF.7080203@bogus.com> Date: Tue, 30 Jun 2015 15:54:31 -0400 X-Google-Sender-Auth: 8m4-Ml6LbCFsz_lFm-XpSkacnc8 Message-ID: From: Phillip Hallam-Baker To: joel jaeggli Content-Type: multipart/alternative; boundary=001a11c335301fc7ba0519c19374 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:54:35 -0000 --001a11c335301fc7ba0519c19374 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 2:27 AM, joel jaeggli wrote: > On 6/29/15 8:13 PM, Phillip Hallam-Baker wrote: > > > > > > On Tue, Jun 23, 2015 at 11:19 AM, John Levine > > wrote: > > > > I can't find in the archives whether the ubiquitous encryption > > discussion has looked at the knotty issues of spam filtering. > > > > It's a really hard problem -- filtering is essential to keep mail > > usable, both due to the sheer volume of the spam and the need to keep > > phishing and malware away from recipients. You can do some filtering > > on the envelope, but there's no substitute for looking at the > contents > > of the message. > > > > All of the middlebox issues apply, it's much easier to do the > > filtering on a large shared server than at endpoints. Partly that's > > because the endpoints often have limited bandwidth and compute power > > (think phones) and partly it's because effective filtering needs to > > consult shared frequently updated lists of malware signatures and > > malicious urls. > > > > > > I don't think it is actually much of a problem in practice. People just > > have to be prepared to accept that they probably don't want end-to-end > > encrypted mail from people they don't know. Once that is accepted, the > > solutions are fairly straightforward, the publicly visible email > > encryption key is to the spam filter, after a reply send an end to end > > key... > > > > Main constraint is that you don't want to accept end-to-end encrypted > > email unless it is signed by someone you know. So the endy mail problem > > becomes an introduction problem. > > The fact that parties that are known to each other have not in general > been mutually authenticated is a, if not the, significant conduit of > phishing. The first last and only reason phishing is possible is that we use authentication credentials that we expect people to keep in their head, never write down and only ever give them to people who are trustworthy. Needless to say, the result has been a fiasco. If a tenth the amount of whining that goes on complaining about the occasional failures of the part of the Web security infrastructure that (mostly) works had gone into avoiding relying on usernames and passwords thirty years after crack. --001a11c335301fc7ba0519c19374 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 2:27 AM, joel jaeggli <joelja@bogus.com>= wrote:
On 6/29/1= 5 8:13 PM, Phillip Hallam-Baker wrote:
>
>
> On Tue, Jun 23, 2015 at 11:19 AM, John Levine <johnl@taugh.com
> <mailto:johnl@taugh.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I can't find in the archives whether the ubiqui= tous encryption
>=C2=A0 =C2=A0 =C2=A0discussion has looked at the knotty issues of spam = filtering.
>
>=C2=A0 =C2=A0 =C2=A0It's a really hard problem -- filtering is esse= ntial to keep mail
>=C2=A0 =C2=A0 =C2=A0usable, both due to the sheer volume of the spam an= d the need to keep
>=C2=A0 =C2=A0 =C2=A0phishing and malware away from recipients.=C2=A0 Yo= u can do some filtering
>=C2=A0 =C2=A0 =C2=A0on the envelope, but there's no substitute for = looking at the contents
>=C2=A0 =C2=A0 =C2=A0of the message.
>
>=C2=A0 =C2=A0 =C2=A0All of the middlebox issues apply, it's much ea= sier to do the
>=C2=A0 =C2=A0 =C2=A0filtering on a large shared server than at endpoint= s.=C2=A0 Partly that's
>=C2=A0 =C2=A0 =C2=A0because the endpoints often have limited bandwidth = and compute power
>=C2=A0 =C2=A0 =C2=A0(think phones) and partly it's because effectiv= e filtering needs to
>=C2=A0 =C2=A0 =C2=A0consult shared frequently updated lists of malware = signatures and
>=C2=A0 =C2=A0 =C2=A0malicious urls.
>
>
> I don't think it is actually much of a problem in practice. People= just
> have to be prepared to accept that they probably don't want end-to= -end
> encrypted mail from people they don't know. Once that is accepted,= the
> solutions are fairly straightforward, the publicly visible email
> encryption key is to the spam filter, after a reply send an end to end=
> key...
>
> Main constraint is that you don't want to accept end-to-end encryp= ted
> email unless it is signed by someone you know. So the endy mail proble= m
> becomes an introduction problem.

The fact that parties that are known to each other have not in = general
been mutually authenticated is a, if not the, significant conduit of
phishing.

The first last and only reason ph= ishing is possible is that we use authentication credentials that we expect= people to keep in their head, never write down and only ever give them to = people who are trustworthy.

Needless to say, the r= esult has been a fiasco.

If a tenth the amount of = whining that goes on complaining about the occasional failures of the part = of the Web security infrastructure that (mostly) works had gone into avoidi= ng relying on usernames and passwords thirty years after crack.
=
--001a11c335301fc7ba0519c19374-- From nobody Tue Jun 30 13:04:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08151B2CAB for ; Tue, 30 Jun 2015 13:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNAGBLw6oiBu for ; Tue, 30 Jun 2015 13:04:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5151B2CAD for ; Tue, 30 Jun 2015 13:04:28 -0700 (PDT) Received: (qmail 29124 invoked from network); 30 Jun 2015 20:04:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=71c2.5592f657.k1506; bh=EP+Wr0Y/CnIIwuVGTVWwdC4cXdn5El6nZrqjHrxFgJs=; b=F1WYU4suVeolDTtIlyo+krMoR3NrLtgYdjLk7YQ+bKr/1ylRKaf4y9YSNm6BmoRa8QjvKwRXVG1ynWSfMOq0/iGGMOX150O3Lx2brC9sYZ6opSaNOsid7todLkORLKLgUVLeP/WXTLAdm9x4ouB5lk08GNvlnPId6SrRsVqaOJNujxV807/kt6L6pxCd2kBHc3hPbGpE2D4fDWtdjqfwYOWDZgT42uRhPAeJHBdlfx7zBlTHClMU0nfPUIosXfSV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=71c2.5592f657.k1506; bh=EP+Wr0Y/CnIIwuVGTVWwdC4cXdn5El6nZrqjHrxFgJs=; b=l0M/muL7TKg1pd7kOZQ1yqUjpguBt5DkFtgFvraiV/dmK/PvCsXWfBsust+CDUe2DsMAr7s4v8mW5ImZDzJ5wsu4zU/uFFyfPOqTz988kYjOlGetofidVYcJI5E9gDK0tH3J3PP4yBmVYeJJU/O4xvm+Rqeh3lVXP6jbIyB93lCUq/au0d9LFvrVZgU2nnUOFRbwaasxHMdCvIE3sq9vfLOj3aRS1reupI6Tejp2MyO+r2Ui8S+h8X9BH0bFHaQi Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 30 Jun 2015 20:04:38 -0000 Date: 30 Jun 2015 16:04:25 -0400 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" In-Reply-To: References: <20150623151902.89304.qmail@ary.lan> <559236DF.7080203@bogus.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Ubiquitous Encryption: spam filtering X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 20:04:29 -0000 > The first last and only reason phishing is possible is that we use > authentication credentials that we expect people to keep in their head, > never write down and only ever give them to people who are trustworthy. That's some of it, but I've seen malware that does MITM attacks to redirect transactions authenticated with uncompromised two-factor devices. If all of the pieces are used exactly correctly, you're pretty secure, but we know how likely that is in the long term. Like I said about spam, it's a hard problem. In spam, exempting people you know from spam filtering doesn't work. Partly that's because the introduction problem is as hard as the spam problem, partly that's because it'll just push spammers toward using compromised legit accounts, something they do a lot of already. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail.