<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Arial" size="2">
<div>-----BEGIN PGP SIGNED MESSAGE-----</div>
<div>Hash: SHA1</div>
<div> </div>
<div>My apologies if you are reached by duplicates of this...</div>
<div> </div>
<div>Kind regards,</div>
<div> </div>
<div> </div>
<div>Anne-Marie Eklund Löwinder</div>
<div>Quality & Security Manager</div>
<div>.SE (The Internet Infrastructure Foundation), PO Box 7399, SE-103 91 Stockholm, Sweden</div>
<div>Phone: +46 (0)8-452 35 00/17</div>
<div>Mobile: +46 (0)734 315 310</div>
<div>E-mail: anne-marie.eklund-lowinder@iis.se</div>
<div>Web: <a href="http://www.iis.se">http://www.iis.se</a></div>
<div> </div>
<div> </div>
<div> </div>
<div>==================================================================</div>
<div> </div>
<div>Call for Papers: Securing and Trusting Internet Names, SATIN 2011</div>
<div> </div>
<div>==================================================================</div>
<div> </div>
<div>When: Monday 4 & Tuesday 5 April 2011</div>
<div> Note that IETF 80 is in Prague, Czech Republic, the previous week</div>
<div> </div>
<div>Where: National Physical Laboratory (NPL)</div>
<div> Teddington, London, UK</div>
<div> </div>
<div>Timetable: Submissions due: Sun 23 Jan 2011, 11:59 PST</div>
<div> Notification of Acceptance: Wed 23 Feb 2011</div>
<div> Final Papers Due: Mon 15 Mar 2011</div>
<div> </div>
<div>Overview</div>
<div>========</div>
<div> </div>
<div>The domain name system, on which the Internet entirely relies, has always been inherently insecure. Spoofing of IP source addresses means that any wide area UDP protocol (such as DNS) can be forged. Cache poisoning attacks can be made less likely but not
prevented altogether.</div>
<div> </div>
<div>ISPs, or others who can intercept traffic, can redirect end users to sites of their choosing. Users can choose (or have forced upon them) DNS services that suppress access to sites for policy reasons.</div>
<div> </div>
<div>DNSSEC, which addresses some of these issues, has been under development since late last century, but the July 2010 signing of the root (and the commitment of many top level domains to timetables for deployment) signal that widespread deployment may finally
be coming to pass.</div>
<div> </div>
<div>However, even at the current scale of deployment, implementation issues are creating unexpected levels of traffic, and that's without the bad guys making any contribution. Meanwhile DNSCURVE is being promoted as a lightweight method of securing the links
to and between name servers, which addresses some, but by no means all, of the security issues.</div>
<div> </div>
<div>DNSSEC is also being seen by some as a distributed, secure, key distribution system, which could support new applications, or replace existing mechanisms for establishing trust in the identity of endpoints.</div>
<div>Others merely see it as a way of defeating marketers who want to inject targeted advertising into browser sessions. But how effective will these ideas be if we continue with our existing APIs and stub resolvers?</div>
<div> </div>
<div>There are significant issues with DNS besides just its integrity. DNS services can be used to amplify denial-of-service attacks to create very substantial traffic flows. Malware has also been using the DNS for rendezvous arrangements, and has avoided countermeasures
by exploiting the DNS system through ``fluxing'' and other techniques.</div>
<div> </div>
<div>There are also signs of a ``tragedy of the commons'' as legitimate companies fill the DNS with large numbers of names, or set low TTLs, to give a performance ``edge''. Meanwhile, some applications pre-fetch DNS answers, with little heed to the impact on
the infrastructure.</div>
<div> </div>
<div>This latter technique raises privacy issues, as indeed does the proposal to ``leak'' partial identities of requestors who contact recursive resolvers, with the aim of providing different answers to machines in different blocks of address space.</div>
<div> </div>
<div>All of this makes DNS, once amongst the most boring of topics, into one of the more exciting, and this workshop into a timely event.</div>
<div> </div>
<div>Topics</div>
<div>======</div>
<div> </div>
<div>SATIN aims to provide a forum for academic work on the security of the DNS alongside industry presentations on practical experiences in providing name services.</div>
<div> </div>
<div>The intent is to make this a workshop that will expose the academics to the real problems that industry is encountering, and to show industry what academia has to offer them. To improve the flow of information, presentations will be restricted to 15 minutes
with 15 minutes of general discussion to follow.</div>
<div> </div>
<div>Submissions must be made under either an ``academic'' or ``industry'' label (relating entirely to the content rather than the affiliations of any author), because the two types will be judged by different standards.</div>
<div> </div>
<div>Academic work will be viewed as an ``extended abstract'' and should aim to meet the general standard for acceptance into normal conferences in the field. However, since this is a workshop, early results and initial ideas are welcomed.</div>
<div> </div>
<div>Industry submissions should be relevant, insightful, and technical, and should provide information that cannot be gleaned from reading sales brochures or manuals.</div>
<div> </div>
<div>In all cases, real-world operational, implementation, and experimental results will be preferred, and these results should inform the DNS protocol development process wherever relevant or possible.</div>
<div> </div>
<div>Topics of interest include but are not limited to:</div>
<div> </div>
<div> Attacks on naming services</div>
<div> DNSSEC</div>
<div> DNSCURVE</div>
<div> Alternative methods of securing name services</div>
<div> APIs for DNS resolvers</div>
<div> Using DNS as a platform for other applications</div>
<div> Denial of service and the DNS</div>
<div> Malware and the DNS</div>
<div> DNS caching on the modern Internet</div>
<div> Privacy and the DNS</div>
<div> Application behaviour and the DNS</div>
<div> Security economics of naming services</div>
<div> Passive DNS</div>
<div> Operational experience</div>
<div> Measurement studies</div>
<div> New threats and challenges</div>
<div> </div>
<div>Questions regarding whether a topic would be suitable are welcome and should be sent to the programme chair, richard.clayton AT npl.co.uk</div>
<div> </div>
<div>Workshop Organizers</div>
<div>===================</div>
<div> </div>
<div>Programme Chair:</div>
<div> Richard Clayton NPL and University of Cambridge</div>
<div> </div>
<div>Programme Committee:</div>
<div> </div>
<div> David Dagon Georgia Tech</div>
<div> Ben Laurie Google</div>
<div> Anne-Marie Eklund Löwinder .SE (The Internet Infrastructure</div>
<div> Foundation)</div>
<div> Dan Massey Colorado State University</div>
<div> Douglas Maughan Department of Homeland Security</div>
<div> Andrew Moore University of Cambridge</div>
<div> Jose Nazario Arbor Networks</div>
<div> Roberto Perdisci University of Georgia</div>
<div> Dave Piscitello ICANN</div>
<div> Paul Vixie ISC</div>
<div> Nicholas Weaver ICSI & UC Berkeley</div>
<div> Jonathan Williams NPL</div>
<div> </div>
<div>Submissions</div>
<div>===========</div>
<div> </div>
<div>All submissions must be in IEEE two column format and no longer than eight (8) 8.5'' x 11'' pages, including figures, tables, and references.</div>
<div> </div>
<div>That means that the text must be set in two columns in 10 point type on</div>
<div>12 point (single-spaced) leading, with the text block being no more than 7.2'' wide by 9.6'' deep. Author names and affiliations should appear on the title page. The use of LaTeX and the IEEEtrans.cls file to create submissions is very strongly encouraged:</div>
<div> <a href="http://conferences.npl.co.uk/satin/format.html">http://conferences.npl.co.uk/satin/format.html</a></div>
<div> </div>
<div>Submissions must be submitted in PDF format via the SATIN 2011 website:</div>
<div> <a href="http://www.easychair.org/conferences/?conf=satin2011">http://www.easychair.org/conferences/?conf=satin2011</a></div>
<div> </div>
<div>Simultaneous submission of the same work to multiple venues, submission of previously published work, or plagiarism, is dishonest and/or fraudulent and action may be taken if this occurs. Note, however, that we expect that many papers accepted for SATIN
will eventually be extended as full papers suitable for presentation at other conferences.</div>
<div> </div>
<div>About the National Physical Laboratory</div>
<div>======================================</div>
<div> </div>
<div>The National Physical Laboratory (NPL) is one of the UK's leading science and research facilities. It is a world-leading centre of excellence in developing and applying the most accurate standards, science and technology available. NPL occupies a unique
position as the UK's National Measurement Institute and sits at the intersection between scientific discovery and real world application. Its expertise and original research have underpinned quality of life, innovation and competitiveness for UK citizens and
business for more than a century.</div>
<div> </div>
<div>NPL is collaborating with the University of Cambridge in a three year programme to develop robust and accurate measurements of Internet security mechanisms. Measuring and understanding the deployment of DNSSEC and other trust mechanisms for Internet names
is a key part of this ongoing programme.</div>
<div> </div>
<div>More at: <a href="http://conferences.npl.co.uk/satin/">http://conferences.npl.co.uk/satin/</a></div>
<div> </div>
<div> </div>
<div> </div>
<div>-----BEGIN PGP SIGNATURE-----</div>
<div>Version: 9.8.3 (Build 4028)</div>
<div>Charset: utf-8</div>
<div> </div>
<div>wj8DBQFNLA2EpdzwAUKxz5QRApMTAKCw+LU+IkJrVpbZoURHJOp7Fe+LdQCg9e5P</div>
<div>xd83uTU4KXuznaqFK1s2vp8=</div>
<div>=wHcr</div>
<div>-----END PGP SIGNATURE-----</div>
<div> </div>
<div> </div>
</font>
</body>
</html>