On 2011-06-22 3:35 AM, Nico Williams wrote:
My concern is that we already have a large number of technologies in
the IETF for establishing channels[*].
We don't have a large number of satisfactory technologies. Indeed, I
don't think we have any satisfactory technologies.
Among the problems
On Tue, Jun 21, 2011 at 5:38 PM, James A. Donald wrote:
> The time is long overdue for an encryption protocol that is not layered on
> top of tcp, and which has protocol negotiation built in.
It's called IPsec (KEs + ESP[/AH]).
Unfortunately you kinda need an implementation of RFC5660 in order f
On 2011-06-21 11:50 PM, Peter Gutmann wrote:
> The problem is that
introducing a totally new crypto API today is going to be pretty much
impossible. The NSA, in the mid to late 1990s, when the only well-established
crypto API around was PKCS #11, published three different reports on crypto
API d
On 19/06/11 9:47 PM, Jon Callas wrote:
Why not send *all* your network traffic over TLS?
On 2011-06-22 7:14 AM, Ian G wrote:
The typical reasons for not using TLS would be (a) it's a
stream-oriented point-to-point protocol, whereas most activity is
app-level datagram-oriented, (b) it's too clo
On Tue, Jun 21, 2011 at 1:18 PM, Ian G wrote:
> On 18/06/11 8:16 PM, Marsh Ray wrote:
>>
>> On 06/18/2011 03:08 PM, slinky wrote:
>
>> But we know there are still hundreds of
>> "trusted" root CAs, many from governments, that will silently install
>> themselves into Windows at the request of
On Tue, Jun 21, 2011 at 4:14 PM, Ian G wrote:
>> Why not send *all* your network traffic over TLS?
>
> The typical reasons for not using TLS would be (a) it's a stream-oriented
> point-to-point protocol, whereas most activity is app-level
> datagram-oriented, (b) it's too closely linked with PKI /
On 19/06/11 9:47 PM, Jon Callas wrote:
On Jun 19, 2011, at 5:54 PM, Nico Williams wrote:
On Sun, Jun 19, 2011 at 7:01 PM, Jon Callas wrote:
That brings us back to the main question: what problem are you trying to solve?
The OP meantioned that the context was JavaScript crypto, and whether
On Tue, Jun 21, 2011 at 2:10 PM, Marsh Ray wrote:
> On 06/21/2011 10:27 AM, Nico Williams wrote:
>>
>> Martin Rex found the TLS renegotiation bug independently from Marsh
>> Ray by thinking of how the SSPI is used to interface to TLS. The SSPI
>> was so faithful to TLS that it really exposed the
On 06/21/2011 12:18 PM, Ian G wrote:
On 18/06/11 8:16 PM, Marsh Ray wrote:
On 06/18/2011 03:08 PM, slinky wrote:
But we know there are still hundreds of
"trusted" root CAs, many from governments, that will silently install
themselves into Windows at the request of any website. Some of th
On 18/06/11 8:16 PM, Marsh Ray wrote:
On 06/18/2011 03:08 PM, slinky wrote:
But we know there are still hundreds of
"trusted" root CAs, many from governments, that will silently install
themselves into Windows at the request of any website. Some of these
even have code signing capabiliti
On 20/06/11 10:59 AM, Solar Designer wrote:
On Wed, Jun 15, 2011 at 04:22:55AM +0400, Solar Designer wrote:
I am trying to
learn some lessons from this.
This used to happen to me a lot in the old Cryptix days, which for a
while were a sort of smorgasboard of algorithms.
One lesson was tha
Cross-posted on .
This is a discussion that started on the Cryptography mailing list:
http://lists.randombit.net/pipermail/cryptography/2011-June/000940.html
NOTE: You need to be a member to post on either list.
RandomBit: http://lists.randombit.net/mailman/listinfo/cryptography
IETF: https://
On 06/21/2011 10:27 AM, Nico Williams wrote:
Martin Rex found the TLS renegotiation bug independently from Marsh
Ray by thinking of how the SSPI is used to interface to TLS. The SSPI
was so faithful to TLS that it really exposed the bug.
Right, so one of the lessons learned here was that if I
On Tue, Jun 21, 2011 at 1:17 PM, Novikov, Lev wrote:
> On 2011-06-21 13:36, Nico Williams wrote:
>> [...] My concern is that we already have a large number of
>> technologies in the IETF for establishing channels[*]. Adding any
>> more should require some strong justification for not using an
>>
Nico,
On 2011-06-21 13:36, Nico Williams wrote:
> [...] My concern is that we already have a large number of
> technologies in the IETF for establishing channels[*]. Adding any
> more should require some strong justification for not using an
> existing one. [...] But when we're talking about *
I'm quite concerned about this section 5 of
http://tools.ietf.org/html/draft-lanz-cicm-lm-00, and, really,
everything to do with "channels" in CICM.
My concern is that we already have a large number of technologies in
the IETF for establishing channels[*]. Adding any more should require
some stro
On 2011-06-22 12:50, Peter Gutmann wrote:
> The problem is that introducing a totally new crypto API today is
> going to be pretty much impossible. [...]
> I cannot imagine what size hammer you'd need to wield to convince
> vendors to implement a totally new API for their products. [...]
> The prob
You might say that the GSS-API is very TL-y or SASL-y too, since
MSFT's SSPI (which is very similar to the GSS-API) has an interface to
TLS and to SASL as well as to NTLM and the Kerberos GSS mechanism.
Martin Rex found the TLS renegotiation bug independently from Marsh
Ray by thinking of how the
On Jun 21, 2011 8:16 AM, "Peter Gutmann" wrote:
>
> Nico Williams writes:
>
> >Not so! Please point to some evidence if you wish to insist on this.
>
> GSS-API is pretty Kerberos-y. It may not have it directly baked in, but
you
> really have to squint at it pretty funny to go beyond Kerberos.
"Novikov, Lev" writes:
>There is an existing class of devices and environments (e.g., military and
>diplomatic communications) which have particular requirements that are hard
>to retrofit into existing crypto APIs (i.e. the logical models are
>substantially different).
>
>For example, many of th
Nico Williams writes:
>Not so! Please point to some evidence if you wish to insist on this.
GSS-API is pretty Kerberos-y. It may not have it directly baked in, but you
really have to squint at it pretty funny to go beyond Kerberos. I know you
can pretend it's not a meant-for-Kerberos API, but
On Tue, Jun 21, 2011 at 03:38:39PM +1200, Peter Gutmann wrote:
> Jeffrey Walton writes:
>
> >The 'details' mentioned above is at http://www.schneier.com/blowfish-bug.txt,
> >and here's the crux of Morgan's report:
> >
> >[bfinit] chokes whenever the most significant bit
> >of key[j] is a
22 matches
Mail list logo
