On 7 Feb 2017, at 8:12, Stephen Farrell wrote:
I've done my AD review of this draft. My own comments
on the content are below (the one I'd most like to
see fixed is the "escrow" stuff) and are ok to be
handled along with other IETF LC comments.
We decided to take these on now, before the IETF LC.
However, before I start IETF LC I would like to be
sure that the WG are ok with the IPR declaration [1]
filed in 2014 that said "Licensing Declaration to
be Provided Later." I think 2017 is "later" enough
to ask whether that the WG (via the chairs) explicitly
declare that they are ok that this has yet to be
clarified.
Warren has stated the question explicitly, and we await the response.
--Paul and Jakob
======================================================================
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the DNS-based Authentication of Named
Entities of the IETF.
Title : Using Secure DNS to Associate Certificates
with Domain Names For S/MIME
Authors : Paul Hoffman
Jakob Schlyter
Filename : draft-ietf-dane-smime-15.txt
Pages : 11
Date : 2017-02-13
Abstract:
This document describes how to use secure DNS to associate an S/MIME
user's certificate with the intended domain name, similar to the way
that DNS-Based Authentication of Named Entities (DANE), RFC 6698,
does for TLS.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime/
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dane-smime-15
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15
======================================================================
- abstract: Someone will want DANE expanded. Better to avoid
the acronym maybe.
Done.
- intro: "Some people want..." is odd - that is not a
technical justification and the entire paragraph is not that
convincing. I'd say deleting that para would be better. Or
add a real justification for the experiment which I think
relates more to attempting to mitigate the difficulty of
finding certs from outside the enterprise than anything else.
Many people here liked the justification, but we agree that your
justification is a good one as well. Added.
- intro: I'd suggest adding a sentence about how this is
similar to RFC7929. As a reader, I'd find it odd to only find
that out later.
Done.
- section 3: This is the same idea as in RFC 7929 right?
(Other than _smimecert I mean,) If so then saying so is right
as it'll help with IETF LC and IESG review and for
developers. If those differ, then saying how and why I think
would be needed.
Done.
- section 4: Please check whether this is all fine when also
considering draft-ietf-lamps-eai-addresses (also in IETF LC).
That check may need to wait a little bit until we're done
with the LC comment handling for the LAMPS deraft.
The current text is "all fine" with the LAMPS draft.
- Section 9: the discussion of an MTA doing the outbound
encryption seems a bit theoretical - I don't recall that
being dnoe in reality except maybe in very special cases like
nested smime, or military messaging. Am I wrong about that?
Yes, you are. There have been products doing this for many years
(possibly more than a decade). Having said that...
- section 9: I think the text about escrow would be better
after the current last para (where you call out the danger of
bad public keys being put in the DNS), and this (escrow)
ought be described as a special case of that attack, where
the attacker is the organisation itself. (While there are
cases where the organisation doing this is not intended as an
attack, were it done for most DNS names, it would mostly be
an attack, and is not distinguishable from an attack for the
sender, so therefore it ought IMO be considered an attack.)
Yes, good call. Done.
- section 9: s/MUST not/MUST NOT/ or I-D nits complains
And we must keep the tool happy, mustn't we? Done.
- section 11: I-D nits complains, maybe calling this
"normative references" would help, but in any case, please
consider/fix this.
The tool is wrong, but we can fix it easily anyhow. Done.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
