From bittau@gmail.com  Mon Aug  1 12:15:43 2011
Return-Path: <bittau@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5092421F8DE9; Mon,  1 Aug 2011 12:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.991
X-Spam-Level: 
X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=0.608,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRaVftl0ncCV; Mon,  1 Aug 2011 12:15:42 -0700 (PDT)
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id B5DDF21F8D9A; Mon,  1 Aug 2011 12:15:42 -0700 (PDT)
Received: by pzk6 with SMTP id 6so11133451pzk.26 for <multiple recipients>; Mon, 01 Aug 2011 12:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-echelon:user-agent; bh=z2MD7wkTQHlx/P/Je6Nn7x7KoBfi0S6f894FqsZd9rs=; b=qxMwR/FrdNFcpnb3alIe/OVGomR8HiOwAmx+gISy/dl3cGfvy/UFhGGRJxo5ejjZlc WjNCUFqaPwUVxw9y47qgWJYguxB4M/cLgXOL4GE4JTf3NYrQmLWjjyWBnZGgCWbrdIbf ZOCa4GuaBSYsyeM2yNQBrMt+N9P88yp5ES9do=
Received: by 10.68.1.135 with SMTP id 7mr8720500pbm.53.1312226149663; Mon, 01 Aug 2011 12:15:49 -0700 (PDT)
Received: from tapir.cs.ucl.ac.uk (sorbo.scs.stanford.edu [171.66.3.100]) by mx.google.com with ESMTPS id d3sm3178253pbg.12.2011.08.01.12.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Aug 2011 12:15:48 -0700 (PDT)
Sender: Andrea Bittau <bittau@gmail.com>
Received: by tapir.cs.ucl.ac.uk (Postfix, from userid 0) id 808584810171; Mon,  1 Aug 2011 12:14:07 -0700 (PDT)
Date: Mon, 1 Aug 2011 12:14:07 -0700
From: Andrea Bittau <bittau@cs.stanford.edu>
To: "David A. McGrew" <david.a.mcgrew@mindspring.com>
Message-ID: <20110801191407.GA3765@shorty>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
X-Echelon: Bush Bomb War KGB
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 19:15:43 -0000

On Mon, Aug 01, 2011 at 10:25:14AM -0700, David A. McGrew wrote:
> This sounds like an option worth pursuing, no pun intended.  You
> make good points about why TCP is a good place to do the capability
> discovery and fallback for crypto.   Why not define a TCP option
> that can enable devices to discover TLS or tcpcrypt or other
> higher-layer crypto protocols?   That option would be much easier to
> implement and standardize, and it could tie into a full tcpcrypt
> protocol that resides in a shim above the TCP layer.  The separation
> will create useful implementation alternatives, and will isolate the
> TCP state machine from changes.

We have been considering this option throughout the work (and will still
do) but:

* No TCP header protection.  TCP-AO, which you suggest, does not
  interoperate with NATs.  We want something that works "out of the
  box".

* We can't leverage the 3-way handshake if operating at the application
  layer.  With tcpcrypt, we can do all session key negotiation in a
  4-way handshake (just one extra leg), or 3 if session caching.  Saving
  RTTs seems like a good thing.

>From a clean-slate perspective, it seems that integrating this into TCP
has all the advantages we're looking for.  Doing minimal work at TCP
(like a signle "do you crypto?" option) and doing the rest at an
application layer seems to come at a compromise (e.g., the drawbacks
listed above).

>From an implementation perspective, I agree that the least changes to
TCP are probably the best option.  tcpcrypt, at least for us, seems to
have a good balance between clean-slate and (relatively) few changes to
TCP, hence why we're pushing for it, as is.  If there were
non-implementation arguments as to app vs. transport layer we'd love to
hear those.

From Jeff.Hodges@KingsMountain.com  Mon Aug  1 13:17:54 2011
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE1D21F8D39 for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 13:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.615
X-Spam-Level: 
X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXh6z8x75ojV for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 13:17:53 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id ECC4A21F8C1B for <saag@ietf.org>; Mon,  1 Aug 2011 13:17:33 -0700 (PDT)
Received: (qmail 5245 invoked by uid 0); 1 Aug 2011 04:17:41 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 1 Aug 2011 04:17:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=2ASRaZxWIdVvEtY7gNUwyx69k1cSq8g4o12K8C4UR94=;  b=kCeH4qeAbJ+yVvzwHFe6rSl6pxcSZ48yOMrWiO0f2Yw2Ljhc93Iu3Z1Zd0CmtUt/a/cfYyBStPISGtr9CoQCOycWPZwdjEYccxco/p2yL+S/Qb+f8YCeMMU2FQemZA5A;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Qnjwj-00036t-Bv for saag@ietf.org; Sun, 31 Jul 2011 22:17:41 -0600
Message-ID: <4E3628E4.2070008@KingsMountain.com>
Date: Sun, 31 Jul 2011 21:17:40 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: IETF Security Area Advisory Group <saag@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Subject: [saag] fyi: talk @ Stanford: Owning the Routing Table - New OSPF Attacks - FRIDAY - AUG 5
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 20:17:54 -0000

[ perhaps something to share with ospf@ietf.org  nor 
routing-discussion@ietf.org ?  (I'm not sub'd to those lists) ]


Subject: FRIDAY - AUG 5 - Owning the Routing Table - New OSPF Attacks -
	Nakibly Gabi
From: Ankur Taly <ataly@stanford.edu>
Date: Fri, 29 Jul 2011 23:08:46 -0700 (PDT)
To: security-seminar <security-seminar@lists.stanford.edu>
Cc: Nakibly Gabi <gabin@rafael.co.il>

TITLE: Owning the Routing Table - New OSPF Attacks

SPEAKER: Nakibly Gabi

ABSTRACT: The holy grail of routing attacks is owning the routing table of a 
router. We present new found vulnerabilities in the OSPF protocol - the most 
popular routing protocol inside autonomous systems (AS) - which allow to own a 
router's routing table without having to own the router itself. We present new 
attacks that falsify the LSAs of routers not controlled by the attacker while 
evading the "fight-back" mechanism. These attacks affords a single attacker a 
great power to persistently falsify large portions of the routing domain's 
topology. This may be utilized to induce routing loops, network cuts or longer 
routes in order to facilitate DoS of the routing domain or to gain access to 
information flows which otherwise the attacker had no access to. This is a 
joint work with Alex Kirshon and Dima Gonikman. The talk shall be presented at 
Black Hat USA 2011.

Venue: Gates 463
Time: 4:30 pm
Date: 5 August 2011 (Friday)

--++**==--++**==--++**==--++**==--++**==--++**==--++**==
security-seminar mailing list
security-seminar@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/security-seminar

From touch@isi.edu  Mon Aug  1 13:20:02 2011
Return-Path: <touch@isi.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B89E21F8D3F; Mon,  1 Aug 2011 13:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.345
X-Spam-Level: 
X-Spam-Status: No, score=-105.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGzTv9-rlQcy; Mon,  1 Aug 2011 13:20:02 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1721F8D18; Mon,  1 Aug 2011 13:20:01 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p71KJgoF027995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2011 13:19:43 -0700 (PDT)
Message-ID: <4E370A5E.1050608@isi.edu>
Date: Mon, 01 Aug 2011 13:19:42 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "David A. McGrew" <david.a.mcgrew@mindspring.com>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
In-Reply-To: <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 20:20:02 -0000

On 8/1/2011 10:25 AM, David A. McGrew wrote:
...
>> But we lose all
>> TCP header MACing - e.g., someone can RST our connection. TCP AO
>> suggests that MACing TCP headers is important so crypto protocols should
>> do that (hence why we live in the transport layer).
>
> True, but why not design tcpcrypt so that it make use of TCP-AO? That
> seems like an approach that would work with the separation outlined above.

TCP-AO could easily support a mode where the TCP body was encrypted, 
e.g., where the encryption algorithm were defined to use the connection 
context (TCP header, IP pseudoheader) as context.

I had been planning on working that into the experimental TCP-AO NAT 
doc, since it could be as useful as the NAT variant.

That won't help initialize the keys, as would be needed before the SYN 
arrives for TCP-AO. That sort of in-band keying was excluded from TCP-AO 
to keep the SYN header size down.

Joe


From vishwas.ietf@gmail.com  Mon Aug  1 13:25:36 2011
Return-Path: <vishwas.ietf@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC121F8B7C for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 13:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level: 
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4BoPW1o4Waj for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 13:25:35 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45D5D21F8B79 for <saag@ietf.org>; Mon,  1 Aug 2011 13:25:35 -0700 (PDT)
Received: by vxi40 with SMTP id 40so5719191vxi.31 for <saag@ietf.org>; Mon, 01 Aug 2011 13:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JmjElv3wzcSd/yT68oJJPNb9Rin/0ZiyIsS0ddcsrSM=; b=uKht4Zw2vJMwNHme0cj8UQZ44ucK8/6ZXe+KDGwXAUMPzz4FpX5+Jw+K4vXaGrEEcs 1tVMgeWM64hHFlfSqscWiK11P6rW1K8BeXm4V2/IJ1HIAlMgt0K9Rep19vmncGg162TL iuiw7wa82RbzCE2UewoDlJrdbEg+hCodZtXf4=
MIME-Version: 1.0
Received: by 10.52.173.111 with SMTP id bj15mr3498262vdc.73.1312230342037; Mon, 01 Aug 2011 13:25:42 -0700 (PDT)
Received: by 10.52.156.161 with HTTP; Mon, 1 Aug 2011 13:25:41 -0700 (PDT)
In-Reply-To: <4E3628E4.2070008@KingsMountain.com>
References: <4E3628E4.2070008@KingsMountain.com>
Date: Mon, 1 Aug 2011 13:25:41 -0700
Message-ID: <CAOyVPHTApJ3X50HAZ13xKGXQ7j5uJ1pdOx0DfJPoukML1qZuCQ@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: multipart/alternative; boundary=bcaec51b9ee5668f6a04a9776f07
Cc: IETF Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] fyi: talk @ Stanford: Owning the Routing Table - New OSPF Attacks - FRIDAY - AUG 5
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 20:25:36 -0000

--bcaec51b9ee5668f6a04a9776f07
Content-Type: text/plain; charset=ISO-8859-1

Hi Jeff,

Thanks for forwarding this. Let me try to get more details of what they are
trying to do here.

I am not sure what new vulnerabilities they have found. However from what I
see it looks like things we well know and by the issues can be negated by
using authentication in OSPF.

Also it is well known that if a router in a domain is compormised and
accepts unauthenticated packets, it can cause routing issues /which means
loops/ blackholes etc. Sounds liek they may be using a higher sequence
number LSA of a router they do not control, which can disrupt routing.

Thanks,
Vishwas
On Sun, Jul 31, 2011 at 9:17 PM, =JeffH <Jeff.Hodges@kingsmountain.com>wrote:

> [ perhaps something to share with ospf@ietf.org  nor
> routing-discussion@ietf.org ?  (I'm not sub'd to those lists) ]
>
>
> Subject: FRIDAY - AUG 5 - Owning the Routing Table - New OSPF Attacks -
>        Nakibly Gabi
> From: Ankur Taly <ataly@stanford.edu>
> Date: Fri, 29 Jul 2011 23:08:46 -0700 (PDT)
> To: security-seminar <security-seminar@lists.**stanford.edu<security-seminar@lists.stanford.edu>
> >
> Cc: Nakibly Gabi <gabin@rafael.co.il>
>
> TITLE: Owning the Routing Table - New OSPF Attacks
>
> SPEAKER: Nakibly Gabi
>
> ABSTRACT: The holy grail of routing attacks is owning the routing table of
> a router. We present new found vulnerabilities in the OSPF protocol - the
> most popular routing protocol inside autonomous systems (AS) - which allow
> to own a router's routing table without having to own the router itself. We
> present new attacks that falsify the LSAs of routers not controlled by the
> attacker while evading the "fight-back" mechanism. These attacks affords a
> single attacker a great power to persistently falsify large portions of the
> routing domain's topology. This may be utilized to induce routing loops,
> network cuts or longer routes in order to facilitate DoS of the routing
> domain or to gain access to information flows which otherwise the attacker
> had no access to. This is a joint work with Alex Kirshon and Dima Gonikman.
> The talk shall be presented at Black Hat USA 2011.
>
> Venue: Gates 463
> Time: 4:30 pm
> Date: 5 August 2011 (Friday)
>
> --++**==--++**==--++**==--++****==--++**==--++**==--++**==
> security-seminar mailing list
> security-seminar@lists.**stanford.edu<security-seminar@lists.stanford.edu>
> https://mailman.stanford.edu/**mailman/listinfo/security-**seminar<https://mailman.stanford.edu/mailman/listinfo/security-seminar>
> ______________________________**_________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/**listinfo/saag<https://www.ietf.org/mailman/listinfo/saag>
>

--bcaec51b9ee5668f6a04a9776f07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi Jeff,</div>
<div>=A0</div>
<div>Thanks for forwarding this. Let me try to get more details of what the=
y are trying to do here.</div>
<div>=A0</div>
<div>I am not sure what new vulnerabilities they have found. However from w=
hat I see it looks like things we well know and by the issues can be negate=
d by using authentication in OSPF.=A0</div>
<div>=A0</div>
<div>Also it=A0is well known that if a router in a domain is compormised an=
d accepts unauthenticated packets, it can cause routing issues /which means=
 loops/ blackholes etc. Sounds liek they may be using a higher sequence num=
ber LSA of a router they do not control, which can disrupt routing.</div>

<div>=A0</div>
<div>Thanks,</div>
<div>Vishwas<br></div>
<div class=3D"gmail_quote">On Sun, Jul 31, 2011 at 9:17 PM, =3DJeffH <span =
dir=3D"ltr">&lt;<a href=3D"mailto:Jeff.Hodges@kingsmountain.com">Jeff.Hodge=
s@kingsmountain.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">[ perhaps something to share wit=
h <a href=3D"mailto:ospf@ietf.org" target=3D"_blank">ospf@ietf.org</a> =A0n=
or <a href=3D"mailto:routing-discussion@ietf.org" target=3D"_blank">routing=
-discussion@ietf.org</a> ? =A0(I&#39;m not sub&#39;d to those lists) ]<br>
<br><br>Subject: FRIDAY - AUG 5 - Owning the Routing Table - New OSPF Attac=
ks -<br>=A0 =A0 =A0 =A0Nakibly Gabi<br>From: Ankur Taly &lt;<a href=3D"mail=
to:ataly@stanford.edu" target=3D"_blank">ataly@stanford.edu</a>&gt;<br>Date=
: Fri, 29 Jul 2011 23:08:46 -0700 (PDT)<br>
To: security-seminar &lt;<a href=3D"mailto:security-seminar@lists.stanford.=
edu" target=3D"_blank">security-seminar@lists.<u></u>stanford.edu</a>&gt;<b=
r>Cc: Nakibly Gabi &lt;<a href=3D"mailto:gabin@rafael.co.il" target=3D"_bla=
nk">gabin@rafael.co.il</a>&gt;<br>
<br>TITLE: Owning the Routing Table - New OSPF Attacks<br><br>SPEAKER: Naki=
bly Gabi<br><br>ABSTRACT: The holy grail of routing attacks is owning the r=
outing table of a router. We present new found vulnerabilities in the OSPF =
protocol - the most popular routing protocol inside autonomous systems (AS)=
 - which allow to own a router&#39;s routing table without having to own th=
e router itself. We present new attacks that falsify the LSAs of routers no=
t controlled by the attacker while evading the &quot;fight-back&quot; mecha=
nism. These attacks affords a single attacker a great power to persistently=
 falsify large portions of the routing domain&#39;s topology. This may be u=
tilized to induce routing loops, network cuts or longer routes in order to =
facilitate DoS of the routing domain or to gain access to information flows=
 which otherwise the attacker had no access to. This is a joint work with A=
lex Kirshon and Dima Gonikman. The talk shall be presented at Black Hat USA=
 2011.<br>
<br>Venue: Gates 463<br>Time: 4:30 pm<br>Date: 5 August 2011 (Friday)<br><b=
r>--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**<u></u>=3D=3D--++**=3D=3D--++**=
=3D=3D--++**=3D=3D<br>security-seminar mailing list<br><a href=3D"mailto:se=
curity-seminar@lists.stanford.edu" target=3D"_blank">security-seminar@lists=
.<u></u>stanford.edu</a><br>
<a href=3D"https://mailman.stanford.edu/mailman/listinfo/security-seminar" =
target=3D"_blank">https://mailman.stanford.edu/<u></u>mailman/listinfo/secu=
rity-<u></u>seminar</a><br>______________________________<u></u>___________=
______<br>
saag mailing list<br><a href=3D"mailto:saag@ietf.org" target=3D"_blank">saa=
g@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/saag" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/saag</a><br></=
blockquote>
</div><br>

--bcaec51b9ee5668f6a04a9776f07--

From touch@isi.edu  Mon Aug  1 17:50:53 2011
Return-Path: <touch@isi.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CBC1F0C51; Mon,  1 Aug 2011 17:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.323
X-Spam-Level: 
X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6e7p9t-dVr4; Mon,  1 Aug 2011 17:50:51 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8B1F0C49; Mon,  1 Aug 2011 17:50:48 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p720oPvM016591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Aug 2011 17:50:26 -0700 (PDT)
Message-ID: <4E3749D1.4000403@isi.edu>
Date: Mon, 01 Aug 2011 17:50:25 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "David A. McGrew" <david.a.mcgrew@mindspring.com>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <4E370A5E.1050608@isi.edu> <45875A47-E146-40F9-9B90-96AD015BBC85@mindspring.com>
In-Reply-To: <45875A47-E146-40F9-9B90-96AD015BBC85@mindspring.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 00:50:53 -0000

On 8/1/2011 5:37 PM, David A. McGrew wrote:
>
> On Aug 1, 2011, at 1:19 PM, Joe Touch wrote:
>
>>
>>
>> On 8/1/2011 10:25 AM, David A. McGrew wrote:
>> ...
>>>> But we lose all
>>>> TCP header MACing - e.g., someone can RST our connection. TCP AO
>>>> suggests that MACing TCP headers is important so crypto protocols
>>>> should
>>>> do that (hence why we live in the transport layer).
>>>
>>> True, but why not design tcpcrypt so that it make use of TCP-AO? That
>>> seems like an approach that would work with the separation outlined
>>> above.
>>
>> TCP-AO could easily support a mode where the TCP body was encrypted,
>> e.g., where the encryption algorithm were defined to use the
>> connection context (TCP header, IP pseudoheader) as context.
>
> It occurs to me that one of the downsides of having authentication via
> TCP-AO and encryption via TCPcrypt would be that authenticated
> encryption (AEAD) could not be used.

You would not want to cross the streams and use both options AFAICT.

>> I had been planning on working that into the experimental TCP-AO NAT
>> doc, since it could be as useful as the NAT variant.
>>
>> That won't help initialize the keys, as would be needed before the SYN
>> arrives for TCP-AO. That sort of in-band keying was excluded from
>> TCP-AO to keep the SYN header size down.
>>
> Can TCP-AO possibly be used in a situation where the key is established
> after the initial message exchange, but there is no key available to
> both endpoints in the first exchange?

No; the assumption in TCP-AO is that a key exists during the initial 
exchange and AO is required. Keys can be changed later.

It would be trivial to set this up as a null key to start with if your 
goal is as you describe, though.

 > If so, is there a strong security
> requirement that militates against doing that?

Generally yes; it prevents AO from protecting you from SYN attacks.

You'd also need to change AO so that (depending on a flag set at both 
endpoints) you change the key after the SYN or not (e.g., increment the 
keyID or somesuch).

> It would be undesirable
> to have an endpoint set up a session (without authentication) then
> immediately have to tear it down (because when authentication was turned
> on, it became apparent that an active attacker had created or modified
> the messages). But perhaps if the "damage" is well contained and quickly
> discovered, it would be OK?

I don't know if this would be considered OK. I'd say it'd be easier to 
separate it into two steps, as hinted above:

1) an updated AO spec that allows a flag (on a master key, e.g.)
	that requires the keyID to be incremented after the SYN
	and that the first key can be null optionally

2) allow null keys (to enable the first part)

Null keys would expose the endpoint during the period they're used, on 
ports they're used. If the period were small (the SYN), then you could 
limit the damage AFAICT, but I'm not sure whether this would be 
considered sufficient or useful.

Joe


From david.black@emc.com  Mon Aug  1 22:25:58 2011
Return-Path: <david.black@emc.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1566821F8E7D; Mon,  1 Aug 2011 22:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.553
X-Spam-Level: 
X-Spam-Status: No, score=-104.553 tagged_above=-999 required=5 tests=[AWL=-1.942, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LI3u30pYkJC; Mon,  1 Aug 2011 22:25:56 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4384A21F8E7E; Mon,  1 Aug 2011 22:25:47 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p725PkHB007803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 01:25:47 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Aug 2011 01:25:32 -0400
Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p725PUtp022163; Tue, 2 Aug 2011 01:25:30 -0400
Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Tue, 2 Aug 2011 01:25:29 -0400
From: <david.black@emc.com>
To: <bittau@cs.stanford.edu>
Date: Tue, 2 Aug 2011 01:25:27 -0400
Thread-Topic: [saag] fyi: tcpcrypt draft
Thread-Index: AcxQedwxl66+yMjXQZiRP9KHfYWF/AAEVrDw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589513E2B@MX14A.corp.emc.com>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
In-Reply-To: <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 05:25:58 -0000

Hi Andrea,

> > tcpcrypt fundamentally does however have lower latency for connection
> > establishment compared to TLS due to fewer RTTs needed in negotiating a
> > key (we leverage the 3-way handshake and add only an extra leg),
> > especially when session caching.

There's a problem here that needs attention.  As was pointed out in the tsv=
area presentation (IIRC) of tcpcrypt, there is plenty of unpleasant deploym=
ent experience with at least middleboxes (e.g., firewalls) that discard TCP=
 packets with unexpected header contents such as a new TCP option (or even =
attempted use of the ECN bits).  Sending the SYN with a new TCP option risk=
s paying a long timeout with a site that doesn't support that new TCP optio=
n and has a middlebox that discards the SYN packet because it doesn't like =
the new option - that behavior will complicate incremental adoption.

What to do about this is a longer discussion, as some of the alternatives h=
ave downsides (e.g., starting both a tcpcyrpt and non-tcpcrypt TCP connecti=
ons consumes an additional connection slot at the responder).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778=
6
david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] On Beh=
alf Of David A. McGrew
> Sent: Monday, August 01, 2011 1:25 PM
> To: Andrea Bittau
> Cc: tcpcrypt@scs.stanford.edu; tsv-area@ietf.org; saag@ietf.org
> Subject: Re: [saag] fyi: tcpcrypt draft
>=20
> Hi Andrea,
>=20
> thanks for the detail.
>=20
> On Jul 29, 2011, at 6:45 PM, Andrea Bittau wrote:
>=20
> > On Thu, Jul 28, 2011 at 07:33:05AM -0700, David A. McGrew wrote:
> >> A lot of work has been done on using IPsec to solve these problems,
> >> and it is important to explain in detail how tcpcrypt improves on
> >> this work.  Besides the opportunistic encryption effort, there is
> >> BTNS (draft-ietf-btns-channel-binding-api-00 defines channel
> >> bindings for IPsec, for instance), RFC 3947 for running IPsec over
> >> NAT.  (Half joking: would the configuration of
> >> draft-ietf-ipsec-internet-key-00 with NAT-T solve all or most these
> >> problems?)
> >
> > tcpcrypt makes incremental deployment easier because probing is built
> > into existing packets and fallback comes at no extrea cost.   When a
> > SYN
> > packet is sent out and tcpcrypt is not supported at the other end, we
> > can fallback to regular tcpcrypt at no extra cost - just carry on
> > with a
> > vanilla TCP handshake.  How would this work with BTNS or IPSec?  Do
> > you
> > probe for IPSec (and then probe for NAT-T), wait for a timeout, and
> > then
> > send a TCP SYN?  If so, it adds network overhead (extra packets) and
> > latency (probe timeout).
>=20
> Yes, valid points.  It would be good to add this motivating text to
> the draft.
>=20
> >
> > tcpcrypt also has less protocol (space) overhead.  NAT-T requires
> > encapsulating IP in UDP, and NAT seems like a common deployment
> > scenario.  It also requires opening more ports on a firewall and
> > configuring additional services (NAT-T).
> >
> >> What TCP applications can't use TLS?   Do you mean that some apps
> >> don't use TLS in current implementations, or that there is some
> >> basic incompatibility?
> >
> > There's a bootstrap problem.  If I have SMTP on TCP/25 I have to
> > assume
> > it's clear-text (I can't send an SSL handshake packet).  Thankfully,
> > SMTP is an extensible protocol and I can send STARTTLS and then go on
> > with SSL.  If the protocol didn't permit any "options" / commands, I'd
> > be stuck to plain-text.  I'd have to allocate a new port.  That makes
> > incremental deployment harder - do I send two SYNs?
>=20
> Got it.  I would state it this way: while TLS can be used to protect
> any TCP application in principle, in practice it is not always
> available, and introducing it into an application protocol requires a
> mechanism for advertising and selecting to use TLS where it is
> available, and falling back on unprotected communications where it is
> not available.
>=20
> >
> >> What about running TCP on top of DTLS?   That would protect the TCP
> >> session, while keeping the crypto separate from the TCP stack.
> >
> > Same answer as per BTNS and NAT-T - we can efficiently incrementally
> > deploy and have less protocol overhead.
> >
> >> 1.  How easy to configure will tcpcrypt be once it supports mutual
> >> authentication, the enforcement of configurable security policies,
> >> and crypto algorithm agility (e.g. ECDH and ECDSA)?
> >
> > Authentication is left to the application, so tcpcrypt will support
> > authentication only if the application supports it.  If the
> > application
> > supports it, then a mechanism is already in place, e.g., htpasswd in
> > Apache for passwords.  So in the case of Apache, it'll include
> > tcpcrypt's session id when doing http digest authentication, for
> > example.
> >
> > We're also working on an authentication library that attempts to
> > authenticate tcpcrypt using DNSSEC+DANE that can be used by all apps
> > if
> > DANE is deployed.  The configuration will require storing a
> > certificate
> > fingerprint in DNS.
> >
> > We expect that most applications (e.g., the ones running clear-text
> > today) won't care about the crypto algorithms used in tcpcrypt's
> > handshake.  So the security policy will be set system-wide (e.g.,
> > allow
> > only RSA, SHA1 or whatever).  For security concious applications it'll
> > be a setsockopt and presumably those applications already have a
> > configuration file for whatever the already use today for crypto.
> >
> >> 2.  The comparison of tcpcrypt to TLS is only considering the RSA
> >> ciphersuites in the latter protocol.  The efficiency and security
> >> properties of other ciphersuites are quite different.
> >
> > Yes, but we expect tcpcrypt to be no worse (or better) than TLS.
>=20
> Agreed; but note that this is a far different statement than "36 x
> better performance", which if I recall right was stated in the
> presentation at IETF81.  It is important to provide a detailed
> comparison, especially to the non-crypto audience who might miss the
> full implications.
>=20
>=20
> > tcpcrypt fundamentally does however have lower latency for conncection
> > establishment compared to TLS due to fewer RTTs needed in
> > negotiating a
> > key (we leverage the 3-way handshake and add only an extra leg),
> > especially when session caching.
> >
> >> 3.  Reversing the client and server public/private key operations in
> >> tcpcrypt, which is used to make the protocol more scalable, is
> >> applicable only to the RSA algorithm.   In particular, the situation
> >> with elliptic curve cryptography is quite different.  This raises
> >> some questions: how does tcpcrypt with RSA compare to an ECDH/ECDSA
> >> TLS ciphersuite, say, at security levels of 128, 192, or 256 bits?
> >> How does tcpcrypt perform with other algorithms?   Given the
> >> interest in ECC as a future direction for cryptography, these
> >> questions deserve some thought.
> >
> > Yes, we'll implement those but we do not expect tcpcrypt's performance
> > to be much different from a TLS implementation - we both do the same
> > thing (e.g., ECDH).
>=20
> What will be especially interesting is to see how the reversal of RSA
> private/public key operations compares to ECC as a function of
> security level.
>=20
> >
> >> What you are describing here is true for the RSA ciphersuites in
> >> SSL, but is not true for the Diffie-Hellman ciphersuites, or the
> >> ECDH ones (see Section 7.4.2 of RFC 5246 for instance).
> >
> > tcpcrypyt's main goal is to be deployed ubiquitously.  Improved
> > performance in one case is only a bonus.  It has a bunch of other
> > advantages (single integrated mechanism, incrementally deployable)
> > apart
> > from RSA performance.
> >
> >> Why is graceful fallback easier at the TCP layer than at another
> >> layer?   And if there is some mechanism within TCP that facilitates
> >> fallback, would it be possible to use that mechanism in conjunction
> >> with a cryptographic protocol external to TCP?  That last option
> >> would minimize the impact to TCP implementations, meaning less new
> >> code inside kernels, and fewer states, and so on.
> >
> > Gracefully, and efficient, I should add.  The problem is detecting
> > whether the other end supports crypto mechanism X.  At a below-
> > transport
> > layer, we'd have to send our IP packet, wait for a timeout, and then
> > send a SYN.  At a transport layer we're sending out a SYN so we can
> > easily piggyback options (perfect!).  At an application layer what's
> > the
> > first thing we send?  STARTTLS?  Does the application-layer protocol
> > allow such new commands or will it drop the command?
> >
> > The minimum TCP mechanism needed for a graceful and efficient fallback
> > is a TCP option in the SYN.  So, tcpcrypt-lite would modify a kernel
> > with a setsockopt(CRYPTO_OPTION) to include the CRYPTO option in a SYN
> > and getsockopt(CRYPTO_OPTION) to see if the CRYPTO option was echoed
> > in
> > the SYN-ACK.  At that point SSL_accept() can be called.
>=20
> This sounds like an option worth pursuing, no pun intended.  You make
> good points about why TCP is a good place to do the capability
> discovery and fallback for crypto.   Why not define a TCP option that
> can enable devices to discover TLS or tcpcrypt or other higher-layer
> crypto protocols?   That option would be much easier to implement and
> standardize, and it could tie into a full tcpcrypt protocol that
> resides in a shim above the TCP layer.  The separation will create
> useful implementation alternatives, and will isolate the TCP state
> machine from changes.
>=20
> For concreteness, I'm thinking of a TCP option that looks like this:
>=20
>                 +---------+---------+-------------------+
>                 |  Kind   |Length=3D2 |     SECCAP        |
>                 +---------+---------+-------------------+
>=20
> The Security Capabilities (SECCAP) field contains an unsigned integer
> that indicates
> the cryptographic security protocol, if any, the endpoint can use to
> protect subsequent
> communications.
>=20
>    SECCAP Value     Meaning
>=20
>          0          Reserved for future use
>          1          No security protocol is available
>          2          TCPcrypt
>          3          TLS
>          ...        ...
>=20
>=20
>=20
> >  But we lose all
> > TCP header MACing - e.g., someone can RST our connection.  TCP AO
> > suggests that MACing TCP headers is important so crypto protocols
> > should
> > do that (hence why we live in the transport layer).
>=20
> True, but why not design tcpcrypt so that it make use of TCP-AO?
> That seems like an approach that would work with the separation
> outlined above.
>=20
> > Also, we can
> > leverage the existing 3-way handshake to get a head start on crypto
> > negotiations.  Sesison caching completes within the three way
> > handshake.
> >
> >> If the RSA keypair is generated using a pseudorandom process (and
> >> there are standards for doing that), the min entropy could be lower.
> >>
> >> But if it is adequate to have the entropy show up in the nonces, the
> >> min-entropy of the key would be a moot point.
> >
> > The pseudo-random generator has to have enough state to generate prime
> > numbers with min entropy 256.  Depending on the prime number
> > generator,
> > this might, for instance, require something on the order of 256 + ceil
> > (log_2 (log_e (2 ^ 1024))) or 266 bits.  We assume most RSA
> > implementations would have more random state than that.
>=20
> Unfortunately that is not always a safe assumption.  There are
> standards for RSA key generation (see for instance NIST SP 800 56-B
> Section 6.3.1) in which n bits of random data are used to seed a
> pseudorandom process that selects the primes used as the private key;
> for 1024-bit RSA, n will be about 80.
>=20
> I am confident that tcpcrypt can be made to work around this fact, but
> it may be an important detail (in the security proof if not in
> practice).
>=20
> David
>=20
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
>=20


From stefw@collabora.co.uk  Tue Aug  2 00:48:49 2011
Return-Path: <stefw@collabora.co.uk>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9415721F8C98 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 00:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INbwtVdm9P9V for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 00:48:49 -0700 (PDT)
Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 77E1F21F8DD6 for <saag@ietf.org>; Tue,  2 Aug 2011 00:48:47 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: stefw) with ESMTPSA id 52FBB6019FB
Message-ID: <4E37ABE3.8090802@collabora.co.uk>
Date: Tue, 02 Aug 2011 09:48:51 +0200
From: Stef Walter <stefw@collabora.co.uk>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11
MIME-Version: 1.0
To: Jan Pechanec <Jan.Pechanec@Sun.COM>,  Darren J Moffat <Darren.Moffat@Sun.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: saag@ietf.org
Subject: [saag] Rename PKCS#11 URI 'pinfile' argument to 'pin'?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 07:48:49 -0000

Hi Jan, everyone,

I've been implementing the PKCS#11 URI scheme a lot recently, and have
gotten quite intimate with it. Thanks for the work on the spec. I've
developed an implementation (which could be used as a reference
implementation):

http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-URIs.html

There's one more change I'd like to suggest: Change attribute 'pinfile'
to 'pin'.

The 'pinfile' argument, is loosely defined. It allows applications to
overload that attribute. Because of this loose definition the name
'pinfile' isn't always appropriate. I think that 'pin' would cover it
much better, and not cause confusions for people new to PKCS#11 URIs.

BTW, we've designed an API around the pinfile argument which allows
libraries and apps in the same process to coordinate use of the PIN
retrieval via the URI pinfile argument.

http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-PIN-Callbacks.html

Cheers,

Stef

From klaas@cisco.com  Tue Aug  2 01:17:07 2011
Return-Path: <klaas@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0121F8F00 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 01:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Gk8rUi4ozN for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 01:17:05 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47E21F8ECE for <saag@ietf.org>; Tue,  2 Aug 2011 01:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1788; q=dns/txt; s=iport; t=1312273034; x=1313482634; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=MGqnh0mtKj/TGA/9uDYMDlCkGzPTUj8PhnAdUo/Z1YI=; b=bWtzuATx9YS5ILr2HrFH4meZxq00NnB7pb8UPBnqlC7T1PxKTlixEDJv DHz6lJdag9i5deVML6QnDRGozc2+pAsYLGYJVbthbAaGZ4v6fZ3y2fFaa wJk1rDoF7TUxuE/dhcyuQRCVxgfaF02cRPH3ZJQF74UJaKLVYwRqRqqup 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlEHADuxN06Q/khN/2dsb2JhbABCmFCPD3eBWQFlLg8WGAMCAQIBNyEIAQEFGYdOoHGBIwGfBIZCBJJ7kGY
X-IronPort-AV: E=Sophos;i="4.67,305,1309737600"; d="scan'208";a="46035728"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2011 08:14:48 +0000
Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p728Emiv025891 for <saag@ietf.org>; Tue, 2 Aug 2011 08:14:48 GMT
Message-ID: <4E37B1F7.9070405@cisco.com>
Date: Tue, 02 Aug 2011 10:14:47 +0200
From: Klaas Wierenga <klaas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: saag@ietf.org
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [saag] abfab meeting summary for IETF81
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 08:17:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Abfab met in the morning session on Friday 29th of July

The progress of the WG documents was discussed (progressing well) as
well as 3 proposals for new work:

- -  gss-eap as Kerberos pre-authentication
(draft-perez-abfab-eap-gss-preauth)

This work proposes to use gss-eap as Kerberos pre-authentication in
order to use Kerberos in a federated environment. It is as of yet
unclear in what WG (Kerberos, Kitten or Abfab) this work fits best, but
this approach solves a number of real world problems and as such is
worth pursuing.

- - federated cross layer access (draft-wei-abfab-fcla)

This draft proposes to use the authentication mechanisms of mobile
operators (GBA) in combination with Abfab to authenticate to application
son the Internet. The draft is very sketchy at the moment, and the
author was urged to provide more detail.

- - multihop federations (draft-mrw-abfab-multihop-fed)

This draft explains an architecture that allows for the establishment of
technical trust between AAA-servers by using so-called trust routers,
entities that act as introducers to other trust routers or AAA-servers
and that learn the paths to them.

All three of these drafts are currently not being taken on as WG docs,
but may so after the work on WG documents has sufficiently progressed.

Detailed minutes can be found at:

http://www.ietf.org/proceedings/81/minutes/abfab.txt

Klaas Wierenga & Leif Johansson (co-chairs abfab)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk43sfUACgkQH2Wy/p4XeFIovgCdFB/F8+Kf1P52zMzDFkjdKOaR
1aEAnjsSEC+yozbrC0WQhXaNDtbVPq5u
=O3Ns
-----END PGP SIGNATURE-----

From stefw@collabora.co.uk  Tue Aug  2 04:32:22 2011
Return-Path: <stefw@collabora.co.uk>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07B721F8ED5 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 04:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keIfIImlIlC3 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 04:32:21 -0700 (PDT)
Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 86B0E21F8B54 for <saag@ietf.org>; Tue,  2 Aug 2011 04:32:21 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: stefw) with ESMTPSA id C8A1460226E
Message-ID: <4E37E046.7000403@collabora.co.uk>
Date: Tue, 02 Aug 2011 13:32:22 +0200
From: Stef Walter <stefw@collabora.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0
MIME-Version: 1.0
To: Darren J Moffat <Darren.Moffat@Oracle.COM>
References: <4E37ABE3.8090802@collabora.co.uk> <4E37CA8B.9050602@Oracle.COM>
In-Reply-To: <4E37CA8B.9050602@Oracle.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Jan Pechanec <Jan.Pechanec@sun.com>, saag@ietf.org
Subject: Re: [saag] Rename PKCS#11 URI 'pinfile' argument to 'pin'?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 11:32:22 -0000

On 08/02/2011 11:59 AM, Darren J Moffat wrote:
> On 08/02/11 08:48, Stef Walter wrote:
>> I've been implementing the PKCS#11 URI scheme a lot recently, and have
>> gotten quite intimate with it. Thanks for the work on the spec. I've
>> developed an implementation (which could be used as a reference
>> implementation):
>>
>> http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-URIs.html
>>
>> There's one more change I'd like to suggest: Change attribute 'pinfile'
>> to 'pin'.
>
> The reason we didn't use 'pin' is because we never wanted the actual
> value of the PKCS#11 PIN as passed to C_Login() to appear in the URI.

Ah yes, good point.

> I agree that 'pinfile' isn't as flexible a name as it could be given
> what kind of thing applications could choose to do with it.

Would 'pinsrc' or 'pin-source' be a good option?

Cheers,

Stef

From jhutz@cmu.edu  Mon Aug  1 10:14:46 2011
Return-Path: <jhutz@cmu.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5907511E80AB for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 10:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.149
X-Spam-Level: 
X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz04mHQVUwc4 for <saag@ietfa.amsl.com>; Mon,  1 Aug 2011 10:14:45 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id BEFDA11E8077 for <saag@ietf.org>; Mon,  1 Aug 2011 10:14:45 -0700 (PDT)
Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p71HEiVb013097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2011 13:14:45 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <ondrej.sury@nic.cz>
In-Reply-To: <31458_1312073702_p6V0t09e032175_E490261C-BD56-436F-919D-69E27DCD6BFD@nic.cz>
References: <0F1A09E5-42E0-4B66-A317-155BB94BC5C2@nic.cz> <alpine.BSO.2.00.1107310416340.20872@natsu.mindrot.org> <31458_1312073702_p6V0t09e032175_E490261C-BD56-436F-919D-69E27DCD6BFD@nic.cz>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 01 Aug 2011 13:14:52 -0400
Message-ID: <1312218892.16851.25.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
X-Mailman-Approved-At: Tue, 02 Aug 2011 08:01:15 -0700
Cc: Damien Miller <djm@mindrot.org>, ietf-ssh <ietf-ssh@NetBSD.org>, jakob@openbsd.org
Subject: Re: [saag] Support for ECDSA and SHA-2 (SHA-256) in the SSHFP record
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 17:14:46 -0000

On Sat, 2011-07-30 at 20:54 -0400, Ondřej Surý wrote:
> Hi Damien,
> 
> On 30. 7. 2011, at 14:21, Damien Miller wrote:
> 
> > Thanks for starting work on this - SSHFP records for ECDSA keys were on
> > my TODO list, but I haven't yet got around to them.
> 
> > I briefly skimmed your draft - one question I have is whether it is
> > better to roll up all the ECDSA key types under one SSHFP RR type.
> > It would be quite ugly to have to allocate SSHFP RR type numbers for
> > each possible ECDSA curve type, but using a single one might make
> > exploitation of SHA256 preimage attacks easier.

Before we go any further, it's probably best to make it clear in advance
that we are _not_ talking about RR types at all.  SSHFP is and continues
to be a single RR type.  What we are talking about is values for the
"algorithm" field in the SSHFP RR data.

It's a bit late now, but if we'd made the algorithm field a string
containing the SSH public key algorithm name, we wouldn't be having this
discussion now. :-(


> I thought that secsh was concluded, but it seems that the mailing list
>  is still up.  Ccing there as well.

The WG did conclude, but this list is still active and is the
appropriate forum for discussing changes or enhancements to SSH or
related protocols.  I'm CC'ing this there, and moving saag to bcc only
so that people there see my first comment above.


-- Jeff


From david.a.mcgrew@mindspring.com  Mon Aug  1 10:25:27 2011
Return-Path: <david.a.mcgrew@mindspring.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AFE21F8B86; Mon,  1 Aug 2011 10:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.989
X-Spam-Level: *
X-Spam-Status: No, score=1.989 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_64=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvUBOL-Psra4; Mon,  1 Aug 2011 10:25:26 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id B1B0221F8B44; Mon,  1 Aug 2011 10:25:26 -0700 (PDT)
Received: from [69.251.37.177] (helo=stealth-10-32-254-211.cisco.com) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <david.a.mcgrew@mindspring.com>) id 1QnwEs-0005jI-OP; Mon, 01 Aug 2011 13:25:14 -0400
Message-Id: <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com>
From: "David A. McGrew" <david.a.mcgrew@mindspring.com>
To: Andrea Bittau <bittau@cs.stanford.edu>
In-Reply-To: <20110730014544.GM3751@shorty>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 1 Aug 2011 10:25:14 -0700
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty>
X-Mailer: Apple Mail (2.936)
X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac4507c408d7d3d2e9aa2d4f5548039267e14d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 69.251.37.177
X-Mailman-Approved-At: Tue, 02 Aug 2011 08:01:15 -0700
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Aug 2011 17:25:28 -0000

Hi Andrea,

thanks for the detail.

On Jul 29, 2011, at 6:45 PM, Andrea Bittau wrote:

> On Thu, Jul 28, 2011 at 07:33:05AM -0700, David A. McGrew wrote:
>> A lot of work has been done on using IPsec to solve these problems,
>> and it is important to explain in detail how tcpcrypt improves on
>> this work.  Besides the opportunistic encryption effort, there is
>> BTNS (draft-ietf-btns-channel-binding-api-00 defines channel
>> bindings for IPsec, for instance), RFC 3947 for running IPsec over
>> NAT.  (Half joking: would the configuration of
>> draft-ietf-ipsec-internet-key-00 with NAT-T solve all or most these
>> problems?)
>
> tcpcrypt makes incremental deployment easier because probing is built
> into existing packets and fallback comes at no extrea cost.   When a  
> SYN
> packet is sent out and tcpcrypt is not supported at the other end, we
> can fallback to regular tcpcrypt at no extra cost - just carry on  
> with a
> vanilla TCP handshake.  How would this work with BTNS or IPSec?  Do  
> you
> probe for IPSec (and then probe for NAT-T), wait for a timeout, and  
> then
> send a TCP SYN?  If so, it adds network overhead (extra packets) and
> latency (probe timeout).

Yes, valid points.  It would be good to add this motivating text to  
the draft.

>
> tcpcrypt also has less protocol (space) overhead.  NAT-T requires
> encapsulating IP in UDP, and NAT seems like a common deployment
> scenario.  It also requires opening more ports on a firewall and
> configuring additional services (NAT-T).
>
>> What TCP applications can't use TLS?   Do you mean that some apps
>> don't use TLS in current implementations, or that there is some
>> basic incompatibility?
>
> There's a bootstrap problem.  If I have SMTP on TCP/25 I have to  
> assume
> it's clear-text (I can't send an SSL handshake packet).  Thankfully,
> SMTP is an extensible protocol and I can send STARTTLS and then go on
> with SSL.  If the protocol didn't permit any "options" / commands, I'd
> be stuck to plain-text.  I'd have to allocate a new port.  That makes
> incremental deployment harder - do I send two SYNs?

Got it.  I would state it this way: while TLS can be used to protect  
any TCP application in principle, in practice it is not always  
available, and introducing it into an application protocol requires a  
mechanism for advertising and selecting to use TLS where it is  
available, and falling back on unprotected communications where it is  
not available.

>
>> What about running TCP on top of DTLS?   That would protect the TCP
>> session, while keeping the crypto separate from the TCP stack.
>
> Same answer as per BTNS and NAT-T - we can efficiently incrementally
> deploy and have less protocol overhead.
>
>> 1.  How easy to configure will tcpcrypt be once it supports mutual
>> authentication, the enforcement of configurable security policies,
>> and crypto algorithm agility (e.g. ECDH and ECDSA)?
>
> Authentication is left to the application, so tcpcrypt will support
> authentication only if the application supports it.  If the  
> application
> supports it, then a mechanism is already in place, e.g., htpasswd in
> Apache for passwords.  So in the case of Apache, it'll include
> tcpcrypt's session id when doing http digest authentication, for
> example.
>
> We're also working on an authentication library that attempts to
> authenticate tcpcrypt using DNSSEC+DANE that can be used by all apps  
> if
> DANE is deployed.  The configuration will require storing a  
> certificate
> fingerprint in DNS.
>
> We expect that most applications (e.g., the ones running clear-text
> today) won't care about the crypto algorithms used in tcpcrypt's
> handshake.  So the security policy will be set system-wide (e.g.,  
> allow
> only RSA, SHA1 or whatever).  For security concious applications it'll
> be a setsockopt and presumably those applications already have a
> configuration file for whatever the already use today for crypto.
>
>> 2.  The comparison of tcpcrypt to TLS is only considering the RSA
>> ciphersuites in the latter protocol.  The efficiency and security
>> properties of other ciphersuites are quite different.
>
> Yes, but we expect tcpcrypt to be no worse (or better) than TLS.

Agreed; but note that this is a far different statement than "36 x  
better performance", which if I recall right was stated in the  
presentation at IETF81.  It is important to provide a detailed  
comparison, especially to the non-crypto audience who might miss the  
full implications.


> tcpcrypt fundamentally does however have lower latency for conncection
> establishment compared to TLS due to fewer RTTs needed in  
> negotiating a
> key (we leverage the 3-way handshake and add only an extra leg),
> especially when session caching.
>
>> 3.  Reversing the client and server public/private key operations in
>> tcpcrypt, which is used to make the protocol more scalable, is
>> applicable only to the RSA algorithm.   In particular, the situation
>> with elliptic curve cryptography is quite different.  This raises
>> some questions: how does tcpcrypt with RSA compare to an ECDH/ECDSA
>> TLS ciphersuite, say, at security levels of 128, 192, or 256 bits?
>> How does tcpcrypt perform with other algorithms?   Given the
>> interest in ECC as a future direction for cryptography, these
>> questions deserve some thought.
>
> Yes, we'll implement those but we do not expect tcpcrypt's performance
> to be much different from a TLS implementation - we both do the same
> thing (e.g., ECDH).

What will be especially interesting is to see how the reversal of RSA  
private/public key operations compares to ECC as a function of  
security level.

>
>> What you are describing here is true for the RSA ciphersuites in
>> SSL, but is not true for the Diffie-Hellman ciphersuites, or the
>> ECDH ones (see Section 7.4.2 of RFC 5246 for instance).
>
> tcpcrypyt's main goal is to be deployed ubiquitously.  Improved
> performance in one case is only a bonus.  It has a bunch of other
> advantages (single integrated mechanism, incrementally deployable)  
> apart
> from RSA performance.
>
>> Why is graceful fallback easier at the TCP layer than at another
>> layer?   And if there is some mechanism within TCP that facilitates
>> fallback, would it be possible to use that mechanism in conjunction
>> with a cryptographic protocol external to TCP?  That last option
>> would minimize the impact to TCP implementations, meaning less new
>> code inside kernels, and fewer states, and so on.
>
> Gracefully, and efficient, I should add.  The problem is detecting
> whether the other end supports crypto mechanism X.  At a below- 
> transport
> layer, we'd have to send our IP packet, wait for a timeout, and then
> send a SYN.  At a transport layer we're sending out a SYN so we can
> easily piggyback options (perfect!).  At an application layer what's  
> the
> first thing we send?  STARTTLS?  Does the application-layer protocol
> allow such new commands or will it drop the command?
>
> The minimum TCP mechanism needed for a graceful and efficient fallback
> is a TCP option in the SYN.  So, tcpcrypt-lite would modify a kernel
> with a setsockopt(CRYPTO_OPTION) to include the CRYPTO option in a SYN
> and getsockopt(CRYPTO_OPTION) to see if the CRYPTO option was echoed  
> in
> the SYN-ACK.  At that point SSL_accept() can be called.

This sounds like an option worth pursuing, no pun intended.  You make  
good points about why TCP is a good place to do the capability  
discovery and fallback for crypto.   Why not define a TCP option that  
can enable devices to discover TLS or tcpcrypt or other higher-layer  
crypto protocols?   That option would be much easier to implement and  
standardize, and it could tie into a full tcpcrypt protocol that  
resides in a shim above the TCP layer.  The separation will create  
useful implementation alternatives, and will isolate the TCP state  
machine from changes.

For concreteness, I'm thinking of a TCP option that looks like this:

                +---------+---------+-------------------+
                |  Kind   |Length=2 |     SECCAP        |
                +---------+---------+-------------------+

The Security Capabilities (SECCAP) field contains an unsigned integer  
that indicates
the cryptographic security protocol, if any, the endpoint can use to  
protect subsequent
communications.

   SECCAP Value     Meaning

         0          Reserved for future use
         1          No security protocol is available
         2          TCPcrypt
         3          TLS
         ...        ...



>  But we lose all
> TCP header MACing - e.g., someone can RST our connection.  TCP AO
> suggests that MACing TCP headers is important so crypto protocols  
> should
> do that (hence why we live in the transport layer).

True, but why not design tcpcrypt so that it make use of TCP-AO?    
That seems like an approach that would work with the separation  
outlined above.

> Also, we can
> leverage the existing 3-way handshake to get a head start on crypto
> negotiations.  Sesison caching completes within the three way  
> handshake.
>
>> If the RSA keypair is generated using a pseudorandom process (and
>> there are standards for doing that), the min entropy could be lower.
>>
>> But if it is adequate to have the entropy show up in the nonces, the
>> min-entropy of the key would be a moot point.
>
> The pseudo-random generator has to have enough state to generate prime
> numbers with min entropy 256.  Depending on the prime number  
> generator,
> this might, for instance, require something on the order of 256 + ceil
> (log_2 (log_e (2 ^ 1024))) or 266 bits.  We assume most RSA
> implementations would have more random state than that.

Unfortunately that is not always a safe assumption.  There are  
standards for RSA key generation (see for instance NIST SP 800 56-B  
Section 6.3.1) in which n bits of random data are used to seed a  
pseudorandom process that selects the primes used as the private key;  
for 1024-bit RSA, n will be about 80.

I am confident that tcpcrypt can be made to work around this fact, but  
it may be an important detail (in the security proof if not in  
practice).

David

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


From david.a.mcgrew@mindspring.com  Mon Aug  1 17:37:43 2011
Return-Path: <david.a.mcgrew@mindspring.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC7A21F8C0A; Mon,  1 Aug 2011 17:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.305
X-Spam-Level: 
X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=2.294,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2VJlDjHyt-X; Mon,  1 Aug 2011 17:37:39 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02F1F0C3D; Mon,  1 Aug 2011 17:37:36 -0700 (PDT)
Received: from [69.251.37.177] (helo=stealth-10-32-254-211.cisco.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <david.a.mcgrew@mindspring.com>) id 1Qo2zP-0001XQ-Fh; Mon, 01 Aug 2011 20:37:43 -0400
Message-Id: <45875A47-E146-40F9-9B90-96AD015BBC85@mindspring.com>
From: "David A. McGrew" <david.a.mcgrew@mindspring.com>
To: Joe Touch <touch@isi.edu>
In-Reply-To: <4E370A5E.1050608@isi.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 1 Aug 2011 17:37:42 -0700
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <4E370A5E.1050608@isi.edu>
X-Mailer: Apple Mail (2.936)
X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac4507044e77353aa95c2453044fb2346e3d6d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 69.251.37.177
X-Mailman-Approved-At: Tue, 02 Aug 2011 08:01:15 -0700
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 00:37:44 -0000

On Aug 1, 2011, at 1:19 PM, Joe Touch wrote:

>
>
> On 8/1/2011 10:25 AM, David A. McGrew wrote:
> ...
>>> But we lose all
>>> TCP header MACing - e.g., someone can RST our connection. TCP AO
>>> suggests that MACing TCP headers is important so crypto protocols  
>>> should
>>> do that (hence why we live in the transport layer).
>>
>> True, but why not design tcpcrypt so that it make use of TCP-AO? That
>> seems like an approach that would work with the separation outlined  
>> above.
>
> TCP-AO could easily support a mode where the TCP body was encrypted,  
> e.g., where the encryption algorithm were defined to use the  
> connection context (TCP header, IP pseudoheader) as context.

It occurs to me that one of the downsides of having authentication via  
TCP-AO and encryption via TCPcrypt would be that authenticated  
encryption (AEAD) could not be used.

>
> I had been planning on working that into the experimental TCP-AO NAT  
> doc, since it could be as useful as the NAT variant.
>
> That won't help initialize the keys, as would be needed before the  
> SYN arrives for TCP-AO. That sort of in-band keying was excluded  
> from TCP-AO to keep the SYN header size down.
>

Can TCP-AO possibly be used in a situation where the key is  
established after the initial message exchange, but there is no key  
available to both endpoints in the first exchange?   If so, is there a  
strong security requirement that militates against doing that?   It  
would be undesirable to have an endpoint set up a session (without  
authentication) then immediately have to tear it down (because when  
authentication was turned on, it became apparent that an active  
attacker had created or modified the messages).   But perhaps if the  
"damage" is well contained and quickly discovered, it would be OK?

David

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


From Darren.Moffat@Oracle.COM  Tue Aug  2 02:59:48 2011
Return-Path: <Darren.Moffat@Oracle.COM>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA9C21F8EEA for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 02:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuzEjfwyjX0m for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 02:59:47 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2A21F8EE9 for <saag@ietf.org>; Tue,  2 Aug 2011 02:59:47 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p729xmS8009328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 09:59:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p729xlpd012093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 09:59:47 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p729xfQx009286; Tue, 2 Aug 2011 04:59:41 -0500
Received: from [10.163.198.80] (/10.163.198.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 02:59:41 -0700
Message-ID: <4E37CA8B.9050602@Oracle.COM>
Date: Tue, 02 Aug 2011 10:59:39 +0100
From: Darren J Moffat <Darren.Moffat@Oracle.COM>
Organization: Oracle Solaris Security
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.17) Gecko/20110618 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.3pre1-Champion ObetStats/1287679796818-161309156 Thunderbird/3.1.10
MIME-Version: 1.0
To: Stef Walter <stefw@collabora.co.uk>
References: <4E37ABE3.8090802@collabora.co.uk>
In-Reply-To: <4E37ABE3.8090802@collabora.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090205.4E37CA97.008A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Tue, 02 Aug 2011 08:01:15 -0700
Cc: Jan Pechanec <Jan.Pechanec@sun.com>, saag@ietf.org, Darren J Moffat <Darren.Moffat@sun.com>
Subject: Re: [saag] Rename PKCS#11 URI 'pinfile' argument to 'pin'?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 09:59:48 -0000

On 08/02/11 08:48, Stef Walter wrote:
> I've been implementing the PKCS#11 URI scheme a lot recently, and have
> gotten quite intimate with it. Thanks for the work on the spec. I've
> developed an implementation (which could be used as a reference
> implementation):
>
> http://p11-glue.freedesktop.org/doc/p11-kit/p11-kit-URIs.html
>
> There's one more change I'd like to suggest: Change attribute 'pinfile'
> to 'pin'.

The reason we didn't use 'pin' is because we never wanted the actual 
value of the PKCS#11 PIN as passed to C_Login() to appear in the URI.

I agree that 'pinfile' isn't as flexible a name as it could be given 
what kind of thing applications could choose to do with it.

I really won't want it to be called 'pin' but I'm open to names other 
than 'pinfile' some possibilities include: getpin,pincallback,pininput 
and I'm happy to see other suggestions too.

-- 
Darren J Moffat

From bittau@gmail.com  Tue Aug  2 14:20:03 2011
Return-Path: <bittau@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DF311E80A9; Tue,  2 Aug 2011 14:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.092
X-Spam-Level: 
X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.507,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIExaV82IBGS; Tue,  2 Aug 2011 14:20:02 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0511E808F; Tue,  2 Aug 2011 14:19:27 -0700 (PDT)
Received: by yie30 with SMTP id 30so140597yie.31 for <multiple recipients>; Tue, 02 Aug 2011 14:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-echelon:user-agent; bh=LDUlszumrTIK5f+7RhdnXO39eiABbYTD6rnGpsLLpZ4=; b=PmRR7HLYVqEl52FTVYcZcdK3ydfEVSpq0UU4H2NMR6vBFybzDW085mOx+QXnoGzjtM octgPn0fOKgMYjYsepbXNGbS9PckSkMbkSxp8ovRET1NgNpeqWw/ZFFvfNBz6X36oq+D 24VlrcmXPZ6UTcWBf0pO/73gG3tEmpDVSPGtY=
Received: by 10.68.31.1 with SMTP id w1mr11221021pbh.421.1312319976916; Tue, 02 Aug 2011 14:19:36 -0700 (PDT)
Received: from tapir.cs.ucl.ac.uk (sorbox.scs.stanford.edu [171.66.3.197]) by mx.google.com with ESMTPS id k3sm222187pbj.45.2011.08.02.14.19.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 14:19:34 -0700 (PDT)
Sender: Andrea Bittau <bittau@gmail.com>
Received: by tapir.cs.ucl.ac.uk (Postfix, from userid 0) id 181524810171; Tue,  2 Aug 2011 14:17:54 -0700 (PDT)
Date: Tue, 2 Aug 2011 14:17:54 -0700
From: Andrea Bittau <bittau@cs.stanford.edu>
To: david.black@emc.com
Message-ID: <20110802211753.GI3814@shorty>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589513E2B@MX14A.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589513E2B@MX14A.corp.emc.com>
X-Echelon: Bush Bomb War KGB
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 21:20:03 -0000

On Tue, Aug 02, 2011 at 01:25:27AM -0400, david.black@emc.com wrote:
> There's a problem here that needs attention.  As was pointed out in the tsvarea presentation (IIRC) of tcpcrypt, there is plenty of unpleasant deployment experience with at least middleboxes (e.g., firewalls) that discard TCP packets with unexpected header contents such as a new TCP option (or even attempted use of the ECN bits).  Sending the SYN with a new TCP option risks paying a long timeout with a site that doesn't support that new TCP option and has a middlebox that discards the SYN packet because it doesn't like the new option - that behavior will complicate incremental adoption.
> 
> What to do about this is a longer discussion, as some of the alternatives have downsides (e.g., starting both a tcpcyrpt and non-tcpcrypt TCP connections consumes an additional connection slot at the responder).

Yes, that's the crux of the argument - will a new TCP option cause
packets to be dropped?  In fact, that's the only compelling argument for
why an application layer approach might be better than a TCP one, though
we still think the arguments for TCP outweigh those for the application
layer.

We're working on measuring (the best we can) how much middleboxes drop
packets with unknown options to see whether it's a show stopper.
Hopefully the common case will be that middleboxes strip options rather
than dropping packets.  In fact, if you have pointers to case studies on
middlebox behavior we'd love to have those.

As you say the solution is not straightforward.  For example, a very
conservative approach could be to disable tcpcrypt if the sender is
unable to connect using tcpcrypt to (say) three sites.  That way the
penatly of sending a vanilla TCP syn and a tcpcrypt SYN to "path probe"
is paid only three times.  tcpcrypt can be turned back on when the
sender's IP changes.  This may work out pretty well if our test results
show that middleboxes are most often found closer to the client-side
(e.g., NATs) rather than the server side.

My understanding of most of ECN's problems is that the bits were
previosuly reserved and then overloaded.  TCP options (in principle) are
a by-the-spec way of extending TCP, so hopefully we'll suffer less
problems compared to ECN. 

From bittau@gmail.com  Tue Aug  2 14:32:34 2011
Return-Path: <bittau@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2DB11E80A9; Tue,  2 Aug 2011 14:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.165
X-Spam-Level: 
X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLxHltag1wfg; Tue,  2 Aug 2011 14:32:34 -0700 (PDT)
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 18D4411E808F; Tue,  2 Aug 2011 14:32:34 -0700 (PDT)
Received: by pzk6 with SMTP id 6so281580pzk.26 for <multiple recipients>; Tue, 02 Aug 2011 14:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-echelon:user-agent; bh=SZKBd8x9gTlFFgBu1r8dofaT2HwXSebZnuuGSI1/QYM=; b=fgX06X3COTwUj3qHmvsMio10g65Sezbky48UU7Ttmsxs7DngmYrqQASnRaKC9alFDD Ra+RKH/gUDV+a3NQeyD59uaOeLHRdjTdBop0PiQiWrs2n76MzknduzkVGs6DzI3OHoW9 ZSijrcu4grBd++06P8fZjCvcGXqPrF45yvrjI=
Received: by 10.68.13.38 with SMTP id e6mr6239984pbc.72.1312320764132; Tue, 02 Aug 2011 14:32:44 -0700 (PDT)
Received: from tapir.cs.ucl.ac.uk (sorbox.scs.stanford.edu [171.66.3.197]) by mx.google.com with ESMTPS id l7sm233186pbh.42.2011.08.02.14.32.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 14:32:42 -0700 (PDT)
Sender: Andrea Bittau <bittau@gmail.com>
Received: by tapir.cs.ucl.ac.uk (Postfix, from userid 0) id A282F4810171; Tue,  2 Aug 2011 14:31:01 -0700 (PDT)
Date: Tue, 2 Aug 2011 14:31:01 -0700
From: Andrea Bittau <bittau@cs.stanford.edu>
To: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
Message-ID: <20110802213101.GJ3814@shorty>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <20110801191407.GA3765@shorty> <133D9897FB9C5E4E9DF2779DC91E947C0654BD89@SLFSNX.rcs.alcatel-research.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0654BD89@SLFSNX.rcs.alcatel-research.de>
X-Echelon: Bush Bomb War KGB
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, "David A. McGrew" <david.a.mcgrew@mindspring.com>, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 21:32:34 -0000

On Tue, Aug 02, 2011 at 05:40:18PM +0200, SCHARF, Michael wrote:
> For whatever it is worth, the question of TCP extension vs. shim layer
> seems to be somehow related to some discussions in the MPTCP WG last
> year. In a different context, an expired ID
> (http://tools.ietf.org/html/draft-scharf-mptcp-mctcp-01) discusses some
> pros and cons of transport layer vs. shim layer+discovery by SYN
> options. Not all of them are about implementation, and IMHO both
> alternatives have disadvantages. Section 5.4 of RFC 6182 also includes
> some thoughts.

Mark Handley is in fact one of the authors of tcpcrypt and RFC 6182 so
we're working closely with him to figure out what the implications of
TCP options are in practice.  Section 5.4 of RFC 6182 concludes that TCP
options are the right way to go and hopefully that applies to tcpcrypt
too (we're working on it with Mark).  All tcpcrypt authors agree that
TCP is the right place for encryption from a design perspective, though
the one practical downside are middleboxes.  We're hoping we can
"handle" most cases by downgrading to TCP by checking if the options
make it through on the SYN / SYN-ACK.  A pretty bad case is when the SYN
is dropped.

For us to better present an argument (or perhaps even change our
design!) we're trying to figure out what the arguments are for an
application layer approach as opposed to a transport one.
Implementation has already come up.  From a design perspective however,
apart from middleboxes (or even more specifically, SYNs getting dropped)
we'd be glad to hear more opinions on why the application layer might be
more attractive.

From rgm-sec@htt-consult.com  Wed Aug  3 06:40:40 2011
Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C1721F8AF9 for <saag@ietfa.amsl.com>; Wed,  3 Aug 2011 06:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOLkba8brilF for <saag@ietfa.amsl.com>; Wed,  3 Aug 2011 06:40:40 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 262F421F8AEE for <saag@ietf.org>; Wed,  3 Aug 2011 06:40:40 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id A38D562AC6 for <saag@ietf.org>; Wed,  3 Aug 2011 13:40:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGg0jB6gSoKS for <saag@ietf.org>; Wed,  3 Aug 2011 09:40:20 -0400 (EDT)
Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 70D2C62934 for <saag@ietf.org>; Wed,  3 Aug 2011 09:40:20 -0400 (EDT)
Message-ID: <4E394FC4.4020801@htt-consult.com>
Date: Wed, 03 Aug 2011 09:40:20 -0400
From: Robert Moskowitz <rgm-sec@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11
MIME-Version: 1.0
To: saag@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [saag] RFC 6090 clean code
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 13:40:40 -0000

I keep coming back to this issue as I deal with hardware vendors that 
are careful about what they build into hardware; particularly when 
patent holders have been very vocal in the past about the value 
proposition of their patents.

Now that a new academic year is approaching, it would seem that there 
are students that could be coding RFC 6090 from a clean slate as their 
term project(s).  Said code SHOULD be free of intentional IPR 
infringement, but probably would still need review for parallelisms.

Is this worthwhile?  I would approach some of the unis I have 
connections to.

I personally am pushing for widespread use of ECDH in all of those 
billions of sensors set to be built over the next few years, and having 
something clean would do nothing but help.

Or if I am all wet (we actually had some rain last night in Detroit, and 
I took a walk out in it without an umbrella; it felt nice) I have other 
windmills to tilt at.



From turners@ieca.com  Thu Aug  4 06:45:03 2011
Return-Path: <turners@ieca.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF421F8B1D for <saag@ietfa.amsl.com>; Thu,  4 Aug 2011 06:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.243
X-Spam-Level: 
X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfZ6w-+kOFym for <saag@ietfa.amsl.com>; Thu,  4 Aug 2011 06:45:02 -0700 (PDT)
Received: from nm23-vm0.access.bullet.mail.mud.yahoo.com (nm23-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.141]) by ietfa.amsl.com (Postfix) with SMTP id C627921F8B14 for <saag@ietf.org>; Thu,  4 Aug 2011 06:45:02 -0700 (PDT)
Received: from [66.94.237.195] by nm23.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Aug 2011 13:45:17 -0000
Received: from [98.139.221.62] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 04 Aug 2011 13:45:17 -0000
Received: from [127.0.0.1] by smtp103.biz.mail.bf1.yahoo.com with NNFMP; 04 Aug 2011 13:45:17 -0000
X-Yahoo-Newman-Id: 459807.10170.bm@smtp103.biz.mail.bf1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: NYf0rCYVM1lxjamq9LpTpDWqvLELkZvobxom3bu9Hxxwb0J 75TgR.SrisCYTnb3KU1G9rc5Nxb0nsasnG9KM814BZqyucn6hfxrUqQr_.q2 lsXBB0S7PYvmZCImZhJZ7YKYLdBCBzae_CIE1kiaB1fQ3R.zxvRUNG51deSY vZM..I8umsUW.UOIn_wiF6jiS2wP761a6YXoZh.RiGOm09OwqST4L3P6vM_8 jmw.2eMH5jbiy7MfyNus.Pa580iI4QI5F7WU6nH7SvrF5cSoLybtugmoe3f7 3S3BEOxB7YIKVLeN4c6Q1Q8YPozRm5RVaGxpArDBwNGGu7H2YVqbxc29HljY LiGF5OD9Qf9dX3grDVyt69EAZ15i9LciPIlL.YoPOPM5lds6mFOCntAH4Rzb 4fiJ5Tqx1KgYQ5Sx9UvLX0g--
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from thunderfish.westell.com (turners@96.231.115.219 with plain) by smtp103.biz.mail.bf1.yahoo.com with SMTP; 04 Aug 2011 06:45:17 -0700 PDT
Message-ID: <4E3AA26C.4070401@ieca.com>
Date: Thu, 04 Aug 2011 09:45:16 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: saag@ietf.org
References: <D7A0423E5E193F40BE6E94126930C493087D47603E@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C493087D47603E@MBCLUSTER.xchange.nist.gov>
X-Forwarded-Message-Id: <D7A0423E5E193F40BE6E94126930C493087D47603E@MBCLUSTER.xchange.nist.gov>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [saag] Fwd: Request for Comments:  NIST SP 800-133, Recommendation for Cryptographic Key Generation
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2011 13:45:03 -0000

These documents may be of interest to people on these mail lists.

-------- Original Message --------
Subject: 	Request for Comments: NIST SP 800-133, Recommendation for 
Cryptographic Key Generation
Date: 	Thu, 4 Aug 2011 09:23:27 -0400
From: 	Caswell, Sara J. <sara.caswell@nist.gov>
To: 	turners@ieca.com <turners@ieca.com>



** PLEASE DO NOT REPLY TO THIS EMAIL **

NIST requests comments on Special Publication (SP) 800-133,
Recommendation for Cryptographic Key Generation. Cryptography relies
upon two basic components: an algorithm (or cryptographic methodology)
and a cryptographic key. This Recommendation discusses the generation of
the keys to be managed and used by NIST’s *approved* cryptographic
algorithms. The document is available at
http://csrc.nist.gov/publications/PubsSPs.html. Please provide comments
by September 30th, 2011 to SP-800-133_Comments@nist.gov
<mailto:SP-800-133_Comments@nist.gov?subject=Comments%20on%20SP%20800-133%20Key%20Generation>, 

with “Comments on SP 800-133 Key Generation” in the subject line.

** PLEASE DO NOT REPLY TO THIS EMAIL **


From Michael.Scharf@alcatel-lucent.com  Tue Aug  2 08:40:20 2011
Return-Path: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6717D21F85AE; Tue,  2 Aug 2011 08:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Level: 
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul-1i1Y1jF8q; Tue,  2 Aug 2011 08:40:19 -0700 (PDT)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 8C14621F858D; Tue,  2 Aug 2011 08:40:19 -0700 (PDT)
Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p72FeJ9d023709; Tue, 2 Aug 2011 17:40:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 2 Aug 2011 17:40:18 +0200
Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0654BD89@SLFSNX.rcs.alcatel-research.de>
In-Reply-To: <20110801191407.GA3765@shorty>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] fyi: tcpcrypt draft
Thread-Index: AcxQf3abwAXl+QxvSQyWhoUPGc+SjwAgsV6w
References: <4DC6C56D.6040709@ieca.com><D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com><20110727184256.GA3690@shorty><8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com><20110730014544.GM3751@shorty><4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <20110801191407.GA3765@shorty>
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: "Andrea Bittau" <bittau@cs.stanford.edu>, "David A. McGrew" <david.a.mcgrew@mindspring.com>
X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73
X-Mailman-Approved-At: Thu, 04 Aug 2011 08:03:11 -0700
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 15:40:20 -0000

> On Mon, Aug 01, 2011 at 10:25:14AM -0700, David A. McGrew wrote:
> > This sounds like an option worth pursuing, no pun intended.=20
>  You make=20
> > good points about why TCP is a good place to do the capability
> > discovery and fallback for crypto.   Why not define a TCP option
> > that can enable devices to discover TLS or tcpcrypt or other
> > higher-layer crypto protocols?   That option would be much easier to
> > implement and standardize, and it could tie into a full tcpcrypt=20
> > protocol that resides in a shim above the TCP layer.  The=20
> separation=20
> > will create useful implementation alternatives, and will=20
> isolate the=20
> > TCP state machine from changes.
>=20
> We have been considering this option throughout the work (and=20
> will still
> do) but:
>=20
> * No TCP header protection.  TCP-AO, which you suggest, does not
>   interoperate with NATs.  We want something that works "out of the
>   box".
>=20
> * We can't leverage the 3-way handshake if operating at the=20
> application
>   layer.  With tcpcrypt, we can do all session key negotiation in a
>   4-way handshake (just one extra leg), or 3 if session=20
> caching.  Saving
>   RTTs seems like a good thing.
>=20
> From a clean-slate perspective, it seems that integrating=20
> this into TCP has all the advantages we're looking for. =20
> Doing minimal work at TCP (like a signle "do you crypto?"=20
> option) and doing the rest at an application layer seems to=20
> come at a compromise (e.g., the drawbacks listed above).
>=20
> From an implementation perspective, I agree that the least=20
> changes to TCP are probably the best option.  tcpcrypt, at=20
> least for us, seems to have a good balance between=20
> clean-slate and (relatively) few changes to TCP, hence why=20
> we're pushing for it, as is.  If there were=20
> non-implementation arguments as to app vs. transport layer=20
> we'd love to hear those.

For whatever it is worth, the question of TCP extension vs. shim layer
seems to be somehow related to some discussions in the MPTCP WG last
year. In a different context, an expired ID
(http://tools.ietf.org/html/draft-scharf-mptcp-mctcp-01) discusses some
pros and cons of transport layer vs. shim layer+discovery by SYN
options. Not all of them are about implementation, and IMHO both
alternatives have disadvantages. Section 5.4 of RFC 6182 also includes
some thoughts.

Michael

From jan.pechanec@oracle.com  Tue Aug  2 10:42:08 2011
Return-Path: <jan.pechanec@oracle.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0935A11E8095 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 10:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCxbHQcN1ubg for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 10:42:07 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16511E807F for <saag@ietf.org>; Tue,  2 Aug 2011 10:42:07 -0700 (PDT)
Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p72HfeAM031134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 17:41:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p72HfbMg017665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 17:41:38 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p72HfTpd015266; Tue, 2 Aug 2011 12:41:31 -0500
Received: from fossa (/10.163.107.122) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 10:41:29 -0700
Date: Tue, 2 Aug 2011 19:31:04 +0200 (CEST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jp161948@fossa
To: Stef Walter <stefw@collabora.co.uk>
In-Reply-To: <4E37E046.7000403@collabora.co.uk>
Message-ID: <alpine.GSO.2.00.1108021925020.3276@fossa>
References: <4E37ABE3.8090802@collabora.co.uk> <4E37CA8B.9050602@Oracle.COM> <4E37E046.7000403@collabora.co.uk>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Source-IP: rtcsinet21.oracle.com [66.248.204.29]
X-CT-RefId: str=0001.0A090206.4E3836D7.002A,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Thu, 04 Aug 2011 08:03:11 -0700
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, saag@ietf.org, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Subject: Re: [saag] Rename PKCS#11 URI 'pinfile' argument to 'pin'?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 18:01:58 -0000

On Tue, 2 Aug 2011, Stef Walter wrote:

>Ah yes, good point.
>
>> I agree that 'pinfile' isn't as flexible a name as it could be given
>> what kind of thing applications could choose to do with it.
>
>Would 'pinsrc' or 'pin-source' be a good option?

	hi Stef, I agree that pinfile is not the best name, I like your 
pin source suggestion, "pin-source". Would that be OK for everyone?

	there is one more thing, we use "-" in all two word attributes:

library-manufacturer
library-description
library-version

	aside from "objecttype" (and "pinfile"). If we have 
"pin-source", wouldn't it be good to rename "objecttype" to 
"object-type"? That way, we would be consistent in how we create 
attribute names. 

	J. 

>Cheers,
>
>Stef
>

-- 
Jan Pechanec
http://blogs.oracle.com/janp

From n.mavrogiannopoulos@gmail.com  Tue Aug  2 11:45:43 2011
Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87B421F8748 for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 11:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7+1N32bQAdo for <saag@ietfa.amsl.com>; Tue,  2 Aug 2011 11:45:43 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 24EC021F8747 for <saag@ietf.org>; Tue,  2 Aug 2011 11:45:42 -0700 (PDT)
Received: by wwg11 with SMTP id 11so2782179wwg.1 for <saag@ietf.org>; Tue, 02 Aug 2011 11:45:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=8o+oQ64U3CNKZZwVyfrpactSj3Fcv/Srk7Vilg5Qgzc=; b=tHY6Z7VjQTzrAzLyrtihDAJa13wQA1vvtguhSUbNO2skhq0TxhJg9mkZ4LHn9pU2cD WtEB0Ebthd7bpwgeReuggISmYKUtVbGHIX58zk5bkPE0q0RJ/ZonwDBn1HqobMjk1F5w gJmhUMTsLiiqsLCd6/W2fB7lLBa9CYo0kKe0g=
Received: by 10.216.54.136 with SMTP id i8mr2109799wec.49.1312310751895; Tue, 02 Aug 2011 11:45:51 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id g48sm28851wee.13.2011.08.02.11.45.49 (version=SSLv3 cipher=OTHER); Tue, 02 Aug 2011 11:45:50 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E3845DD.7070306@gnutls.org>
Date: Tue, 02 Aug 2011 20:45:49 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Jan Pechanec <jan.pechanec@oracle.com>
References: <4E37ABE3.8090802@collabora.co.uk> <4E37CA8B.9050602@Oracle.COM> <4E37E046.7000403@collabora.co.uk> <alpine.GSO.2.00.1108021925020.3276@fossa>
In-Reply-To: <alpine.GSO.2.00.1108021925020.3276@fossa>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 04 Aug 2011 08:03:11 -0700
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, Stef Walter <stefw@collabora.co.uk>, saag@ietf.org
Subject: Re: [saag] Rename PKCS#11 URI 'pinfile' argument to 'pin'?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 18:45:43 -0000

On 08/02/2011 07:31 PM, Jan Pechanec wrote:

>>> I agree that 'pinfile' isn't as flexible a name as it could be given
>>> what kind of thing applications could choose to do with it.
>> Would 'pinsrc' or 'pin-source' be a good option?
> 
> 	hi Stef, I agree that pinfile is not the best name, I like your 
> pin source suggestion, "pin-source". Would that be OK for everyone?

Fine with me.

> 	there is one more thing, we use "-" in all two word attributes:
> 	aside from "objecttype" (and "pinfile"). If we have 
> "pin-source", wouldn't it be good to rename "objecttype" to 
> "object-type"? That way, we would be consistent in how we create 
> attribute names. 

I also think being consistent is nice.

regards,
Nikos

From c.raiciu@cs.ucl.ac.uk  Wed Aug  3 04:44:52 2011
Return-Path: <c.raiciu@cs.ucl.ac.uk>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5B21F8B21; Wed,  3 Aug 2011 04:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP6UD+QFbLyQ; Wed,  3 Aug 2011 04:44:51 -0700 (PDT)
Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA421F8B18; Wed,  3 Aug 2011 04:44:51 -0700 (PDT)
Received: from [141.85.37.138] (helo=[10.0.0.3]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1QoZrV-0009X5-Cm; Wed, 03 Aug 2011 12:43:45 +0100
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
In-Reply-To: <20110802213101.GJ3814@shorty>
Date: Wed, 3 Aug 2011 14:44:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AE53878-7A53-4AD2-80C2-07ADD000E479@cs.ucl.ac.uk>
References: <4DC6C56D.6040709@ieca.com> <D1CCED3D-C041-4DA2-B999-D3EF7FC889D0@cisco.com> <20110727184256.GA3690@shorty> <8A00B447-53C3-44D0-8238-8DAAE44688CB@mindspring.com> <20110730014544.GM3751@shorty> <4884218B-9477-4F6D-84BB-9EB07F4D5CA9@mindspring.com> <20110801191407.GA3765@shorty> <133D9897FB9C5E4E9DF2779DC91E947C0654BD89@SLFSNX.rcs.alcatel-research.de> <20110802213101.GJ3814@shorty>
To: Andrea Bittau <bittau@cs.stanford.edu>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Thu, 04 Aug 2011 08:03:11 -0700
Cc: tcpcrypt@scs.stanford.edu, tsv-area@ietf.org, "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>, "David A. McGrew" <david.a.mcgrew@mindspring.com>, saag@ietf.org
Subject: Re: [saag] fyi: tcpcrypt draft
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 11:44:52 -0000

Hi,

Michio Honda has recently performed experiments on exactly these issues =
of extending TCP; the results are reported in an IMC paper to be =
published later this year that Michio and us have co-authored.

I can send the paper to interested people (please email me directly) but =
can't send it on this list because it is still not in its final form.

The paper probes 150 access networks (including home, hotspots, 3g =
providers, cable, etc) to check and see if new  TCP options get through, =
and whether middleboxes resegment the TCP stream.=20
There are many other tests there, but those are not necesarily relevant =
to tcpcrypt. The paper does not probe the server end of things where =
firewalls, load balancers and the like can cause further  grief.

The new options get through on SYNs on 86% - 96% of the paths we probed. =
The percentage depends on the TCP port (only 86% allow new options on =
HTTP traffic, 94% on HTTPS traffic, and 96% for a new, unknown port).
SYNs with new options were never dropped; in the remaining 4%-14% of the =
cases the new options were simply removed.

As for middleboxes that resegment the bytestream: this behaviour did =
appear in the tests, but it was correlated with the removal of new =
options on SYNs. Basically, middleboxes that resegment tend to terminate =
the connection and open a new one to the destination, acting like a full =
proxy.

We've analyzed all experimental data and its implications for about =
mptcp and tcpcrypt: the result is that these two protocols seem safe to =
deploy today in the access networks we've probed.=20

Cheers,
Costin

On 3 Aug 2011, at 00:31, Andrea Bittau wrote:

> On Tue, Aug 02, 2011 at 05:40:18PM +0200, SCHARF, Michael wrote:
>> For whatever it is worth, the question of TCP extension vs. shim =
layer
>> seems to be somehow related to some discussions in the MPTCP WG last
>> year. In a different context, an expired ID
>> (http://tools.ietf.org/html/draft-scharf-mptcp-mctcp-01) discusses =
some
>> pros and cons of transport layer vs. shim layer+discovery by SYN
>> options. Not all of them are about implementation, and IMHO both
>> alternatives have disadvantages. Section 5.4 of RFC 6182 also =
includes
>> some thoughts.
>=20
> Mark Handley is in fact one of the authors of tcpcrypt and RFC 6182 so
> we're working closely with him to figure out what the implications of
> TCP options are in practice.  Section 5.4 of RFC 6182 concludes that =
TCP
> options are the right way to go and hopefully that applies to tcpcrypt
> too (we're working on it with Mark).  All tcpcrypt authors agree that
> TCP is the right place for encryption from a design perspective, =
though
> the one practical downside are middleboxes.  We're hoping we can
> "handle" most cases by downgrading to TCP by checking if the options
> make it through on the SYN / SYN-ACK.  A pretty bad case is when the =
SYN
> is dropped.
>=20
> For us to better present an argument (or perhaps even change our
> design!) we're trying to figure out what the arguments are for an
> application layer approach as opposed to a transport one.
> Implementation has already come up.  =46rom a design perspective =
however,
> apart from middleboxes (or even more specifically, SYNs getting =
dropped)
> we'd be glad to hear more opinions on why the application layer might =
be
> more attractive.


From vishwas.ietf@gmail.com  Thu Aug  4 19:58:04 2011
Return-Path: <vishwas.ietf@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4095321F874F for <saag@ietfa.amsl.com>; Thu,  4 Aug 2011 19:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level: 
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5qjjYQkgXxL for <saag@ietfa.amsl.com>; Thu,  4 Aug 2011 19:58:03 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44421F874B for <saag@ietf.org>; Thu,  4 Aug 2011 19:58:03 -0700 (PDT)
Received: by qyk34 with SMTP id 34so78982qyk.10 for <saag@ietf.org>; Thu, 04 Aug 2011 19:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XK2n9uWjbHdfp0RVfLAjBxHbdf1nrPjEIqStPKt3goE=; b=kz3wh3yh+EDOd24VyEIVNT9VsFLenBffLxt9JJxyWqJeq1pqtKzVcJWiQipKaeR7+g CGpmm1F5WN/6PZqz6M9OQi5gypDFUJPqZ9Vf0TcuQqKqQmQ2RRi8xds8g6PPalKGPyQV xHxvrR0bMkbtdjb3aJ/oJwyjK08H5xzXPy9qo=
MIME-Version: 1.0
Received: by 10.229.106.32 with SMTP id v32mr1281579qco.77.1312513099235; Thu, 04 Aug 2011 19:58:19 -0700 (PDT)
Received: by 10.229.65.91 with HTTP; Thu, 4 Aug 2011 19:58:19 -0700 (PDT)
In-Reply-To: <CAOyVPHTApJ3X50HAZ13xKGXQ7j5uJ1pdOx0DfJPoukML1qZuCQ@mail.gmail.com>
References: <4E3628E4.2070008@KingsMountain.com> <CAOyVPHTApJ3X50HAZ13xKGXQ7j5uJ1pdOx0DfJPoukML1qZuCQ@mail.gmail.com>
Date: Thu, 4 Aug 2011 19:58:19 -0700
Message-ID: <CAOyVPHRS8siJ1MEC54OeyNfisce94CCCLfwkpThvTB9pmS=XGg@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: multipart/alternative; boundary=00235429dbc40b015e04a9b94580
Cc: IETF Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] fyi: talk @ Stanford: Owning the Routing Table - New OSPF Attacks - FRIDAY - AUG 5
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2011 02:58:04 -0000

--00235429dbc40b015e04a9b94580
Content-Type: text/plain; charset=ISO-8859-1

Hi guys,

I looked at the presentation. It basically assumes the attacker has the MD5
keys used to protect OSPF sessions and the attacker controls a router.

Ofcourse once ots well known once there is a wrong router, it can redirect
all traffic to itself, create routing loops, blackholes and do everything
else. It is for this very purpose that MD5 is used. :)

Thanks,
Vishwas
On Mon, Aug 1, 2011 at 1:25 PM, Vishwas Manral <vishwas.ietf@gmail.com>wrote:

> Hi Jeff,
>
> Thanks for forwarding this. Let me try to get more details of what they are
> trying to do here.
>
> I am not sure what new vulnerabilities they have found. However from what I
> see it looks like things we well know and by the issues can be negated by
> using authentication in OSPF.
>
> Also it is well known that if a router in a domain is compormised and
> accepts unauthenticated packets, it can cause routing issues /which means
> loops/ blackholes etc. Sounds liek they may be using a higher sequence
> number LSA of a router they do not control, which can disrupt routing.
>
> Thanks,
> Vishwas
>   On Sun, Jul 31, 2011 at 9:17 PM, =JeffH <Jeff.Hodges@kingsmountain.com>wrote:
>
>> [ perhaps something to share with ospf@ietf.org  nor
>> routing-discussion@ietf.org ?  (I'm not sub'd to those lists) ]
>>
>>
>> Subject: FRIDAY - AUG 5 - Owning the Routing Table - New OSPF Attacks -
>>        Nakibly Gabi
>> From: Ankur Taly <ataly@stanford.edu>
>> Date: Fri, 29 Jul 2011 23:08:46 -0700 (PDT)
>> To: security-seminar <security-seminar@lists.**stanford.edu<security-seminar@lists.stanford.edu>
>> >
>> Cc: Nakibly Gabi <gabin@rafael.co.il>
>>
>> TITLE: Owning the Routing Table - New OSPF Attacks
>>
>> SPEAKER: Nakibly Gabi
>>
>> ABSTRACT: The holy grail of routing attacks is owning the routing table of
>> a router. We present new found vulnerabilities in the OSPF protocol - the
>> most popular routing protocol inside autonomous systems (AS) - which allow
>> to own a router's routing table without having to own the router itself. We
>> present new attacks that falsify the LSAs of routers not controlled by the
>> attacker while evading the "fight-back" mechanism. These attacks affords a
>> single attacker a great power to persistently falsify large portions of the
>> routing domain's topology. This may be utilized to induce routing loops,
>> network cuts or longer routes in order to facilitate DoS of the routing
>> domain or to gain access to information flows which otherwise the attacker
>> had no access to. This is a joint work with Alex Kirshon and Dima Gonikman.
>> The talk shall be presented at Black Hat USA 2011.
>>
>> Venue: Gates 463
>> Time: 4:30 pm
>> Date: 5 August 2011 (Friday)
>>
>> --++**==--++**==--++**==--++****==--++**==--++**==--++**==
>> security-seminar mailing list
>> security-seminar@lists.**stanford.edu<security-seminar@lists.stanford.edu>
>> https://mailman.stanford.edu/**mailman/listinfo/security-**seminar<https://mailman.stanford.edu/mailman/listinfo/security-seminar>
>> ______________________________**_________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/**listinfo/saag<https://www.ietf.org/mailman/listinfo/saag>
>>
>
>

--00235429dbc40b015e04a9b94580
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Hi guys,</div>
<div>=A0</div>
<div>I looked at the presentation. It basically assumes the attacker has th=
e MD5 keys used to protect OSPF sessions and the attacker controls a router=
. </div>
<div>=A0</div>
<div>Ofcourse once ots well known once there is a wrong router, it can redi=
rect all traffic to itself,=A0create routing loops, blackholes and do every=
thing else. It is for this very purpose that MD5 is used. :)</div>
<div>=A0</div>
<div>Thanks,</div>
<div>Vishwas<br></div>
<div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 1:25 PM, Vishwas Manral <=
span dir=3D"ltr">&lt;<a href=3D"mailto:vishwas.ietf@gmail.com">vishwas.ietf=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>Hi Jeff,</div>
<div>=A0</div>
<div>Thanks for forwarding this. Let me try to get more details of what the=
y are trying to do here.</div>
<div>=A0</div>
<div>I am not sure what new vulnerabilities they have found. However from w=
hat I see it looks like things we well know and by the issues can be negate=
d by using authentication in OSPF.=A0</div>
<div>=A0</div>
<div>Also it=A0is well known that if a router in a domain is compormised an=
d accepts unauthenticated packets, it can cause routing issues /which means=
 loops/ blackholes etc. Sounds liek they may be using a higher sequence num=
ber LSA of a router they do not control, which can disrupt routing.</div>

<div>=A0</div>
<div>Thanks,</div>
<div>Vishwas<font color=3D"#888888"><br></font></div>
<div>
<div></div>
<div class=3D"h5">
<div class=3D"gmail_quote">On Sun, Jul 31, 2011 at 9:17 PM, =3DJeffH <span =
dir=3D"ltr">&lt;<a href=3D"mailto:Jeff.Hodges@kingsmountain.com" target=3D"=
_blank">Jeff.Hodges@kingsmountain.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">[ perhaps something to share wit=
h <a href=3D"mailto:ospf@ietf.org" target=3D"_blank">ospf@ietf.org</a> =A0n=
or <a href=3D"mailto:routing-discussion@ietf.org" target=3D"_blank">routing=
-discussion@ietf.org</a> ? =A0(I&#39;m not sub&#39;d to those lists) ]<br>
<br><br>Subject: FRIDAY - AUG 5 - Owning the Routing Table - New OSPF Attac=
ks -<br>=A0 =A0 =A0 =A0Nakibly Gabi<br>From: Ankur Taly &lt;<a href=3D"mail=
to:ataly@stanford.edu" target=3D"_blank">ataly@stanford.edu</a>&gt;<br>Date=
: Fri, 29 Jul 2011 23:08:46 -0700 (PDT)<br>
To: security-seminar &lt;<a href=3D"mailto:security-seminar@lists.stanford.=
edu" target=3D"_blank">security-seminar@lists.<u></u>stanford.edu</a>&gt;<b=
r>Cc: Nakibly Gabi &lt;<a href=3D"mailto:gabin@rafael.co.il" target=3D"_bla=
nk">gabin@rafael.co.il</a>&gt;<br>
<br>TITLE: Owning the Routing Table - New OSPF Attacks<br><br>SPEAKER: Naki=
bly Gabi<br><br>ABSTRACT: The holy grail of routing attacks is owning the r=
outing table of a router. We present new found vulnerabilities in the OSPF =
protocol - the most popular routing protocol inside autonomous systems (AS)=
 - which allow to own a router&#39;s routing table without having to own th=
e router itself. We present new attacks that falsify the LSAs of routers no=
t controlled by the attacker while evading the &quot;fight-back&quot; mecha=
nism. These attacks affords a single attacker a great power to persistently=
 falsify large portions of the routing domain&#39;s topology. This may be u=
tilized to induce routing loops, network cuts or longer routes in order to =
facilitate DoS of the routing domain or to gain access to information flows=
 which otherwise the attacker had no access to. This is a joint work with A=
lex Kirshon and Dima Gonikman. The talk shall be presented at Black Hat USA=
 2011.<br>
<br>Venue: Gates 463<br>Time: 4:30 pm<br>Date: 5 August 2011 (Friday)<br><b=
r>--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**<u></u>=3D=3D--++**=3D=3D--++**=
=3D=3D--++**=3D=3D<br>security-seminar mailing list<br><a href=3D"mailto:se=
curity-seminar@lists.stanford.edu" target=3D"_blank">security-seminar@lists=
.<u></u>stanford.edu</a><br>
<a href=3D"https://mailman.stanford.edu/mailman/listinfo/security-seminar" =
target=3D"_blank">https://mailman.stanford.edu/<u></u>mailman/listinfo/secu=
rity-<u></u>seminar</a><br>______________________________<u></u>___________=
______<br>
saag mailing list<br><a href=3D"mailto:saag@ietf.org" target=3D"_blank">saa=
g@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/saag" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<u></u>listinfo/saag</a><br></=
blockquote>
</div><br></div></div></blockquote></div><br>

--00235429dbc40b015e04a9b94580--

From d3e3e3@gmail.com  Wed Aug 10 06:35:00 2011
Return-Path: <d3e3e3@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E6F21F89C2 for <saag@ietfa.amsl.com>; Wed, 10 Aug 2011 06:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.17
X-Spam-Level: 
X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-2.924, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wToelf2i1j-h for <saag@ietfa.amsl.com>; Wed, 10 Aug 2011 06:34:59 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F99121F89A7 for <saag@ietf.org>; Wed, 10 Aug 2011 06:34:59 -0700 (PDT)
Received: by ywm21 with SMTP id 21so717036ywm.31 for <saag@ietf.org>; Wed, 10 Aug 2011 06:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=qZDrMzSMP6o6Y/NzqwNRykJ0bc2+WMgjIPZc2ZXzCjk=; b=PAYBa41uCuBuWttcomGYYInwBxac1+PZw37aPCbAx+cQaArzdRj1Uy7cmaPmq2m1jJ XPjJxHM6x070WHSKobqbuDNn4wRhH3rG5j6nkSLPLKYhm8ITR2h/MQsy4i251iLkGJDa 74cl4s3SKFSycwZQ80YHVRfM0Y/W45Rs4CWYs=
Received: by 10.151.43.8 with SMTP id v8mr8191739ybj.296.1312983331059; Wed, 10 Aug 2011 06:35:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.5 with HTTP; Wed, 10 Aug 2011 06:35:11 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 10 Aug 2011 09:35:11 -0400
Message-ID: <CAF4+nEExM2TCgw9vMA_UD4A1WS_C_Ctujq8jQ6EGVQc6S2GCCQ@mail.gmail.com>
To: saag@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: base64
Subject: [saag] Password
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 13:35:00 -0000

U2VlIGh0dHA6Ly94a2NkLmNvbS85MzYvCgpUaGFua3MsCkRvbmFsZAo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PQqgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZKCgICsxLTUwOC0zMzMtMjI3MCAo
Y2VsbCkKoDE1NSBCZWF2ZXIgU3RyZWV0CqBNaWxmb3JkLCBNQSAwMTc1NyBVU0EKoGQzZTNlM0Bn
bWFpbC5jb20K

From warren@kumari.net  Wed Aug 10 07:44:58 2011
Return-Path: <warren@kumari.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1949021F86C2 for <saag@ietfa.amsl.com>; Wed, 10 Aug 2011 07:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.251
X-Spam-Level: 
X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i03lY-URUUaL for <saag@ietfa.amsl.com>; Wed, 10 Aug 2011 07:44:57 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 79E4021F86B1 for <saag@ietf.org>; Wed, 10 Aug 2011 07:44:57 -0700 (PDT)
Received: from [192.168.1.4] (24-104-73-2-ip-static.hfc.comcastbusiness.net [24.104.73.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 797541B4105C; Wed, 10 Aug 2011 10:45:26 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CAF4+nEExM2TCgw9vMA_UD4A1WS_C_Ctujq8jQ6EGVQc6S2GCCQ@mail.gmail.com>
Date: Wed, 10 Aug 2011 07:45:28 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <E77C0586-D58A-4BAE-A995-E3F78B205734@kumari.net>
References: <CAF4+nEExM2TCgw9vMA_UD4A1WS_C_Ctujq8jQ6EGVQc6S2GCCQ@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: saag@ietf.org
Subject: Re: [saag] Password
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 14:44:58 -0000

On Aug 10, 2011, at 6:35 AM, Donald Eastlake wrote:

> See http://xkcd.com/936/
> 

hunter2

http://bash.org/?244321


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


From jsalowey@cisco.com  Wed Aug 17 12:19:19 2011
Return-Path: <jsalowey@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33A511E80BE for <saag@ietfa.amsl.com>; Wed, 17 Aug 2011 12:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.775
X-Spam-Level: 
X-Spam-Status: No, score=-103.775 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA+EzEh1Y2N4 for <saag@ietfa.amsl.com>; Wed, 17 Aug 2011 12:19:19 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2107D11E80B5 for <saag@ietf.org>; Wed, 17 Aug 2011 12:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=665; q=dns/txt; s=iport; t=1313608811; x=1314818411; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=PScXXxlzeelzE5Pf2/apCvPlZK0rKBkjNUiq7FFzH2o=; b=kpJrAhleZZNVzN8EobavFzkf4HQbzjAZNE0NIMcmkysmuYqmzUKDfQKD GcnsxjC4ni2zTEHVQKsFPmDZWbeDLO8c0xIFRnA7OelpyLIsmsP/gAU6d MNvKEl0mVoXhi1Yklwwx2DGJn7Drqekn7Jt0BMuUCNKSjBgsEjQtqxuFj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUHAEUUTE6rRDoH/2dsb2JhbABCmV6PFXeBWQEngjKeFoEjAZ8KhWlfBIdgizOFDIwJ
X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208";a="14063331"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 17 Aug 2011 19:19:59 +0000
Received: from [10.33.249.193] ([10.33.249.193]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7HJJxnx007100 for <saag@ietf.org>; Wed, 17 Aug 2011 19:19:59 GMT
From: Joe Salowey <jsalowey@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2011 12:20:00 -0700
Message-Id: <EF14B3B1-A0FE-4B9D-B133-468FA2E220EB@cisco.com>
To: saag@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [saag] IETF-81 TLS meeting report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2011 19:19:19 -0000

TLS met on Thursday Afternoon.  DTLS heartbeat is ready for last call.  =
Eric presented a suggestion for a working group policy for handling TLS =
extensions.  Paul Hoffman will work with the chairs on some text for the =
policy that will be discussed on the list.  Dirk Balfanz presented his =
draft on origin bound certificates in TLS which seemed to be well =
received.  Paul Wouters presented a TLS Extension for out-of-band public =
key validation that could be useful for DANE and other use cases.  There =
was some support in the room for continuing work in this direction. Paul =
Hoffman gave an information presentation on DNS serialization.=20=

From turners@ieca.com  Tue Aug 23 11:02:58 2011
Return-Path: <turners@ieca.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2D21F8B4E for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.944
X-Spam-Level: 
X-Spam-Status: No, score=-100.944 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZXPRXpFxEbd for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:02:58 -0700 (PDT)
Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by ietfa.amsl.com (Postfix) with SMTP id 8A18A21F8B2D for <saag@ietf.org>; Tue, 23 Aug 2011 11:02:58 -0700 (PDT)
Received: from [98.139.91.64] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2011 18:04:01 -0000
Received: from [98.139.91.10] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 23 Aug 2011 18:04:01 -0000
Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 23 Aug 2011 18:04:01 -0000
X-Yahoo-Newman-Id: 676648.82479.bm@omp1010.mail.sp2.yahoo.com
Received: (qmail 58833 invoked from network); 23 Aug 2011 18:04:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314122641; bh=bmZH8k8zUfSaVN7Rbii/AM1jv4ohAvLckMQuEdRgFDk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=U04K5VKw8VscsMYoRRcCQOzZHCLDd52MpgCykdTmiuaH8DVj+Q3T2HABHLfKWJlQz5TMAALH2Iw6v+gjrLxLjSu9xT6iTztDJTwOcaHF9dP+a+bMXMoApR7j20bHDXUykIG8xmIfv2d1HWY59VLY1Y58VMNS61CqQLwfX0zfA58=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: nXjkzN0VM1kzRyotbkOAajoNhcih.ZXayZNsgDhF5dUBhnS N2cIeohLTy2g67m.Z4XUtDKXWXK9u4hVsVvkcq2uPhZDuHyvQj05bYYLO6_h _WsMROCXEp5T94QAmCmQ.5AWzVPbkUPSggizy0j6PrhCDq4AjJ9kwI1WRYoM alxWrYY4AM7YJPMqg14dfotLSuU54UIkkV6W9GGN1GlZHBhavO3MYof6tapf vI4.QkrxaTqzgWbB3lvlKnM2pdGI.9hN3ZWNNu0agV1njVM2Zz8vVDj.EpGQ NDvnEmpv38LiBTuHZhZ0BSmFRlZWbetmbXaIiwN8NuRAgfVWc.RBg8rU2kLc OuhJImFvnbjGJYP0BqWzxszF1HxYXmvIsRk2kJkOfh3V23Yhhlf9ovMIJJzz PV_Op8w45Xjj0CSYbIDotl5RXgt2RAmR9GrNatzEl
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from thunderfish.westell.com (turners@96.231.120.184 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 23 Aug 2011 11:04:01 -0700 PDT
Message-ID: <4E53EB90.90304@ieca.com>
Date: Tue, 23 Aug 2011 14:04:00 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: saag@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:02:59 -0000

At the last couple of IETF we've had a number of security WGs occur 
after saag.  We're considering moving saag (normally right after 
Thursday lunch) back one slot.  Stephen and I thought we should run this 
by the community because saag's been in the same slot for years.

spt

From paul.hoffman@vpnc.org  Tue Aug 23 11:14:28 2011
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD621F8BD5 for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOHOi1lvhKTz for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:14:28 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 19ECF21F8B25 for <saag@ietf.org>; Tue, 23 Aug 2011 11:14:28 -0700 (PDT)
Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7NIFYCx085780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Aug 2011 11:15:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <4E53EB90.90304@ieca.com>
Date: Tue, 23 Aug 2011 11:15:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org>
References: <4E53EB90.90304@ieca.com>
To: Sean Turner <turners@ieca.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:14:28 -0000

On Aug 23, 2011, at 11:04 AM, Sean Turner wrote:

> At the last couple of IETF we've had a number of security WGs occur =
after saag.  We're considering moving saag (normally right after =
Thursday lunch) back one slot.  Stephen and I thought we should run this =
by the community because saag's been in the same slot for years.


Define "back". :-) =46rom the context, I assume that you mean "later in =
the day", but you could also mean "back towards the beginning of the =
meeting" (that is, Thursday morning).

--Paul Hoffman


From turners@ieca.com  Tue Aug 23 11:18:27 2011
Return-Path: <turners@ieca.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6398C21F8BA0 for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.03
X-Spam-Level: 
X-Spam-Status: No, score=-101.03 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uskeSpVTx2bQ for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:18:26 -0700 (PDT)
Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with SMTP id B70FD21F8B94 for <saag@ietf.org>; Tue, 23 Aug 2011 11:18:26 -0700 (PDT)
Received: from [98.139.212.146] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2011 18:19:27 -0000
Received: from [98.139.212.204] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 23 Aug 2011 18:19:27 -0000
Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 23 Aug 2011 18:19:27 -0000
X-Yahoo-Newman-Id: 918376.90309.bm@omp1013.mail.bf1.yahoo.com
Received: (qmail 5598 invoked from network); 23 Aug 2011 18:19:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314123567; bh=KiP6egufpFa3QMGHaVQoZ/wEgfr+x930oM5OFKScjBw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FtsNFpGL0oosqkN0UzLydqC7zTG7s9RQ/vzMPXJO27uRoxfrMFrsTWlEZ0GqDLT45MbKIS9ngBgthV464x96wf2On10R9/dM2ryVDJuH82H8Koi6Pxh8wFw+FlITjo3yNslhCiI/ObsgHdL4DwlxpWZxlzpKP0ZKbNXB59OWuRE=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: Amkhi7gVM1n1GvOo1WVzcZ5bPMIcL9FxCECPWw.cwSSyqLw RkLJHGSsu6XzTquNJbzQMwqihkzqKVpC6AV_.ihHYXSqk5zFZJye2XN5nEOt DXjfYCuAqYOga.aYptMXVbqZ6OXO.U.1mx6OUb1sd3cRMkKBs5BAJEM0IpFE F6U_sIlEWneubWQFYyfW6oyLY_yGzQzH90LHEh7RGB_E0X9dNN_tAVAWp07Z TRla67rVNtfqS8.Eh1WvSnXaH4eYy.GlV5ntaW4b2h5sNPAc0lM.UzNCxRGk lYNteJAh_nmRQBD_59jbWNyYoDxPPSjIcITiVP.V7h.pio.yqXSe0V_8B18G Jf1Xdn5nI1HALhR7IrOlsCg6dGgHi4jlAd.0QjzMTEeEcySXMNMVO3Q.C33R BIczwyeO9MmxW7y85GzgS3g5Y1Sg2apd1CNZCT5py0MWKWTzFkN8-
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
Received: from thunderfish.westell.com (turners@96.231.120.184 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 23 Aug 2011 11:19:27 -0700 PDT
Message-ID: <4E53EF2E.8010500@ieca.com>
Date: Tue, 23 Aug 2011 14:19:26 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <4E53EB90.90304@ieca.com> <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org>
In-Reply-To: <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:18:27 -0000

On 8/23/11 2:15 PM, Paul Hoffman wrote:
> On Aug 23, 2011, at 11:04 AM, Sean Turner wrote:
>
>> At the last couple of IETF we've had a number of security WGs occur after saag.  We're considering moving saag (normally right after Thursday lunch) back one slot.  Stephen and I thought we should run this by the community because saag's been in the same slot for years.
>
>
> Define "back". :-) From the context, I assume that you mean "later in the day", but you could also mean "back towards the beginning of the meeting" (that is, Thursday morning).

 From 1300-1500 Afternoon Session I to 1520-1720  Afternoon Session II. 
  This assumes they keep the sessions slots the same.

spt

From barryleiba.mailing.lists@gmail.com  Tue Aug 23 11:20:50 2011
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3221F8713 for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.032
X-Spam-Level: 
X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW2aNa2JH2Oh for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:20:50 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1430221F86FF for <saag@ietf.org>; Tue, 23 Aug 2011 11:20:50 -0700 (PDT)
Received: by yie12 with SMTP id 12so359205yie.31 for <saag@ietf.org>; Tue, 23 Aug 2011 11:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MGIAfZy7JepT9vzcBhkLINGWfxL0XEUApH0u4c3ROSU=; b=FpXbTWVNIlhtuV6epedm4Zok+2Zz/fV0IreQv3FK6NMIWuUw+XZS+wH+yPLU/im9Se riHKAQQQ9qgr2axJR2/uspioIW4BnvN1AHHgJuPQEQXRXii0y4YHUbk1qoX5PNDhFjv/ 4kbH3KM3wCGSCafIKgtrv4niqfJyLmGF0JxPI=
MIME-Version: 1.0
Received: by 10.146.58.22 with SMTP id g22mr4024640yaa.34.1314123718112; Tue, 23 Aug 2011 11:21:58 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.181.13 with HTTP; Tue, 23 Aug 2011 11:21:58 -0700 (PDT)
In-Reply-To: <4E53EF2E.8010500@ieca.com>
References: <4E53EB90.90304@ieca.com> <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org> <4E53EF2E.8010500@ieca.com>
Date: Tue, 23 Aug 2011 14:21:58 -0400
X-Google-Sender-Auth: BjkmVjAymrWMQqFG-4aLcnAmBZo
Message-ID: <CAC4RtVAq12mEvgSRnjSOhFVwzePrtp_XAGX8ojjOefOiFk+9tw@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Sean Turner <turners@ieca.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:20:51 -0000

> From 1300-1500 Afternoon Session I to 1520-1720 =A0Afternoon Session II. =
=A0This
> assumes they keep the sessions slots the same.

I'll be there all week, so anything works for me, modulo conflicts.
Friday morning's fine, too, or even Friday after the cookie break.
Cookies can help keep us cruising.

Barry

From klaas@cisco.com  Tue Aug 23 11:51:42 2011
Return-Path: <klaas@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413CF21F8BAA for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYltZ8+TSCJZ for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:51:41 -0700 (PDT)
Received: from out46-ams.mf.surf.net (out46-ams.mf.surf.net [145.0.1.46]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1421F8B8F for <saag@ietf.org>; Tue, 23 Aug 2011 11:51:41 -0700 (PDT)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7NIqjTP017502; Tue, 23 Aug 2011 20:52:46 +0200
Received: from 5ed00726.cm-7-1a.dynamic.ziggo.nl ([94.208.7.38] helo=[192.168.1.108]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from <klaas@cisco.com>) id 1Qvw4a-000A2z-Dc; Tue, 23 Aug 2011 20:51:40 +0200
References: <4E53EB90.90304@ieca.com> <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org> <4E53EF2E.8010500@ieca.com>
In-Reply-To: <4E53EF2E.8010500@ieca.com>
Mime-Version: 1.0 (iPad Mail 8L1)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <9FF025A3-8B09-48C4-890B-BCC94DFB150F@cisco.com>
X-Mailer: iPad Mail (8L1)
From: Klaas Wierenga <klaas@cisco.com>
Date: Tue, 23 Aug 2011 20:53:26 +0200
To: Sean Turner <turners@ieca.com>
X-Antivirus: no malware found
X-Bayes-Prob: 0.5 (Score 0, tokens from: @@RPTN)
X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0vFnSQJKf - c17d3b76ce9d - 20110823 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.46
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:51:42 -0000

Hi,

That would still have been too early for abfab ;-) Anyway, pushing it back a=
 bit works for me. Friday less so because people might decide they don't nee=
d to stay until friday..... wrong, but it happens

Klaas

Sent from my iPad

On Aug 23, 2011, at 8:19 PM, "Sean Turner" <turners@ieca.com> wrote:

> On 8/23/11 2:15 PM, Paul Hoffman wrote:
>> On Aug 23, 2011, at 11:04 AM, Sean Turner wrote:
>>=20
>>> At the last couple of IETF we've had a number of security WGs occur afte=
r saag.  We're considering moving saag (normally right after Thursday lunch)=
 back one slot.  Stephen and I thought we should run this by the community b=
ecause saag's been in the same slot for years.
>>=20
>>=20
>> Define "back". :-) =46rom the context, I assume that you mean "later in t=
he day", but you could also mean "back towards the beginning of the meeting"=
 (that is, Thursday morning).
>=20
> =46rom 1300-1500 Afternoon Session I to 1520-1720  Afternoon Session II.  T=
his assumes they keep the sessions slots the same.
>=20
> spt
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

From jimsch@nwlink.com  Tue Aug 23 11:52:39 2011
Return-Path: <jimsch@nwlink.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131DA21F8C6A for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdqNXE9wVrJo for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 11:52:38 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7571121F8BEF for <saag@ietf.org>; Tue, 23 Aug 2011 11:52:38 -0700 (PDT)
Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTPS id 151F52CA42; Tue, 23 Aug 2011 11:53:47 -0700 (PDT)
From: "Jim Schaad" <jimsch@nwlink.com>
To: "'Barry Leiba'" <barryleiba@computer.org>, "'Sean Turner'" <turners@ieca.com>
References: <4E53EB90.90304@ieca.com>	<EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org>	<4E53EF2E.8010500@ieca.com> <CAC4RtVAq12mEvgSRnjSOhFVwzePrtp_XAGX8ojjOefOiFk+9tw@mail.gmail.com>
In-Reply-To: <CAC4RtVAq12mEvgSRnjSOhFVwzePrtp_XAGX8ojjOefOiFk+9tw@mail.gmail.com>
Date: Tue, 23 Aug 2011 12:28:52 -0700
Message-ID: <009001cc61ca$e46abbf0$ad4033d0$@nwlink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQMDA8T6m0zVZw8DyX8yk5rSXk2dywH4HVMLAjTFAo0CuhcAdZKGVjKQ
Cc: 'Paul Hoffman' <paul.hoffman@vpnc.org>, saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 18:52:39 -0000

I was not aware there were cookies on the Friday break.

+1 on moving it back.  It was moved forward because so many people were
leaving early on Thursday to begin with.  Since we all now should assume =
we
have Friday meetings it would be a good thing

jim

> -----Original Message-----
> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf =
Of
> Barry Leiba
> Sent: Tuesday, August 23, 2011 11:22 AM
> To: Sean Turner
> Cc: Paul Hoffman; saag@ietf.org
> Subject: Re: [saag] moving saag session back one slot
>=20
> > From 1300-1500 Afternoon Session I to 1520-1720 =A0Afternoon Session =
II.
> > This assumes they keep the sessions slots the same.
>=20
> I'll be there all week, so anything works for me, modulo conflicts.
> Friday morning's fine, too, or even Friday after the cookie break.
> Cookies can help keep us cruising.
>=20
> Barry
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



From kent@bbn.com  Tue Aug 23 13:28:09 2011
Return-Path: <kent@bbn.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AB021F8C39 for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 13:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.608
X-Spam-Level: 
X-Spam-Status: No, score=-106.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kofKZNb+H2Rb for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 13:28:09 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 05AD321F8C12 for <saag@ietf.org>; Tue, 23 Aug 2011 13:28:09 -0700 (PDT)
Received: from dhcp89-089-129.bbn.com ([128.89.89.129]:49205) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Qvxb3-000Kwi-BS; Tue, 23 Aug 2011 16:29:17 -0400
Mime-Version: 1.0
Message-Id: <p06240804ca79bbb225cc@[128.89.89.129]>
In-Reply-To: <4E53EB90.90304@ieca.com>
References: <4E53EB90.90304@ieca.com>
Date: Tue, 23 Aug 2011 16:19:41 -0400
To: Sean Turner <turners@ieca.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 20:28:09 -0000

At 2:04 PM -0400 8/23/11, Sean Turner wrote:
>At the last couple of IETF we've had a number of security WGs occur 
>after saag.  We're considering moving saag (normally right after 
>Thursday lunch) back one slot.  Stephen and I thought we should run 
>this by the community because saag's been in the same slot for years.
>
>spt

Fine with me.

Since we're all supposed to hang around for Friday, a Friday
morning slot would be OK with me as well.

Steve

From stpeter@stpeter.im  Tue Aug 23 13:47:56 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4848B21F8CD3 for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 13:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.615
X-Spam-Level: 
X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPo-ZGAUUVCh for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 13:47:55 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B03DF21F8CD2 for <saag@ietf.org>; Tue, 23 Aug 2011 13:47:55 -0700 (PDT)
Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F3238415A0; Tue, 23 Aug 2011 14:51:19 -0600 (MDT)
Message-ID: <4E54123F.90208@stpeter.im>
Date: Tue, 23 Aug 2011 14:49:03 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Klaas Wierenga <klaas@cisco.com>
References: <4E53EB90.90304@ieca.com> <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org> <4E53EF2E.8010500@ieca.com> <9FF025A3-8B09-48C4-890B-BCC94DFB150F@cisco.com>
In-Reply-To: <9FF025A3-8B09-48C4-890B-BCC94DFB150F@cisco.com>
X-Enigmail-Version: 1.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2011 20:47:56 -0000

On 8/23/11 12:53 PM, Klaas Wierenga wrote:
> Hi,
> 
> That would still have been too early for abfab ;-) Anyway, pushing it
> back a bit works for me. Friday less so because people might decide
> they don't need to stay until friday..... wrong, but it happens

Perhaps the SAAG meeting is just the thing that will finally motivate
people to participate on Friday. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From klaas@cisco.com  Tue Aug 23 22:44:17 2011
Return-Path: <klaas@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685C621F8C0B for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 22:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZUys3x4FhJE for <saag@ietfa.amsl.com>; Tue, 23 Aug 2011 22:44:16 -0700 (PDT)
Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAD21F8C0A for <saag@ietf.org>; Tue, 23 Aug 2011 22:44:16 -0700 (PDT)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7O5jLdC020115; Wed, 24 Aug 2011 07:45:23 +0200
Received: from 5ed00726.cm-7-1a.dynamic.ziggo.nl ([94.208.7.38] helo=[192.168.1.108]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from <klaas@cisco.com>) id 1Qw6G8-000D9e-2M; Wed, 24 Aug 2011 07:44:16 +0200
References: <4E53EB90.90304@ieca.com> <EFDB5D26-4004-46BF-B43D-E7FEFE2CEDF4@vpnc.org> <4E53EF2E.8010500@ieca.com> <9FF025A3-8B09-48C4-890B-BCC94DFB150F@cisco.com> <4E54123F.90208@stpeter.im>
In-Reply-To: <4E54123F.90208@stpeter.im>
Mime-Version: 1.0 (iPad Mail 8L1)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <C59AA2E9-DC3D-4BA7-8273-93CA8C2767B5@cisco.com>
X-Mailer: iPad Mail (8L1)
From: Klaas Wierenga <klaas@cisco.com>
Date: Wed, 24 Aug 2011 07:46:04 +0200
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Antivirus: no malware found
X-Bayes-Prob: 0.5 (Score 0, tokens from: @@RPTN)
X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0uFo5JlSa - 6de170f9357b - 20110824 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.28
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 05:44:17 -0000

On Aug 23, 2011, at 10:59 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote=
:

> On 8/23/11 12:53 PM, Klaas Wierenga wrote:
>> Hi,
>>=20
>> That would still have been too early for abfab ;-) Anyway, pushing it
>> back a bit works for me. Friday less so because people might decide
>> they don't need to stay until friday..... wrong, but it happens
>=20
> Perhaps the SAAG meeting is just the thing that will finally motivate
> people to participate on Friday. :)

I guess I am missing something, it was my understanding that that is why abf=
ab was put on the Friday ;-)

Klaas

P.s. Fwiw I like the Friday morning slot, it gives a few more days to chase f=
or slides etc.=

From jhutz@cmu.edu  Fri Aug 26 11:39:08 2011
Return-Path: <jhutz@cmu.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E057C21F8C0D for <saag@ietfa.amsl.com>; Fri, 26 Aug 2011 11:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.535
X-Spam-Level: 
X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz7YBto1emGV for <saag@ietfa.amsl.com>; Fri, 26 Aug 2011 11:39:08 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 59E0221F8B83 for <saag@ietf.org>; Fri, 26 Aug 2011 11:39:08 -0700 (PDT)
Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p7QIeKT9025098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 14:40:22 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Sean Turner <turners@ieca.com>
In-Reply-To: <23362_1314122650_p7NI49Ux031495_4E53EB90.90304@ieca.com>
References: <23362_1314122650_p7NI49Ux031495_4E53EB90.90304@ieca.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 26 Aug 2011 14:40:18 -0400
Message-ID: <1314384018.2745.26.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: saag@ietf.org
Subject: Re: [saag] moving saag session back one slot
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2011 18:39:09 -0000

On Tue, 2011-08-23 at 14:04 -0400, Sean Turner wrote:
> At the last couple of IETF we've had a number of security WGs occur 
> after saag.  We're considering moving saag (normally right after 
> Thursday lunch) back one slot.  Stephen and I thought we should run this 
> by the community because saag's been in the same slot for years.

SAAG always used to be in the last Thursday slot.  It looks like in
IETF63, the last slot was also the first afternoon slot, and after that,
SAAG kept the first afternoon slot.

Personally, I'd be happy to see it return to the traditional
last-Thursday slot.  Of course, as some others have noted, a Friday
morning slot would work, too.