headers
Joe Touch | 2 Jul 2012 19:09
Picon
Favicon

Re: Should security requirements be MUST?


On 7/2/2012 10:03 AM, Eric Rescorla wrote:
> On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch <touch <at> isi.edu> wrote:
>>
>>
>> On 7/2/2012 9:05 AM, Nico Williams wrote:
>>>
>>> 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.
>>
>>
>> App-layer.
>>
>> Where they won, they won because they allowed half the connection to not
>> authenticate.
>
> No, they won because the people deploying the software wanted to be
> able to have it just install on the user's machine without screwing with the
> kernel.

SSL is popular because users don't need to buy X.509 certs or register 
with an authority to use it.
(Continue reading)

Permalink | Reply |
headers
Eric Rescorla | 2 Jul 2012 19:17

Re: Should security requirements be MUST?

On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch <touch <at> isi.edu> wrote:
>
>
> On 7/2/2012 10:03 AM, Eric Rescorla wrote:
>>
>> On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch <touch <at> isi.edu> wrote:
>>>
>>>
>>>
>>> On 7/2/2012 9:05 AM, Nico Williams wrote:
>>>>
>>>>
>>>> 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.
>>>
>>>
>>>
>>> App-layer.
>>>
>>> Where they won, they won because they allowed half the connection to not
>>> authenticate.
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 2 Jul 2012 19:34
Picon
Favicon

Re: Should security requirements be MUST?


On 7/2/2012 10:17 AM, Eric Rescorla wrote:
> On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch <touch <at> isi.edu> wrote:
...
>> SSL is popular because users don't need to buy X.509 certs or register with
>> an authority to use it.
>
> IPsec could have been run in the same configuration (i.e., with anonymous
> clients) if people had wanted to. For instance, one could have used
> self-signed certs on the client side.
>
> Seriously, you think Netscape would have shipped a security system that
> required you to install a kernel module?

They could have shipped with a security system that used an existing 
security kernel module, just like they shipped with a communication 
system that used an existing transport kernel module.

They could also have shipped with modules that used kernel modules 
optionally where present.

>>>> BTNS was all about trying to get that benefit for protocols
>>>> like IPsec, that were wound too tightly around a "one size fits all"
>>>> approach, IMO.
>>>>
>>>> And they won for consumer transactions. Secure tunnels can't operate
>>>> efficiently in user-space without defeating outboard transport, network,
>>>> and
>>>> link protocol support.
>>>
(Continue reading)

Permalink | Reply |
headers
Eric Rescorla | 2 Jul 2012 19:44

Re: Should security requirements be MUST?

On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <touch <at> isi.edu> wrote:
>
>
> On 7/2/2012 10:17 AM, Eric Rescorla wrote:
>>
>> On Mon, Jul 2, 2012 at 10:09 AM, Joe Touch <touch <at> isi.edu> wrote:
>
> ...
>
>>> SSL is popular because users don't need to buy X.509 certs or register
>>> with
>>> an authority to use it.
>>
>>
>> IPsec could have been run in the same configuration (i.e., with anonymous
>> clients) if people had wanted to. For instance, one could have used
>> self-signed certs on the client side.
>>
>> Seriously, you think Netscape would have shipped a security system that
>> required you to install a kernel module?
>
>
> They could have shipped with a security system that used an existing
> security kernel module, just like they shipped with a communication system
> that used an existing transport kernel module.

Please do tell: what existing security kernel module was available in
1995 across the entire range of operating systems that people
ran browsers on?
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 2 Jul 2012 20:00
Picon
Favicon

Re: Should security requirements be MUST?


On 7/2/2012 10:44 AM, Eric Rescorla wrote:
....
>> They could have shipped with a security system that used an existing
>> security kernel module, just like they shipped with a communication system
>> that used an existing transport kernel module.
>
> Please do tell: what existing security kernel module was available in
> 1995 across the entire range of operating systems that people
> ran browsers on?

IPsec didn't exist, nor did PPTP at the time.

But that was 1995. There have been more than a few releases since then. 
I don't know anyone who's still running 1995 browser software.

>> They could also have shipped with modules that used kernel modules
>> optionally where present.
>
> What would be the point of that once you already had to absorb the
> cost of shipping the crypto?

Backup support for services isn't uncommon. Even at the time kernel 
updates were fairly frequent - as frequent as app updates, in some cases 
(e.g., comparing release histories of MacOS, for which minor version 
numbers exist vs patch history, and Netscape).

> Look, I was actually involved in building cryptographic software intended
> for use by consumers at the time that SSL/TLS was being designed,
> and I can assure you that people thought that the need to install a kernel
(Continue reading)

Permalink | Reply |
headers
Eric Rescorla | 2 Jul 2012 19:50

Re: Should security requirements be MUST?

One more thing.

On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <touch <at> isi.edu> wrote:

> When you either care about your battery or preserving that $500 CPU for real
> work, you want a $10 crypto chip to help.
>
> When you handle messages that are high-speed but small (1500 bytes or
> smaller), you want that chip.

This isn't true. Performance of encryption and decryption is nearly linear
in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead
but it is amortized very quickly by message size. See, for instance,
Rescorla, "SSL and TLS", page 199.

Additionally, see Langley again:
"But don't make the records too large either! See the 15KB record that
https://www.bankofamerica.com sent? None of that data can be parsed by
the browser until the whole record has been received. As the
congestion window opens up, those large records tend to span several
windows and so there's an extra round trip of delay before the browser
gets any of that data. Since the browser is pre-parsing the HTML for
subresources, it'll delay discovery and cause more knock-on effects.

So how large should records be? There's always going to be some
uncertainty in that number because the size of the TCP header depends
on the OS and the number of SACK blocks that need to be sent. In the
ideal case, each packet is full and contains exactly one record. Start
with a value of 1415 bytes for a non-padded ciphersuite (like RC4), or
1403 bytes for an AES based ciphersuite and look at the packets which
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 2 Jul 2012 20:13
Picon
Favicon

Re: Should security requirements be MUST?


On 7/2/2012 10:50 AM, Eric Rescorla wrote:
> One more thing.
>
> On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <touch <at> isi.edu> wrote:
>
>> When you either care about your battery or preserving that $500 CPU for real
>> work, you want a $10 crypto chip to help.
>>
>> When you handle messages that are high-speed but small (1500 bytes or
>> smaller), you want that chip.
>
> This isn't true. Performance of encryption and decryption is nearly linear
> in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead
> but it is amortized very quickly by message size.

That must be why the high-speed SSL you cite uses 8K blocks, rather than 
something that might correspond better to the TCP packets sent.

 > See, for instance,
> Rescorla, "SSL and TLS", page 199.
>
> Additionally, see Langley again:
> "But don't make the records too large either! See the 15KB record that
> https://www.bankofamerica.com sent? None of that data can be parsed by
> the browser until the whole record has been received. As the
> congestion window opens up, those large records tend to span several
> windows and so there's an extra round trip of delay before the browser
> gets any of that data.
(Continue reading)

Permalink | Reply |
headers
Eric Rescorla | 2 Jul 2012 20:44

Re: Should security requirements be MUST?


On Jul 2, 2012, at 11:13, Joe Touch <touch <at> isi.edu> wrote:

> 
> 
> On 7/2/2012 10:50 AM, Eric Rescorla wrote:
>> One more thing.
>> 
>> On Mon, Jul 2, 2012 at 10:34 AM, Joe Touch <touch <at> isi.edu> wrote:
>> 
>>> When you either care about your battery or preserving that $500 CPU for real
>>> work, you want a $10 crypto chip to help.
>>> 
>>> When you handle messages that are high-speed but small (1500 bytes or
>>> smaller), you want that chip.
>> 
>> This isn't true. Performance of encryption and decryption is nearly linear
>> in messages encrypted. Yes, HMAC-SHA1 has some per-record overhead
>> but it is amortized very quickly by message size.
> 
> That must be why the high-speed SSL you cite uses 8K blocks, rather than something that might correspond
better to the TCP packets sent.
> 

You must be thinking of someone else.

I've provided you measurements that support what I am saying. Unless you have measurements that show
differently I don't think there is much to talk about

Ekr
(Continue reading)

Permalink | Reply |
headers
Jeffrey Hutzelman | 2 Jul 2012 21:03
Picon
Favicon

Re: Should security requirements be MUST?

OK, folks, that's enough.

This discussion has gone far, far afield of the original question, and
IMHO no longer addresses any question useful in either the design of
current and future Internet standards or in the writing of the documents
that describe them.

And frankly, I'm getting tired of watching Joe and ekr argue.  I've seen
over 20 messages in this thread in my inbox in the last couple of hours,
and it's getting old.

Please stop.  Please?

-- Jeff
Permalink | Reply |
headers
Marsh Ray | 2 Jul 2012 19:52
Favicon

Re: Should security requirements be MUST?

On 07/02/2012 12:34 PM, Joe Touch wrote:
>>
>> Seriously, you think Netscape would have shipped a security system that
>> required you to install a kernel module?
>
> They could have shipped with a security system that used an existing
> security kernel module, just like they shipped with a communication
> system that used an existing transport kernel module.

I'm sorry dude but that's just ridiculous.

If fact, Netscape shipped a time when kernel TCP/IP modules didn't exist 
on many clients.

Netscape shipped SSL 6 months before IPsec was even described for the 
first time in RFC 1825. Of course there were no kernel crypto modules.

Today on a popular platform like MS Windows there are OS-provided crypto 
modules. Some apps use them, some don't. But you can bet if it were a 
significant perf benefit to doing it in kernel mode this optimization 
would have gotten to network programmers. In fact, Windows IIS and Linux 
both have in-kernel http servers but this has everything to do with 
reducing user-kernel mode context switches and nothing to do with crypto 
performance. The only crypto performance issues I ever hear of people 
having on modern hardware is the asymmetric key operations.

And with that, I'm pretty sure this thread has overextended its ability 
to inform.

- Marsh
(Continue reading)

Permalink | Reply |
headers
david.black | 2 Jul 2012 20:06

SSL VPN

Joe Touch writes:

>>>> What, you've never heard of an SSL VPN?
>>>
>>> I've also heard of token ring, but besides the geek community, it's not used
>>> all that much. The dominant VPNs are IPsec and PPTP.
>>
>> Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and
>> why Cisco AnyConnect now supports DTLS.
>
>  From their pages, these appear to be focused on support for email and
> web access to SSL-based services. E.g., from Cisco's page:
> 
> ---
> SSL VPN Overview
> 
> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from
> almost any Internet-enabled location using only a web browser that
> natively supports SSL encryption. This feature allows your company to
> extend access to its secure enterprise network to any authorized user by
> providing remote-access connectivity to corporate resources from any
> Internet-enabled location.
> ---
> 
> I.e., that's web browser access to services.

That's wrong, sorry.  An SSL VPN provides full IP network extension -
it's most definitely not browser-only.  The technology is effectively IP
encapsulation in TLS, not clever use of TLS to access "SSL-based services."
(Continue reading)

Permalink | Reply |
headers
Fisk, Mike | 2 Jul 2012 21:28

Re: SSL VPN

The marketing around SSL VPN is pretty atrocious in my opinion... Most products basically provide an SSL proxy to internal web servers and, optionally, a "browser-based" plugin that installs a full kernel-level network tunnel for you. On Linux, for example, one major vendor provides a java package that runs sudo, gets the user to authenticate, and installs a traditional VPN client (not exactly the kind of thing you want users to be trained to be accepting of). Whether or not that tunnel uses SSL, IPsec, or rot13 is difficult to tell. Enterprises apparently prefer to get their employees to install network tunnels from the browser than to distribute software in more traditional ways.



-----Original Message-----
From: david.black <at> emc.com [david.black <at> emc.com]
Sent: Monday, July 02, 2012 12:07 PM Mountain Standard Time
To: touch <at> isi.edu
Cc: saag <at> ietf.org
Subject: [saag] SSL VPN

Joe Touch writes:

>>>> What, you've never heard of an SSL VPN?
>>>
>>> I've also heard of token ring, but besides the geek community, it's not used
>>> all that much. The dominant VPNs are IPsec and PPTP.
>>
>> Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and
>> why Cisco AnyConnect now supports DTLS.
>
>  From their pages, these appear to be focused on support for email and
> web access to SSL-based services. E.g., from Cisco's page:
>
> ---
> SSL VPN Overview
>
> Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from
> almost any Internet-enabled location using only a web browser that
> natively supports SSL encryption. This feature allows your company to
> extend access to its secure enterprise network to any authorized user by
> providing remote-access connectivity to corporate resources from any
> Internet-enabled location.
> ---
>
> I.e., that's web browser access to services.

That's wrong, sorry.  An SSL VPN provides full IP network extension -
it's most definitely not browser-only.  The technology is effectively IP
encapsulation in TLS, not clever use of TLS to access "SSL-based services."

EMC uses AnyConnect for secure remote access, and it effectively
replaced usage of remote access IPsec VPNs for the entire company.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

<div>
The marketing around SSL VPN is pretty atrocious in my opinion... Most products basically provide an SSL proxy to internal web servers and, optionally, a "browser-based" plugin that installs a full kernel-level network tunnel for you. On Linux, for example,
 one major vendor provides a java package that runs sudo, gets the user to authenticate, and installs a traditional VPN client (not exactly the kind of thing you want users to be trained to be accepting of). Whether or not that tunnel uses SSL, IPsec, or rot13
 is difficult to tell. Enterprises apparently prefer to get their employees to install network tunnels from the browser than to distribute software in more traditional ways.<br><br><br><br>
-----Original Message-----<br>From:&nbsp;david.black <at> emc.com [<a href="mailto:david.black <at> emc.com">david.black <at> emc.com</a>]<br>Sent:&nbsp;Monday, July 02, 2012 12:07 PM Mountain Standard Time<br>To:&nbsp;touch <at> isi.edu<br>Cc:&nbsp;saag <at> ietf.org<br>Subject:&nbsp;[saag] SSL VPN<br><br><p>Joe Touch writes:<br><br>
&gt;&gt;&gt;&gt; What, you've never heard of an SSL VPN?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I've also heard of token ring, but besides the geek community, it's not used<br>
&gt;&gt;&gt; all that much. The dominant VPNs are IPsec and PPTP.<br>
&gt;&gt;<br>
&gt;&gt; Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and<br>
&gt;&gt; why Cisco AnyConnect now supports DTLS.<br>
&gt;<br>
&gt;&nbsp; From their pages, these appear to be focused on support for email and<br>
&gt; web access to SSL-based services. E.g., from Cisco's page:<br>
&gt;<br>
&gt; ---<br>
&gt; SSL VPN Overview<br>
&gt;<br>
&gt; Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from<br>
&gt; almost any Internet-enabled location using only a web browser that<br>
&gt; natively supports SSL encryption. This feature allows your company to<br>
&gt; extend access to its secure enterprise network to any authorized user by<br>
&gt; providing remote-access connectivity to corporate resources from any<br>
&gt; Internet-enabled location.<br>
&gt; ---<br>
&gt;<br>
&gt; I.e., that's web browser access to services.<br><br>
That's wrong, sorry.&nbsp; An SSL VPN provides full IP network extension -<br>
it's most definitely not browser-only.&nbsp; The technology is effectively IP<br>
encapsulation in TLS, not clever use of TLS to access "SSL-based services."<br><br>
EMC uses AnyConnect for secure remote access, and it effectively<br>
replaced usage of remote access IPsec VPNs for the entire company.<br><br>
Thanks,<br>
--David<br>
----------------------------------------------------<br>
David L. Black, Distinguished Engineer<br>
EMC Corporation, 176 South St., Hopkinton, MA&nbsp; 01748<br>
+1 (508) 293-7953&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FAX: +1 (508) 293-7786<br>
david.black <at> emc.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +1 (978) 394-7754<br>
----------------------------------------------------<br><br>
_______________________________________________<br>
saag mailing list<br>
saag <at> ietf.org<br><a href="https://www.ietf.org/mailman/listinfo/saag">https://www.ietf.org/mailman/listinfo/saag</a><br></p>
</div>
Permalink | Reply |
headers
Hannes Tschofenig | 3 Jul 2012 08:34
Picon

Re: SSL VPN

The issue is that VPN vendors want to provide software to customers that actually work.

There are networks out there (and I wish I had data to cite; maybe someone else has) that provide fairly
excessing filtering policies and hence a plain IETF IKEv2/IPsec based VPN wouldn't get through the
firewalls. 

Then, you have two choices: 

1) change the transport mechanisms for IKEv2/IPsec (running it over TCP)
2) switch to TLS

Since the IKEv2 exchange is pretty similar to the TLS handshake most people may not have strong preferences
between the two. Over the years we had copied the features between TLS and IKEv2 back and forth.  

Ciao
Hannes

On Jul 2, 2012, at 10:28 PM, Fisk, Mike wrote:

> The marketing around SSL VPN is pretty atrocious in my opinion... Most products basically provide an SSL
proxy to internal web servers and, optionally, a "browser-based" plugin that installs a full
kernel-level network tunnel for you. On Linux, for example, one major vendor provides a java package that
runs sudo, gets the user to authenticate, and installs a traditional VPN client (not exactly the kind of
thing you want users to be trained to be accepting of). Whether or not that tunnel uses SSL, IPsec, or rot13
is difficult to tell. Enterprises apparently prefer to get their employees to install network tunnels
from the browser than to distribute software in more traditional ways.
> 
> 
> 
> -----Original Message-----
> From: david.black <at> emc.com [david.black <at> emc.com]
> Sent: Monday, July 02, 2012 12:07 PM Mountain Standard Time
> To: touch <at> isi.edu
> Cc: saag <at> ietf.org
> Subject: [saag] SSL VPN
> 
> Joe Touch writes:
> 
> >>>> What, you've never heard of an SSL VPN?
> >>>
> >>> I've also heard of token ring, but besides the geek community, it's not used
> >>> all that much. The dominant VPNs are IPsec and PPTP.
> >>
> >> Yeah, that's why both Cisco and Juniper have big SSL VPN product lines and
> >> why Cisco AnyConnect now supports DTLS.
> >
> >  From their pages, these appear to be focused on support for email and
> > web access to SSL-based services. E.g., from Cisco's page:
> >
> > ---
> > SSL VPN Overview
> >
> > Cisco IOS SSL VPN provides SSL VPN remote-access connectivity from
> > almost any Internet-enabled location using only a web browser that
> > natively supports SSL encryption. This feature allows your company to
> > extend access to its secure enterprise network to any authorized user by
> > providing remote-access connectivity to corporate resources from any
> > Internet-enabled location.
> > ---
> >
> > I.e., that's web browser access to services.
> 
> That's wrong, sorry.  An SSL VPN provides full IP network extension -
> it's most definitely not browser-only.  The technology is effectively IP
> encapsulation in TLS, not clever use of TLS to access "SSL-based services."
> 
> EMC uses AnyConnect for secure remote access, and it effectively
> replaced usage of remote access IPsec VPNs for the entire company.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> _______________________________________________
> saag mailing list
> saag <at> ietf.org
> https://www.ietf.org/mailman/listinfo/saag
> 
> _______________________________________________
> saag mailing list
> saag <at> ietf.org
> https://www.ietf.org/mailman/listinfo/saag
Permalink | Reply |
headers
Richard L. Barnes | 2 Jul 2012 19:23
Picon

Re: Should security requirements be MUST?


On Jul 2, 2012, at 1:09 PM, Joe Touch wrote:
> On 7/2/2012 10:03 AM, Eric Rescorla wrote:
>> On Mon, Jul 2, 2012 at 9:50 AM, Joe Touch <touch <at> isi.edu> wrote:
>>> On 7/2/2012 9:05 AM, Nico Williams wrote:
>>>> 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.
>>> 
>>> 
>>> App-layer.
>>> 
>>> Where they won, they won because they allowed half the connection to not
>>> authenticate.
>> 
>> No, they won because the people deploying the software wanted to be
>> able to have it just install on the user's machine without screwing with the
>> kernel.
> 
> SSL is popular because users don't need to buy X.509 certs or register with an authority to use it.
> 
> Compare, e.g., how popular SSL is vs. another userland security system that relies on PKI entries for all
users - I don't see the general public using PGP.
> 
>>> BTNS was all about trying to get that benefit for protocols
>>> like IPsec, that were wound too tightly around a "one size fits all"
>>> approach, IMO.
>>> 
>>> And they won for consumer transactions. Secure tunnels can't operate
>>> efficiently in user-space without defeating outboard transport, network, and
>>> link protocol support.
>> 
>> What, you've never heard of an SSL VPN?
> 
> I've also heard of token ring, but besides the geek community, it's not used all that much. The dominant
VPNs are IPsec and PPTP.

I'm aware of multiple enterprise VPNs based on DTLS.  For example:

"
The Cisco AnyConnect VPN Client provides remote users with secure VPN connections to the Cisco ASA 5500
Series Adaptive Security Appliance using the Secure Socket Layer (SSL) protocol and the Datagram TLS
(DTLS) protocol. AnyConnect provides remote end users with the benefits of a Cisco SSL VPN client, and
supports applications and functions unavailable to a clientless, browser-based SSL VPN connection.

"
<http://www.cisco.com/en/US/products/ps8411/products_qanda_item09186a00809aec31.shtml>
Permalink | Reply |

Gmane