On Wed, 21 Dec 2005, The IESG wrote:
- An update to RFC 2716 to bring EAP-TLS into standards track, clarify
specification, interoperability, and implementation issues gathered over the
years, and update the document to meet the requirements of RFC 3748, RFC 4017,
and EAP keying framework
Branching off from the interminable justifiable changes thread
--On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings
[EMAIL PROTECTED] wrote:
Related to how much the charter pre-supposes the solution, the sentence
that Public keys needed to validate the signatures will be stored
Related to how much the charter pre-supposes the solution, the sentence
that Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy. seems like a pretty heavy
constraint on the possible solutions and one that some proposals
disagreed with.
I
Keith,
Keith Moore wrote:
I'm comfortable with having a domain's root public keys stored in DNS
but allowing the corresponding root private keys to sign key
certificates for individual public keys that can be included in
DKIM-signed messages. The policies for use of those public keys can
The question that I think IESG should be asking themselves is how is this
similar and/or different from other groups the have chartered or will in the
future. Nearly every group has some people with a fairly strong idea of at
least one way to solve the problem. Without this, it is usually not
If there were an I-D describing such a protocol, I'd be interested in
reading it - is there one?
Not yet. But it hardly seems like the time to write an I-D when there
is at present considerable effort being invested to preclude such an I-D
being considered by the group.
Keith
Branching off from the interminable justifiable changes thread
Dropping DKIM, because those people suffer enough without being subjected to
more general discussion about the nature of the universe at IETF :-)
I applaud Cullen for his note. I agree with the parts that Harald snipped
out,
Said individuals have also been known to make
misleading statements to support their arguments.
I'm thinking we must be coming to the end of productive discussion...
Spencer
___
Ietf mailing list
Ietf@ietf.org
On Thu, 22 Dec 2005, Keith Moore wrote:
Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to
store public key information is one of the fundamental assumptions behind
DKIM. Change that assumption and you will probably produce a system with
very different
On Thu, 22 Dec 2005, Barry Leiba wrote:
Actually, the DKIM base spec does provide a mechanism for replacing the
DNS keystore with something else. Look at 1.4 for a general statement,
and the description of the q= tag in 3.5. DKIM's intended to be able
to support user-level keys in a future
Keith Moore wrote:
OTOH, the assumption that _all_ public keys used to validate DKIM
signatures will be stored in DNS is a very limiting one, because it
appears to lead to either
a) a constraint that policy be specified only on a per-domain basis
(which is far too coarse for many
Cullen Jennings wrote:
My current understanding is that the deployments
are small enough that changes are still easy and that non backwards
compatible changes are already expected.
Mail is, in fact, pretty different than most IETF protocols
insofar as it's a store and forward system where
Michael,
Nice note.
One point, however:
Michael Thomas wrote:
We have already agreed to -- and incorporated -- a
substantial backward incompatible change (the canonicalization)
due to feedback (and threats) we got. What I'm hoping for
We have agreed to the addition of an enhancement that
Dave Crocker wrote:
We have agreed to the addition of an enhancement that provides a good
alternative to the existing set of two algorithms.
That is quite different from tossing out over-the-wire backward
compatibility.
I have not seen the group agree that a sender of an (ESTG) DKIMv1
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote:
If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.
My concern regarding the charter is related
'nowsp' canonicalization does not exist in DKIMv2 (-base-01). It was
eliminated, rather than deprecated, because it created a vulnerability.
sorry. i had misunderstood that line of discussion. and, yes,
vulnerability counts as a showstopper.
While some -base-01 verifiers may
Douglas Otis wrote:
DKIM should be seen as aspect of the SMTP transport.
IBTD. Trying to find any feature in DKIM not covered by the
existing SMTP schemes (MTAMARK, CSV, SPF, but not PRA) it's
_independence_ of SMTP that fascinates me in DKIM. All you
need is the header, a piece of software,
Michael,
Since I believe that, whatever else happens, it is better than
those who are interested in DKIM get on with the work rather
than spending more weeks or months splitting procedural hairs,
let me see if I can explain the distinction I see.
For context, I have a skeptical view of all
I believe in the end-to-end principle, rather than the network knows
best principle.
If someone is interested in a topic, they can subscribe to the topic.
If they are interested in everything, they can subscribe to everything.
If that are not interested in something, they can chose to not
Why force someone to listen to the whole
messaging/applications/rai/weather/snmp/smtp/ldap/foobar discussion if
all they are interested in is the limited topic of notifications?
I have no problems with insisting that posts to the list be in some way
about notifications, or about how a
I
think it has also been claimed that it is sufficiently finished
and mature that IETF ratification and endorsement is needed, but
no real changes are required or desirable.
John,
1. That is not what has been claimed or sought for DKIM. Ever. There
is a world of difference between
On Dec 22, 2005, at 12:06 PM, Frank Ellermann wrote:
Douglas Otis wrote:
DKIM should be seen as aspect of the SMTP transport.
It could also work for news if we get the FWS canonicalization right.
Agreed. The presents of the signature should not impose limitation
upon what content
--On Thursday, 22 December, 2005 14:09 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
I
think it has also been claimed that it is sufficiently
finished and mature that IETF ratification and endorsement is
needed, but no real changes are required or desirable.
John,
1. That is not
John C Klensin wrote:
In addition, there is, I think, one other approach that might be
appropriate, but only in very limited circumstances. That
approach applies where there is a well-thought-out approach with
design team consensus, evidence of implementation, and no
clearly-identified
On Dec 22, 2005, at 7:59 PM, J.D. Falk wrote:DKIM won't be deployed widely enough to be useful to senders until about a year after the IETF finishes with it. That's a pretty interesting statement considering this argument is about backwards compatibility with the "wide deployment" of a
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advantages and unlike DKIM or DK does not put
On Fri, 23 Dec 2005, Mark Delany wrote:
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of
John,
Dave, I'm sorry, but some of the assertions that have been made
about what protecting existing implementations means have been
indistinguishable to me from no real changes permitted. It
Please provide quotes, and please reconcile your assessment with the
list of real changes already
Apparently you expect the extensive, open group consensus process that
was pursued TWICE on this matter to have no import, but the last-minute,
vague whim of a few posters instead should hold sway.
Dave,
Unless you can cite an IETF BCP RFC that authorizes unchartered,
self-appointed, ad hoc
A new Request for Comments is now available in online RFC libraries.
RFC 4230
Title: RSVP Security Properties
Author(s): H. Tschofenig, R. Graveman
Status: Informational
Date: December 2005
Mailbox:[EMAIL PROTECTED], [EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4301
Title: Security Architecture for the Internet Protocol
Author(s): S. Kent, K. Seo
Status: Standards Track
Date: December 2005
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4306
Title: Internet Key Exchange (IKEv2) Protocol
Author(s): C. Kaufman, Ed.
Status: Standards Track
Date: December 2005
Mailbox:[EMAIL PROTECTED]
A new Request for Comments is now available in online RFC libraries.
RFC 4305
Title: Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload
(ESP) and Authentication Header (AH)
Author(s): D.
A new Request for Comments is now available in online RFC libraries.
RFC 4307
Title: Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)
Author(s): J. Schiller
Status: Standards Track
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 4312
Title: The Camellia Cipher Algorithm and Its Use With
IPsec
Author(s): A. Kato, S. Moriai, M. Kanda
Status: Standards Track
Date: December
A new Request for Comments is now available in online RFC libraries.
RFC 4304
Title: Extended Sequence Number (ESN) Addendum to
IPsec Domain of Interpretation (DOI)
for Internet Security Association
and Key
A new Request for Comments is now available in online RFC libraries.
RFC 4332
Title: Cisco's Mobile IPv4 Host Configuration Extensions
Author(s): K. Leung, A. Patel, G. Tsirtsis, E. Klovning
Status: Informational
Date: December 2005
A new Request for Comments is now available in online RFC libraries.
RFC 4309
Title: Using Advanced Encryption Standard (AES) CCM Mode
with IPsec Encapsulating Security Payload (ESP)
Author(s): R. Housley
Status: Standards Track
A new Request for Comments is now available in online RFC libraries.
RFC 4308
Title: Cryptographic Suites for IPsec
Author(s): P. Hoffman
Status: Standards Track
Date: December 2005
Mailbox:[EMAIL PROTECTED]
Pages:
39 matches
Mail list logo
