Subject: experiments in the ietf week

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Mar 2008 08:01:43 -0400

I really enjoyed the IPv6 experiment, thanks to everyone who was
involved. Obviously, the experiment and a couple of other recent things
(like moving to AMS service) made things move forward in a number of
different places, our own computers, IETF computers, various people's
own and company sites, etc. Perhaps the most notable achievement here
was ipv6.google.com. That was really great, thank you Google!

But the experiment was useful also in other ways, not only as an
operational/deployment action. The two experiments that I attended
(NANOG and IETF) have changed my and maybe other people's opinions too
on some of the technical issues. I think it helps us see clearer on what
are the things that the IETF needs to do in this space. We will see
follow-ups on this.

We should also implement future IPv6 experiments and network deployments.

But why I'm really sending this e-mail is to suggest that IPv6 might not
be the only topic for such future efforts. Here's a challenge for the
RAI folks: What about SIP, as in every plenary participant making SIP
calls to each other. Doable?

Challenge for our IT folks: Internationalized Internet Drafts, including
file names. Doable?

ietf.pana in addition to ietf.1x. Doable?

Etc

Jari

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Mar 2008 11:11:00 -0400

On Mar 14, 2008, at 8:01 AM, Jari Arkko wrote:

> Challenge for our IT folks: Internationalized Internet Drafts,  
> including file names. Doable?

It's doable, no doubt. The next question is whether this is actually  
smart.

The Finnish character set is something I can deal with, although my  
keyboard differs from a Finnish one, making typing the name in  
something I would have to think about. I personally don't speak or  
read any of the languages that use derivatives of the Han character  
set, and will find it difficult to read or point you to a draft with  
a Japanese or Chinese name.

I'm inclined to wonder what problem you're solving and what problem  
you're trading that one for. I imagine it is that you would like to  
be able to use Finnish words in draft monikers or to post internet  
drafts in Finnish. I would counsel you to be careful what you wish  
for. If the important thing is global communication among engineers,  
this might take you in a direction you didn't really intend.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Mar 2008 17:06:15 +0100

> this might take you in a direction you didn't really intend.

Well,

two wishes that come up frequently are really modest:

- the ability to provide properly spelled contact information

- the ability to use non-ASCII characters in specification text that 
deals with I18N

Of course to make this useful, it would need to be accepted in RFCs as well.

BR, Julian

---

From: Richard Barnes <[email-masked]>
Date: Fri, 14 Mar 2008 17:38:28 -0400

As some of you might have noticed, some GEOPRIV participants ran a small 
experiment, using the IETF network as a base for location-based 
services.  We had a few folks try it, and learned a lot, but three main 
things:

1. Interworking with the IETF NOC was really pleasant (Thanks, guys!)

2. James Winterbottom's location server worked really well and 
integrated easily with the IETF network.

2. The client software I wrote successfully interworked with the 
location server in test cases, but failed badly in real life

Overall, prototyping these technologies was a really positive experience 
for us, one that I would recommend to other WGs.  We're certainly 
planning on making another effort at it in Dublin!

--Richard

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 15 Mar 2008 02:58:13 +0100

> ietf.pana in addition to ietf.1x. Doable?

I would like to second Jari's statement. To follow up to Joel's  
comment at the technical plenary on the issue of lack of operators - I  
believe that if the designers and vendors of some of the IETF  
standards better understood how they actually worked in real use cases  
and tried to deployment - we might find a lot more deployment issues  
earlier.

I am all for it.

- kurtis -

---

From: Mark Andrews <[email-masked]>
Date: Sun, 16 Mar 2008 12:16:10 +1100

Enable DNSSEC validation on the network's servers.  At a
	minimum make them DNSSEC transparent.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Mar 2008 19:44:12 +0100

> 	minimum make them DNSSEC transparent.

Is there any software out there for common OSes that does something  
useful with this?

A more interesting experiment would be to do away with SSL for a bit  
and use IPsec instead. But I think we're far from being finished with  
IPv6. Nearly all IETF mailinglists are still hosted on IPv4-only  
servers, to name just one issue.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 16 Mar 2008 21:42:19 +0100

Hi Iljitsch,

On 2008-03-16 19:44 Iljitsch van Beijnum said the following:
... Nearly all IETF mailinglists are still hosted on IPv4-only  
> servers, to name just one issue.

Umm...  At this time, most IETF mailing lists are hosted on
mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled.  
(The numbers I have for active WGs are that 90 out of 120 lists
are hosted on ietf.org).  I can't really reconcile that with 
your statement above.  Could you expand on your thoughts in
this respect?

	Henrik

---

From: Mark Andrews <[email-masked]>
Date: Mon, 17 Mar 2008 10:30:38 +1100

> Is there any software out there for common OSes that does something  

	Yes.  It is also useful in its own right by protecting the
	down stream clients.

	Note: DNSSEC validation in the recursive resolver is stage 1
	of DNSSEC deployment.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Mar 2008 18:46:06 -0600

At Sun, 16 Mar 2008 19:44:12 +0100,
Iljitsch van Beijnum wrote:
> and use IPsec instead. 

Why would this be either interesting or desirable?

-Ekr

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Mar 2008 22:59:52 +1100

> Why would this be either interesting or desirable?

	DNSSEC transparency is important for machines on the IPv6
	only net trying to validate answers off IPv4 only servers.

	Validatation is useful for protecting the resolvers themselves.

	Mark

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Mar 2008 05:34:13 -0700

At Wed, 19 Mar 2008 22:59:52 +1100,
> 	Validatation is useful for protecting the resolvers themselves.

I was referring to Iljitsch's suggestion about SSL and IPsec, not
the suggestion about DNSSEC.

-Ekr

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 16:31:03 +0200

Eric,

> the suggestion about DNSSEC.
Yes. FWIW, I don't think that would be interesting. DNSSEC experiments
by itself might be interesting, particularly if they could be combined
with some movement in getting the root signed.

Jari

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Mar 2008 17:10:10 +0200

Hi Jari,

we have already started todo the same with other protocols in GEOPRIV. See
http://www.ietf.org/mail-archive/web/geopriv/current/msg05453.html
http://www.ietf.org/mail-archive/web/geopriv/current/msg05468.html
http://www.ietf.org/mail-archive/web/geopriv/current/msg05472.html

Ciao
Hannes

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 20:37:36 +0200

Yes, that's excellent. In particular, I like your approach of making
things available for the IETF crowd, delivered by the folks who are also
delivering the standards.

Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Mar 2008 15:17:56 +0100

> Why would this be either interesting or desirable?

SSL is vulnerable to more attacks than IPsec and IPsec is more general  
than SSL. As such it would be good if we could have IPsec deployment  
similar to SSL deployment, similar to how it would be good to have  
IPv6 rather than IPv4 deployment, so a similar experiment could be  
useful in showing what if any the reasons are we're still stuck with  
the inferior SSL/TLS technology.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Mar 2008 15:23:00 +0100

> your statement above.  Could you expand on your thoughts in

IETF discussion list (and several others):

Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20])

v6ops list:

Received: from psg.com (psg.com [IPv6:2001:418:1::62])

This is excellent progress since the last time I checked somewhere  
last year, which was the basis for my statement.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marc Manthey <[email-masked]>
Date: Mon, 24 Mar 2008 16:18:47 +0100

> last year, which was the basis for my statement.

hello ipv6  peoples, sorry for crossposting

how can i use ipv6 from my machine ?

using leopard 10.5.2. mail ?

my endpoint is 2001:6f8:1051:0:20d:93ff:fe79:f1e

thought its automatic :-P

thanks

marc

-- 
"Wer also allgemeine Aufklärung verbreitet, verschafft zugleich eben  
dadurch allgemeine wechselseitige Sicherheit, und allgemeine  
Aufklärung und Sicherheit machen Fürsten und Staaten entbehrlich. Oder  
wozu braucht man sie sodann?"

Marc Manthey -  Hildeboldplatz 1a
D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
jabber :[email-masked]
blog : http://www.let.de
ipv6 http://www.stattfernsehen.com/matrix
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Mar 2008 12:48:54 -0400

> thought its automatic :-P

I think you just need to make sure that the servers you use for  
inbound and outbound mail are reachable on IPv6 and have AAAA records  
published in the DNS.

Joe

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Mar 2008 10:28:10 -0700

These claims are meaningless to me. Transport and network layer security have distinct objectives and purposes. They are not replacements or interchangeable in any sense.
 
If you beleive that there is an attack that SSL is vulnerable to you should bring it up in TLS. 

In general the higher up you climb in the stack, the better the security you can offer. In order to provide application layer security in a correctly layered network model you have to apply security at a layer that the application talks to, that means either the messaging (S/MIME/PGP/S-HTTP/SHEN) or the transport layer (SSL, DNS). SSL provides confidentiality, integrity and authentication. If you want useful non-repudiation you need to move up to the message layer.
 
The advantage of going lower in the stack is to gain greater generality. IPSec allows every communication to be protected with a basic level of security in a manner that is transparent to the applications. As such it allows certain aspects of confidentiality and integrity to be supported but cannot inform application logic.
 
Security today is all about layered security. Ideally an email transaction would have at least three layers of security:
 
1) IPSec
 
2) TLS (between SUBMIT client to server, STP server to server, POP3/IMAP server to client)
 
3a) DKIM + S/MIME/PGP
   Each message should be DKIM signed as a matter of course
   If the recipient advertises an acceptable encryption key and protocol this should be used to encrypt the message
 
3b) DRM attachments
   If a message has attachments (e.g. Word, HTML Archive, etc) these should be subject to lifecycle-long data level protection.

The most critical layer here is layer 3b which is unfortunately the one we do not have today. At the moment 2014 is the earliest I can see there being the hope of an unencumbered data level security specification. 
 
I do not see any value in 'turning off' upper layer security enhancements as an experiment. 
 
________________________________

From: [email-masked] on behalf of Iljitsch van Beijnum
Sent: Mon 24/03/2008 10:17 AM
To: Eric Rescorla
Cc: Mark Andrews; Jari Arkko; IETF Discussion; Kurt Erik Lindqvist
Subject: Re: experiments in the ietf week

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Mar 2008 10:49:18 -0700

Enough, already.

If we are going to have experiments in IETF week then lets do the thing right and have a process. In particular -

Proposer MUST write an Internet Draft prior to the experiment stating:

1) Purpose - the information to be obtained
2) Method - what it to be done
3) Resources - what will be required of the organizers
4) Expected outcomes - what it is expected that the experiment will tell us
5) Forcing functions - if the experiment is intended to be a forcing function for infrastructure deployment
6) Justification for spending the time and effort

Proposer MUST write up the results of the experiment and submit to the RFC editor afterwards

I don't think there is much point in just running the same experiment every time. It will become a tradition and the last thing this institution needs is more traditions that have outlived their utility cluttering up the process. 

And we should probably have a separate mailing list to discuss such proposals.

IPv6 Next Steps

The Philadelphia IPv6 outage tested one specific aspect of the transition - is there an IPv6 network on the other side to connect to in due course, is it possible to run a pure IPv6 network?

I think that that is one useful data point to test but not the only significant data point. In particular the biggest problem we have is the exhaustion of IPv4 space. The most important network test to make in my view is whether current generation machines work acceptably on an IPv6+NATv4Share connection for typical end user tasks.

By 'acceptably' I mean ZERO-click administration. No configuration tweaks whatsoever. If a product does not run out of the box it has failed.

Secure WiFi Connection

I would like to see some demonstration of the fact that the default WiFi configuration on all existing platforms provides zero protection against an 'evil twin' WiFi attack. Using WPA protection has little value unless you have mutual authentication. The current specs don't allow for that.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Mar 2008 19:58:48 +0200

Phillip, Iljitsch,
 
> should bring it up in TLS.

I think Iljitsch meant that TLS cannot protect against TCP
vulnerabilities, such as spoofed connection resets. This is obviously
well known.

The upside of TLS has of course been that its been extremely easy to
deploy. That's the experiment the planet has been running for the last
decade, and I think the results speak for themselves ;-)

Now, if we had a proposal that turned IPsec into as easily deployable
between random clients and known servers as TLS, I would be interested
in a new experiment! But I did not see a proposal for that yet. Maybe
time for that draft that Phillip suggested in another thread, Iljitsch?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Mar 2008 20:02:28 +0200

Phillip,

> write an Internet Draft prior to the experiment,
>

+1

> *IPv6 Next Steps*
>
> The Philadelphia IPv6 outage tested one specific aspect of the
> transition - is there an IPv6 network on the other side to connect to
> in due course, is it possible to run a pure IPv6 network?
>
> I think that that is one useful data point to test but not the only
> significant data point. In particular the biggest problem we have is
> the exhaustion of IPv4 space. The most important network test to make
> in my view is whether current generation machines work acceptably on
> an IPv6+NATv4Share connection for typical end user tasks.
>

I agree, and I think that's been the focus of many folks working in this
space. Lets see what we can come up with for Dublin.

> By 'acceptably' I mean ZERO-click administration. No configuration
> tweaks whatsoever. If a product does not run out of the box it has failed.
>
> *Secure WiFi Connection*
>
> I would like to see some demonstration of the fact that the default
> WiFi configuration on all existing platforms provides zero protection
> against an 'evil twin' WiFi attack. Using WPA protection has little
> value unless you have mutual authentication. The current specs don't
> allow for that.
>
Is there something missing from ietf.1x ssid support that we've had for
years? It uses IETF standards, too...

Jari

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Mar 2008 15:22:42 -0400

Phillip:

Have you tried the SSID at the IETF meetings that is configured to make
use of 802.1x?

Russ

At 01:49 PM 3/24/2008, Hallam-Baker, Phillip wrote:

Secure WiFi Connection

I would like to see some demonstration of the fact that the default WiFi
configuration on all existing platforms provides zero protection against
an 'evil twin' WiFi attack. Using WPA protection has little value unless
you have mutual authentication. The current specs don't allow for
that.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Mar 2008 18:08:52 -0700

Well I would submit that there is a major problem there on the security usability front.

Don't make me think. My tolerance for network configuration is vastly greater than the typical user. 

This has to all just work, just like my Apple Mac did on the home network the day I bought it. Not like my Apple Mac this morning which for some unaccountable reason no longer sees the machines it acknowledged before and gives me precisely zero information to allow me to determine the cause.

From: Jari Arkko [mailto:[email-masked]]

Jari

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Mar 2008 18:18:58 -0700

I am willing to have a go at it next time round but only if I have some idea what I am expected to have on my machine and what authentication indicata I am to expect.

As it stands there is no way for me to evaluate an authentic or inauthentic experience. I don't know what authentic looks like. I have no trust anchor.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Mon 24/03/2008 3:22 PM
To: Hallam-Baker, Phillip
Cc: IETF Discussion
Subject: Re: Write an RFC Was: experiments in the ietf week
 
Phillip:

Have you tried the SSID at the IETF meetings that is configured to make use of 802.1x?

Russ

	Secure WiFi Connection

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 25 Mar 2008 03:30:58 +0100

On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote:

> I am willing to have a go at it next time round but only if I have  
> some idea what I am expected to have on my machine and what  
> authentication indicata I am to expect.
>
> As it stands there is no way for me to evaluate an authentic or  
> inauthentic experience. I don't know what authentic looks like. I  
> have no trust anchor.

This email message sent to me was enough of a trust anchor to use  
802.1x. Specifically as "the instructions" are the same as IETF-70 and  
previous meetings.

http://www.ietf.org/mail-archive/web/71attendees/current/msg00154.html

Sure, the mail was not signed, but I also asked a friend at the  
meeting "what he used". And as we both had the same instructions, we  
trusted that. If we wanted to, we could have asked someone actually  
running the network, but we did not feel we had to.

    Patrik

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Mar 2008 05:44:09 -0700

What I am trying to get at here is the problem of usability. Security is no use to me to stop Internet crime if everyone either turns it off or is unable to use it. The layered model is a big problem here because the lower layers abstract away the user. There is no user interface, there are no user oriented use cases and as a result the protocols fail to deliver the necessary information to the upper layers to allow the user to make sure that they are safe.

"3. Do Not Verify Server Cert and we won't verify yours :)"

OK, it is a good idea to turn on confidentiality and integrity. But this is not something that is really going to help solve the evil twin WiFi attack out in the general population. Its a pretty insidious attack as the effects are localized and we can't measure the frequency. 

If we are going to do experiments then we should be providing feedback to the relevant parties. Pointing out to the IEEE that WiFi security fails basic principles of security usability - the user does not have sufficient information to distinguish the intended connection from the twin - would be a useful purpose.

Of course, going round pointing out this sort of thing to others would make it incumbent on us to fix the same problems in our protocols.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Mon 24/03/2008 10:30 PM
To: Hallam-Baker, Phillip
Cc: Russ Housley; IETF Discussion
Subject: Re: Write an RFC Was: experiments in the ietf week

    Patrik

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 25 Mar 2008 09:05:26 -0400

Phillip does have a point regarding 802.1x authentication, which is
typically used to authenticate the user to the service, and not vice
versa. Conceivably a person could set up an "evil" access point that
advertises the same beacon as the official access points, and has
802.1x enabled to accept the same shared user name and password (which
is also well publicized).

One way that could make this much more secure from the user viewpoint
would be for every attendee to receive an individual 802.1x user name
and password, perhaps printed on the back of their name tag.
Presumably an "evil" access point would not have access to these names
and passwords, so users can be sure that they are attaching to an
official access point. But as this would create much more work for the
NOC and admin staff, I'm not advocating we do that.

Cheers,
Andy

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Mar 2008 14:32:27 +0100

> time for that draft that Phillip suggested in another thread,  

I'm afraid that won't work because of scheduling conflicts if I wanted  
to present such a draft to the appropriate SEC area wg...

A quick s/TLS/IPsec/g isn't realistic, but I would certainly be  
interested in seeing one or more IETF services use some kind of IPsec  
protection in order to see if this is workable in practice. There are  
APIs that allow applications to set this up on a per-application  
basis, unless I'm mistaken.

And yes, the issues I referred to are DoS and TCP spoofing. These can  
only be protected against at the  network level. Encryption can, and  
therefore, probably should, be handled at the transport level. (That  
is not to say that authentication at the network level is entirely  
useless, just that it can protect against more stuff at the network  
level.)
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Mar 2008 07:25:34 -0700

Yes, a security experiment is not so interesting without an attack.
 
I would like an evil twin access point to be set up with a cert that says 'evil twin' and measure how much traffic goes through it. This is frequently done at BlackHat albeit not necessarily in a manner that complies with human subjects criteria.
 
Its not much of a security experiment if you only measure whether people can deploy it.

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tue 25/03/2008 9:05 AM
To: Patrik Fältström
Cc: Hallam-Baker, Phillip; IETF Discussion
Subject: Re: Write an RFC Was: experiments in the ietf week

Cheers,
Andy

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 25 Mar 2008 08:10:56 -0700

...
> And yes, the issues I referred to are DoS and TCP spoofing. 
> These can only be protected against at the  network level. 

What are your thoughts on DTLS's DoS and spoofing protection?

-d

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 08:11:37 -0700 (PDT)

> basis, unless I'm mistaken.

I believe you're mistaken. There is much work that needs to be done in this
area before it will be possible for applications to use IPsec this way. The
good news is that the BTNS WG is actively working to fill this gap; see

    An abstract interface between applications and IPsec (draft-ietf-btns-abstract-api-01.txt)
    IPsec Channels: Connection Latching (draft-ietf-btns-connection-latching-06)
    IPsec Application Programming Interfaces (draft-ietf-btns-c-api-03)

But even if this work is successful it will be many years before the necessary
support is sufficiently widely implemented and deployed to be usable, assuming
that ever happens.

				Ned

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Mar 2008 15:59:54 -0700

At Mon, 24 Mar 2008 15:17:56 +0100,
> the inferior SSL/TLS technology.

One of the true joys of the IETF is watching people explain why 
their favorite technology is superior to the technology people
have actually chosen to use.

Both IPsec and SSL have applications where they are the appropriate
choice. I don't think there's a lot of point in going into them in
detail. But given that the attacks you're mentioning are frankly
irrelevant in 99.9% of cases (btw, I know what TCP spoofing is, but
it's not relevant for TLS, because the application should be looking
at the cryptographic identity, not the transport layer identity), the
notion that we should tear out most of the application layer security
infrastructure to accomodate your notions of architetural
appropriateness strikes me as extremely dubious.

-Ekr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Mar 2008 13:25:20 +0100

> What are your thoughts on DTLS's DoS and spoofing protection?

Looks like this is mostly similar to IPsec except that the port  
numbers rather than SA is used to demultiplex so the anti-DoS  
protection that the sequence number / anti replay counter provides is  
less than with IPsec. Also, a quick read of RFC 4347 doesn't reveal  
any advice regarding the initial value of the sequence number, so  
applications may start at 0 or 1 and make this easy to guess.

I assume this means in the future we'll be running TCP over DTLS over  
UDP...

The part that I don't like about DTLS is the way it avoids dealing  
with MTU issues and pretty much tells people to do PMTUD for IPv4 for  
UDP even though in theory this is extremely hard to get to work and  
practice it never works.

I wonder what kind of security mechanisms we would come up with if we  
got to do all of this again from scratch but with the benefit of  
hindsight. I'm pretty sure it wouldn't be TLS+IPsec+DTLS. And if I  
could go back in time and make sure the person who invented the DF bit  
wouldn't make it to work that day, I wouldn't hesitate to do that.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2008 06:36:31 -0700

At Wed, 26 Mar 2008 13:25:20 +0100,
Iljitsch van Beijnum wrote:
> less than with IPsec.

You really need to describe the attacks you're concerned about, rather
than handwaving. After reading this a few times, I *think* you're
claiming the following:

    An attacker who knows the host-port quartet of a DTLS association
    can send send completely bogus but correctly formatted packets to
    one side and therefore force them to attempt to decrypt the
    record. This amounts to a computational DoS attack. Whereas, by
    contrast, mounting this attack on IPsec requires knowing the SPI,
    which presumably requires being on path, since it's random.

Do I have this right?

If so this is a pretty feeble attack. 

- Modern cryptographic implementations are extremely fast. For
  comparison the MacBook Air I'm typing this on will do order 10^6
  HMAC-MD5s/second on 64-byte packets.  So, to consume all my
  resources would require order 10^8 bits per second, which is a
  pretty serious packet-based DoS ittack on many contexts.
- Even mounting this attack requires knowing both host/port
  quartets. With DTLS, as with TLS, the responder/server's
  port is typically known whereas the initiator/client's port
  is random or pseudorandom. This creates some barrier to
  mounting this attack.
- A very similar attack is available on IKE (and DTLS, of
  course). In order to block DoS attacks, both handshakes
  offer the option of doing a "stateless cookie" exchange,
  in which the responder gives the initiator a token which 
  can be used to verify the client's next message (which must
  of course contain the token). But the way these tokens are
  generates is to have the responder compute a cryptographic
  MAC/hash over some input data. So an attacker can force
  any random IKE or DTLS stack to do as many digest operations
  as it wants.

> UDP even though in theory this is extremely hard to get to work and  

You've misunderstood the purpose of DTLS, which is to replicate
the semantics of UDP to the greatest extent possible, consistent
with also provided an association-based security system. Accordingly,
since UDP-based applications have to deal with PMTU, they have to
do so with DTLS as well.

-Ekr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Mar 2008 15:01:21 +0100

>  pretty serious packet-based DoS ittack on many contexts.

This is a bogus argument. Implementations are always inferior to  
optimistic performance claims and although maybe your laptop CAN do  
that that doesn't mean you WANT it to spend its cycles and battery  
power on that. (Or maybe you do, but I certainly don't.)

>  is random or pseudorandom. This creates some barrier to

The DTLS design to reuse the port numbers is not unreasonable as long  
as DoS against CPU resources isn't a concern. But not using random  
sequence numbers, like TCP has been doing since the dawn of time, is a  
serious oversight because it costs next to nothing and buys a lot of  
protection against spoofing attacks.

>  any random IKE or DTLS stack to do as many digest operations

That doesn't make sense. For such a cookie to provide additional  
benefit over the normal HMAC, the value in the next message must be  
present in that next message in the clear so the number of crypto  
operations required is equal to the number of valid packets, which  
isn't under the control of an attacker, rather than the total number  
of packets (like a HMAC), which can be inflated by an attacker.

> since UDP-based applications have to deal with PMTU, they have to

I wasn't offering a critique of DTLS' purpose, but rather, of its  
operation. Path MTU discovery for IPv4 for UDP can only work if  
applications can adjust their packet sizes arbitrarily, which they  
often can't, or at least not in a reasonable way. Perpetuating this  
broken idea in DTLS was a mistake.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2008 07:32:41 -0700

At Wed, 26 Mar 2008 15:01:21 +0100,
Iljitsch van Beijnum wrote:
> optimistic performance claims 

What do you mean "optimistic performance claims"? I ran
"openssl speed". That's actually a pretty good reflection
of what the performance of SSL implementation will be.

> and although maybe your laptop CAN do  

No, I don't, but once again you're totally missing the point:
the amount of bandwidth you'd need to perform a computational
DoS attack on the symmetric part of the system is so high
that it's basically a bandwidth-based DoS in itself.

> protection against spoofing attacks.

1. TCP has *not* used random sequence numbers since the dawn of
   time. On the contrary, they have been historically extremely
   predictable, hence RFC 1948 (though of course the techniques
   predate it.) And the reason that it now uses random sequence
   numbers is to block attacks much more severe than the ones
   you're describing here.
2. You're using the term "spoofing" in a way that's misleading.
   DTLS packets injected into the network by an attacker who
   does not have possession of the keying materal are quite
   correctly rejected by the DTLS stack. It's just that they
   are cryptographically verified first without being rejected
   out of hand.
3. As you say, it *is* cheap, but in keeping with our general
   principle of not improving TLS but just making it datagram
   capable, we decided to stick with TLS's 0-based sequence
   numbers.

Not to put too fine a point on it, I think this proposed attack
s basically irrelevant. I have not heard of any situation in
which anyone has mounted DoS attacks on machines by forcing
them to repeatedly perform cryptographic packet verifications
(most likely since it's so lame) and in the unlikely case that
that were to happen, we could always quickly roll out an
extension to randomize the sequence numbers.

> of packets (like a HMAC), which can be inflated by an attacker.

You might want to refamiliarize yourself with how these systems
actually work.

Let's take IKE as an example (though the situation is the same in
DTLS). Here's the initial exchange from RFC 4306 S 2.6.:

       Initiator                          Responder
       -----------                        -----------
       HDR(A,0), SAi1, KEi, Ni   -->

                                 <-- HDR(A,0), N(COOKIE)

       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

                                 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

So, whenever the responder gets *any* initial packet from
a plausible counterparty (and this is clearly in control of the
attacker), it has to compute a cookie. And how is that done?
Scrolling further down S 2.6, we get some advice.

   A good way to do this is to set the responder cookie to be:

      Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

So, precisely as I said, an attacker can force the responder
to compute as many hashes as he chooses.

> broken idea in DTLS was a mistake.

You could call it that. I call it appropriate layering.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Mar 2008 07:35:00 -0700

At Wed, 26 Mar 2008 07:32:41 -0700,
> of what the performance of SSL implementation will be.

That said, there is a dependency on cipher suite. So, RC4-MD5
is not too much slower than HMAC-MD5 alone. By contrast, 
AES-SHA1 is maybe 4x slower. OTOH, I only was counting the 
size of the TLS records themselves, so when you add the TCP
and UDP headers, the bit rate is probably twice as high.

-Ekr