On 2/28/11 3:45 AM, Nikos Mavrogiannopoulos wrote:
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
Sean Turner wrote:
Yours was the first document I noticed to use SHA384 as PRF. If there
are other documents that specify that, and don't set the verify_data_length
size then it applies to those as well. (just noticed that applies to RFC5288
as well).
If the verify_data_length default
This draft makes three references to RFC 4646, Tags for Identifying
Languages, which was obsoleted in September 2009 by RFC 5646 (still BCP
47).
RFC 5646 introduced numerous changes, by far the most significant of
which was to add support for language subtags based on ISO 639-3. This
increased
On 3/8/11 8:09 AM, Doug Ewell wrote:
This draft makes three references to RFC 4646, Tags for Identifying
Languages, which was obsoleted in September 2009 by RFC 5646 (still BCP
47).
RFC 5646 introduced numerous changes, by far the most significant of
which was to add support for language
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of course).
-Ekr
On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex m...@sap.com wrote:
Sean
On Mar 3, 2011, at 12:37 PM, Russ Housley wrote:
Begin forwarded message:
From: Rene Struik rstruik@gmail.com
Date: March 2, 2011 10:03:33 PM EST
To: ietf@ietf.org
Subject: Re: Last Call: draft-herzog-static-ecdh-04.txt (Use of
static-static Elliptic-Curve Diffie-Hellman key
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of course).
One of the purposes of a cryptographic hash function
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
the length of the verify_data of
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is than
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length
On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray ma...@extendedsubset.com wrote:
On 03/08/2011 11:33 AM, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rexm...@sap.com wrote:
Cutting down the SHA-384 output from 48 to 12 octets significantly
impairs
its ability to protect from
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
I don't understand this
Eric Rescorla wrote:
Marsh Ray wrote:
I think he's arguing that anything cut down to 96 bits represents a lousy
hash function allowing practical collisions on today's hardware.
Perhaps, but this isn't a digest but rather a MAC, and so the attack
model is different.
You seem to be
The comment period ends tomorrow.
Bob
On Feb 22, 2011, at 9:31 PM, Bob Hinden wrote:
Based on the discussion, the IAOC has decided to put the XML2RFC RFP on hold,
notify potential bidders of this, and have a community comment period on the
tools-disc...@ietf.org list. Subscription
On Tue, Mar 8, 2011 at 10:45 AM, Martin Rex m...@sap.com wrote:
Eric Rescorla wrote:
Marsh Ray wrote:
I think he's arguing that anything cut down to 96 bits represents a lousy
hash function allowing practical collisions on today's hardware.
Perhaps, but this isn't a digest but rather a
Eric Rescorla wrote:
If we move in a new, stronger crypto-algorithm, then we should not
unreasonably spoil its properties.
Truncating a SHA-384 based PRF to 12 octets is like using
an sha384WithRsaEncryption signature with a 1024 bit RSA key,
it is an imbalanced pairing of
Eric Rescorla wrote:
I'm sorry, but I think it is a bad idea to use a flawed design for
the TLS finished message by subverting the collision resistence
of stronger secure hash functions that are used for the PRF.
Yes, I realize you think that, but until you offer a cryptographic
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
TLSv1.2
resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference
you might want the intended status of that draft to be historic not
informative
On Mar 6, 2011, at 11:04 PM, Mykyta Yevstifeyev wrote:
Hello all,
I've just made the Internet-Draft containing some summary on IONs experiment
available. You may find it here:
Hi, thanks for the quick response. More comments inline. I've deleted any
sections on which I think we are in agreement.
On Mar 7, 2011, at 6:07 AM, Oscar Novo wrote:
Hello Ben,
Thanks for your comments. Answers to your comments inline.
Oscar
-Original Message-
From: Ben
On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex m...@sap.com wrote:
resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references
On 3/8/11 2:59 PM, Lyman Chapin wrote:
I suggest that the draft include a definition of the term writing
system. Peter Daniels' explanation of what a writing system is in
The World's Writing Systems is probably too detailed (not to mention
arcane); but given the importance of the term (which is
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
Martin Rex m...@sap.com writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any may have become first popular, there was only room for 96 bits
of MAC data in the IP
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Resource Certificate PKI (RPKI) Trust Anchor Locator'
draft-ietf-sidr-ta-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has approved the following document:
- 'SONET/SDH Circuit Emulation Service Over Packet (CEP) Management
Information Base (MIB) Using SMIv2'
(draft-ietf-pwe3-cep-mib-16.txt) as a Proposed Standard
This document is the product of the Pseudowire Emulation Edge to Edge
Working Group.
The Multiple AoR reachabiliTy InformatioN Indication (martini) WG in the
Real-Time Applications and Infrastructure Area has concluded. With the
publication of RFC 5947 and RFC 6140, the group has achieved the goals for
which it was created.
The IESG contact persons are Gonzalo Camarillo and
28 matches
Mail list logo
