headers
joel jaeggli | 1 Jul 2012 18:39

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

On 6/30/12 6:04 AM, Yaron Sheffer wrote:
> This is highly speculative, highly subjective of course, but I don't 
> think an API would have gotten IPsec to dominate the world. On the 
> contrary, app developers are happy to focus on their own stuff and not 
> spend too much time on security.
>
> From an application point of view, TLS has two important advantages 
> over IPsec (IKE really):
>
> - The well known advantage is that TLS is usually happy to 
> authenticate only the server, leaving client auth to the application. 
> This makes deployment so much easier.
>
> - The dirty little secret is that many people do not even authenticate 
> the server. In the cloud computing space (today's Wild West?) I have 
> seen several cases of popular tools that just don't bother, with no 
> apparent justification that I can think of. Another example is EAP-TLS 
> configuration on Windows.
offhand I'd say that's the case for most smtp mta implementations as well...
> I'm not trying to imply that TLS is insecure. But clearly if 
> widespread deployment is a goal (and it should be, otherwise why 
> bother writing RFCs) you should let deployers/developers choose their 
> appropriate level of security. In some cases, sadly, they will make 
> the wrong choice.
>
> Thanks,
>     Yaron
Permalink | Reply | 1 comment |
headers
Joe Touch | 2 Jul 2012 08:00
Picon
Favicon

Re: Should security requirements be MUST?


On Jun 30, 2012, at 5:18 AM, Alan DeKok <aland <at> deployingradius.com> wrote:

> Joe Touch wrote:
>> It would be useful to know if that actually sent packets on the wire
>> (not in-memory measurements),
> 
>  If your best counter-argument is to assume I'm a complete idiot, that
> explains why your tests only get 50Mbps.

1500 byte blocks, measured per core, and that was IP level.

>  For more reality-based counter-arguments, see the "high performance
> SSH" patches.  They're also getting better than 900Mbps with crypto on
> commodity hardware.

8 cores, different alg (CTR, not CBC, which is weaker), and 8 kb blocks at the "app" level, not 1500.

That won't protect TCP.  To do that, you need to encrypt at the block of a TCP or IP packet, which is a lot
costlier.  And burning 8 cores is a lot more costly than one $10 crypto chip, and prevents use of outboard TCP
and IP hardware assist.

Joe
Permalink | Reply | 0 comments |
headers
Joe Touch | 2 Jul 2012 08:04
Picon
Favicon

Re: Should security requirements be MUST?


On Jun 29, 2012, at 5:43 PM, Eric Rescorla <ekr <at> rtfm.com> wrote:

> 
> 
> On Jun 29, 2012, at 17:11, Joe Touch <touch <at> isi.edu> wrote:
> 
>> 
>> 
>> On 6/29/2012 5:00 PM, Alan DeKok wrote:
>>> Joe Touch wrote:
>>>> My last graphed measurements of this were in an NPSEC 2006 paper, and
>>>> show that an entire Xeon CPU (within noise of current ones) gets around
>>>> 50Mbps at 100% load.
>>> 
>>>  Well... I've measured commodity systems doing 940+ Mbps with AES-256.
>>> This is in the last 4 months, using 2 year-old systems, and 1.5K packets.
>> 
>> It would be useful to know if that actually sent packets on the wire (not in-memory measurements), and if
so, how much of your CPU was gone in the process.
>> 
>>>  If you need crypto acceleration to fill a 1G pipe, then your system
>>> has less CPU power than my iPhone.
>> 
>> Your iPhone certainly can't run anywhere this fast.
> 
> You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the
hardware encryption chip (if there even is one)

And background processes too, since iOS 4.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Yutaka OIWA | 2 Jul 2012 10:56
Picon
Favicon

Re: On webauth and layering (Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP)

Dear Nico,

First to clarify, you seem to be misunderstanding my claim about
"unnaturality".  I've never said that your specific proposal is unnatural;
I just said that use of HTTP headers are natural for Mutual authentication
protocol, and that such "naturality" property depends on specific design
and use of each protocols, not a universal one.
It seem to me that it also holds for Alexey's SCRAM-SHA1 proposal.

2012/6/26 Nico Williams <nico <at> cryptonector.com>:
> On Fri, Jun 15, 2012 at 7:38 PM, Yutaka OIWA <y.oiwa <at> aist.go.jp> wrote:

> If you mean that application-layer authentication is unnatural on the
> wire then I disagree vehemently.  In fact, I think any HTTP-layer
> authentication scheme will be unnatural on the wire: HTTP is a
> one-round-trip, stateless protocol, but authentication protocols are
> mostly NOT one round-trip (or less).

For the first sentence, the answer is "NO" as I wrote above.
However, I disagree on the following sentences.
Both Mutual and SCRAM authentication schemes are
meeting "stateless" requirements of the HTTP
which is described in httpbis-p1, quoted below.

> HTTP is defined as a stateless protocol, meaning that each request message can be understood in
isolation. [...] Hence, servers MUST NOT assume that two requests on the same connection are from the same
user agent unless the connection is secured and specific to that agent.

HTTP's design criteria is that HTTP transport is completely
"stateless", meaning that each response is tied to a single request,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Finch | 2 Jul 2012 13:22
Picon
Favicon

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

joel jaeggli <joelja <at> bogus.com> wrote:
> On 6/30/12 6:04 AM, Yaron Sheffer wrote:
> >
> > - The dirty little secret is that many people do not even authenticate the
> > server. In the cloud computing space (today's Wild West?) I have seen
> > several cases of popular tools that just don't bother, with no apparent
> > justification that I can think of. Another example is EAP-TLS configuration
> > on Windows.

> offhand I'd say that's the case for most smtp mta implementations as well...

That's mainly because there's no spec for which identity to check against
the cert. Consequently bad certs don't cause operational problems, so most
certs that have been installed can't be verified.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Working on a fix: http://tools.ietf.org/html/draft-fanf-dane-smtp

Tony.
--

-- 
f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
Tyne, Dogger: South 5 or 6, decreasing 3 or 4. Slight or moderate. Rain, fog
patches developing. Good, becoming moderate, occasionally very poor.
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 2 Jul 2012 14:57

Re: Should security requirements be MUST?

On Sun, Jul 1, 2012 at 11:04 PM, Joe Touch <touch <at> isi.edu> wrote:
>
>
> On Jun 29, 2012, at 5:43 PM, Eric Rescorla <ekr <at> rtfm.com> wrote:

>> You realize that an iPhone only allows one foreground process so it hardly matters if it doesn't share the
hardware encryption chip (if there even is one)
>
> And background processes too, since iOS 4.

iOS background processes are very sharply limited in terms of
how much resources they can consume.

http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html

About the only one of these cases that would allow you to do
high-speed encryption is voice/video, but video in the background
doesn't make sense and video in the foreground means nobody
else should be doing fast encryption.

Really, I'm finding it pretty hard to believe we're still having this
userland versus kernel debate in 2012. The market has spoken
and userland cryptography won. That was clear back in 1999.

-Ekr
Permalink | Reply | 3 comments |
headers
Stephen Kent | 2 Jul 2012 18:04
Picon

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

>...
>
>x.500 naming is just not useful.  Humans can handle name <at> domain and
>only slightly more complex name forms, but x.500 is impossible.  And
>we're stuck with Name because that's what TBSCertificate uses for
>subjectName.  We can't switch to GeneralName for subjectName.  We're
>screwed.  I'm tempted to propose the use of UUIDs in subjectName and
>then treat the first subjectAltName as the canonical name, banning the
>use of Name, but that wouldn't fly either.  We're stuck.

X.509 has supported DNS names as Subject Alt names since 1998.

Steve
Permalink | Reply | 0 comments |
headers
Nico Williams | 2 Jul 2012 18:05

Re: Should security requirements be MUST?

On Mon, Jul 2, 2012 at 7:57 AM, Eric Rescorla <ekr <at> rtfm.com> wrote:
> Really, I'm finding it pretty hard to believe we're still having this
> userland versus kernel debate in 2012. The market has spoken
> and userland cryptography won. That was clear back in 1999.

Agreed; user-land cryptographic protocols won long ago, and I'd say
they won with SSL 2.0, so, really, long, long ago.  There are
exceptions though, such as distributed filesystems, which usually are
implemented in kernel mode such that session crypto also happens in
kernel mode.  Also, there do exist kernel-mode HTTPS implementations
(e.g., Solaris has one), though I think that exists primarily to take
better advantage of crypto co-processors -- a thing of the past
really, as crypto instructions like AES-NI proliferate in new CPUs.
IPsec would have to have had APIs and all that in 1995 for this to
have turned out differently; it didn't.

Nico
--
Permalink | Reply | 0 comments |
headers
Nico Williams | 2 Jul 2012 18:12

Re: IPsec, APIs, and x.500 naming (Re: Should security requirements be MUST?)

On Mon, Jul 2, 2012 at 11:04 AM, Stephen Kent <kent <at> bbn.com> wrote:
>> x.500 naming is just not useful.  Humans can handle name <at> domain and
>> only slightly more complex name forms, but x.500 is impossible.  And
>> we're stuck with Name because that's what TBSCertificate uses for
>> subjectName.  We can't switch to GeneralName for subjectName.  We're
>> screwed.  I'm tempted to propose the use of UUIDs in subjectName and
>> then treat the first subjectAltName as the canonical name, banning the
>> use of Name, but that wouldn't fly either.  We're stuck.
>
> X.509 has supported DNS names as Subject Alt names since 1998.

Right, but not as subjectName, because subjectName is only a Name, not
a GeneralName.  And so we're still stuck with Name, and Name is simply
awful.

Nico
--
Permalink | Reply | 1 comment |
headers
Stephen Farrell | 2 Jul 2012 18:16
Picon
Picon

Re: Stephen Farrell's Discuss on draft-ietf-trill-rbridge-channel-06: (with DISCUSS and COMMENT)


Hi all,

I have a discuss [1] on a TRILL draft [2] that defines a way
to channel other protocols via RBridges.

In discussing that with Don, he nicely summarised the core issue
as follows:

On 07/01/2012 06:22 PM, Donald Eastlake wrote:
> it seems to me
> that what all this boils down to is that the Security Area has to
> decide that either (1) with improved wording an RBridge Channel level
> mandatory to implement, optional to use, security feature is not
> necessary for approval of this draft or (2) such a feature is
> necessary for approval of the draft and the TRILL WG needs to go come
> up with one.

TRILL isn't something I know much about, so I'd welcome input
(on or off list) as to what's reasonable here.

Note that there will be a statement that any other protocol
defined to run over this channel MUST define its own security
mechanisms.

Thanks,
Stephen.

[1]
https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-channel/ballot/
(Continue reading)

Permalink | Reply | 1 comment |

Gmane