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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Dear participants of the Ietf mailing list,
I am a student doing research for my dissertation.
In part of that research I am looking for monitoring tools, specifically
implemented for the Home Agent. (MIB RFC 2006) Or the Mobile IP suite.
So far I have only found general tools, as the HP NNMi,
Overflowing by another 32 bits is hardly the same as there was only room for
-Ekr
On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
Eric Rescorla e...@rtfm.com writes:
Can you please point to where in IP there is a limit that requires a MAC no
greater than 96
On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
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
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 Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos n...@gnutls.org wrote:
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
Actually, this discussion has been going on for longer than so-far
referenced docs show.
One of my favourite RFCs on the subject:
RFC 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000.
The Internet Engineering Task Force (IETF) has been asked to take a
position on the inclusion into
Hi Ben,
More comments inline as [ON1]. :)
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: 8. maaliskuuta 2011 23:14
To: Oscar Novo
Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review
Team; The IETF
Subject: Re: Gen-ART LC Review of
On 03/08/2011 09:59 AM, Martin Rex wrote:
To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like
unreasonable cutdown of the security margin for the Finished messages.
I agree.
Last I looked into it, I came to the conclusion that collisions of any
efficient 96 bit hash
On 03/08/2011 11:33 AM, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 9:20 AM, Martin Rexm...@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
On 03/08/2011 12:45 PM, Martin Rex wrote:
RFC-5746 TLS extension Renegotiation indication
Yes, it would be bad if those could be collided.
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
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 used 7 times
in the draft), its
Martin Rex m...@sap.com writes:
Truncating the PRF output to 12 octets for TLSv1.2 seems like an error.
It's not an error, it's IPsec cargo cult design. OK, using cargo cult design
for a security protocol probably rates as an error, but the choice of exactly
96 bits was deliberate rather than
On Mar 9, 2011, at 6:01 AM, Oscar Novo wrote:
Hi Ben,
More comments inline as [ON1]. :)
-Original Message-
From: Ben Campbell [mailto:b...@estacado.net]
Sent: 8. maaliskuuta 2011 23:14
To: Oscar Novo
Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; General Area Review
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-netext-pmip6-lr-ps-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-ancp-protocol-15
Reviewer:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-ancp-protocol-15
Reviewer:
Transport Directorate review of draft-mrw-nat66-09.txt
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their
80th IETF Meeting
Prague, Czech Republic
March 27 - April 1, 2011
Host: CZ.NIC
1. Registration - Early Bird Cut-off March 18, 2011
2. NEW: Companion Program
3. Social Event
4. Visas Letters of Invitation
5. Accommodations and Transportation
6. Meeting Wiki
1. Registration - Early Bird
The IESG has received a request from the Datagram Congestion Control
Protocol WG (dccp) to consider the following document:
- 'Sender RTT Estimate Option for DCCP'
draft-ietf-dccp-tfrc-rtt-option-04.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Signed Object Template for the Resource Public Key Infrastructure'
draft-ietf-sidr-signed-object-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few
A new Request for Comments is now available in online RFC libraries.
RFC 6172
Title: Deprecation of the Internet Fibre
Channel Protocol (iFCP) Address Translation Mode
Author: D. Black, D. Peterson
Status: Standards
23 matches
Mail list logo
