On 10/27/2011 09:02 PM, Russ Housley wrote:
The fact that the SHA-384 is used in the latter case in combination
with AES_256 it implies that SHA256 was replaced by SHA384 to
increase the security (the same way AES-128 was replaced by
AES-256). However there is no evidence that a 96-bit SHA384
On 10/16/2011 09:23 AM, Nikos Mavrogiannopoulos wrote:
A comment on this draft is that it might be misleading on the
security levels it claims. It mentions: The Fact Sheet on Suite
B Cryptography requires key establishment and authentication
algorithms based on Elliptic Curve Cryptography
On 10/27/2011 07:37 PM, Russ Housley wrote:
more than 96-bits of security.
It is important to distinguish between off-line and on-line
attacks. It is common (though perhaps not universal) to rate
the strength of cryptography in terms of resistance to off-line
attack, and that is what Suite
On 10/14/2011 12:13 AM, Russ Housley wrote:
A comment on this draft is that it might be misleading on the
security levels it claims. It mentions: The Fact Sheet on Suite B
Cryptography requires key establishment and authentication
algorithms based on Elliptic Curve Cryptography and encryption
On 10/03/2011 10:55 PM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Suite B Profile for Transport Layer Security (TLS)'
draft-salter-rfc5430bis-01.txt as an Informational RFC
The IESG plans to make a decision in the
384 bits for the record messages, that IMO does not make much sense.
regards,
Nikos
[0]. http://homes.esat.kuleuven.be/~preneel/
On Mon, Mar 14, 2011 at 11:49 PM, Martin Rex m...@sap.com wrote:
Nikos Mavrogiannopoulos wrote:
On 03/14/2011 06:28 PM, Martin Rex wrote:
That was, what I assume
On 03/14/2011 06:28 PM, Martin Rex wrote:
Nikos Mavrogiannopoulos wrote:
This sounds pretty awkward decision because HMAC per record is full
(e.g. 160-bits on SHA-1), but the MAC on the handshake message
signature is truncated to 96-bits. Why wasn't the record MAC
truncated as well? In any
On 03/11/2011 12:28 AM, Stephen Kent wrote:
It wasn't any may have become first popular, there was only
room for 96 bits of MAC data in the IP packet, so MD5 was
truncated to that size.
This is an odd claim, since:
(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally
specified
On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla e...@rtfm.com wrote:
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be forgetting that the finished messages have been reused
for other purposes already:
No, I'm not forgetting that. That
On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla e...@rtfm.com wrote:
I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a
On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno
kanno.sat...@po.ntts.co.jp wrote:
I see that this document defines ciphersuites with a PRF based on
SHA384... However it does not specify the verify_data_length, thus
the default value of 12 applies, and the SHA384 PRF is being truncated
to 96
On 02/23/2011 06:29 PM, The IESG wrote:
The IESG has received a request from an individual submitter to
consider the following document: - 'Addition of the Camellia Cipher
Suites to Transport Layer Security (TLS)'
draft-kanno-tls-camellia-00.txt as an Informational RFC
The IESG plans to
On Mon, Oct 25, 2010 at 7:39 PM, Michael StJohns mstjo...@comcast.net wrote:
Hi -
I'm confused about this approval.
As I read the draft and the approval comments, this document is an
independent submission describing how to do C12.22 over IP. But the document
is without context for who
On Thu, Apr 22, 2010 at 4:29 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
In which environments is the extension useful?
The only motivation in the document that I can find is this:
In some application environments, it is desirable to have the client
and/or the server be able to input more
On Thu, Feb 25, 2010 at 1:07 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Mark Andrews wrote:
http://tools.ietf.org/html/draft-dempsky-dnscurve-00
As I read the draft, it seems to me that DNSCurve without Curve
(that is, with 96 bit nonce of DNSCurve as an extended message
ID
Masataka Ohta wrote:
Nikos Mavrogiannopoulos wrote:
Not really. I Don't know what you mean by simple nonce, but as I
understand dnscurve if implemented properly would have ssh-style
authentication.
Ssh without secure public key distribution mechanism is not really
secure
Concerning the SCSV behavior I prefer publishing the specification as-is.
regards,
Nikos
On Tue, Jan 26, 2010 at 9:49 AM, pasi.ero...@nokia.com wrote:
Concerns have been raised that the IESG may have judged community
consensus about one specific detail of draft-ietf-tls-renegotiation
On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex m...@sap.com wrote:
asideThat's been the standard for PKIX RFCs for at least ten years
(actively acknowledged by WG mmembers), although perhaps its spread
to other groups should be discouraged./aside
I fully agree.
That may be attributed to the
I'd propose to add this text to the standard:
This protocol MUST NOT be used with RFC4492, RFC5289 and
draft-rescorla-tls-suiteb.
That way the certicom's patents are not applicable.
On Mon, Jul 20, 2009 at 11:24 PM, Dan Harkinsdhark...@lounge.org wrote:
Certicom's IPR statement dated 13
Dean Anderson wrote:
I think you misunderstand how patents work or what the license says.
The licence is available for the case when used with either It is
not the case that a patent only applies to specific RFCs. RFC's aren't
mentioned in patents. Patent claims covering tls-extractor
20 matches
Mail list logo
