ietf
[Top] [All Lists]

RE: Gen-ART review of draft-ietf-dane-smtp-with-dane-16

2015-05-07 03:52:39
Hi,

Thanks for the quick response and for addressing my comments. 

See in-line. 

Regards,

Dan


-----Original Message-----
From: Viktor Dukhovni [mailto:ietf-dane(_at_)dukhovni(_dot_)org]
Sent: Wednesday, May 06, 2015 6:23 PM
To: ietf(_at_)ietf(_dot_)org; dane(_at_)ietf(_dot_)org
Cc: Romascanu, Dan (Dan)
Subject: Re: Gen-ART review of draft-ietf-dane-smtp-with-dane-16

On Wed, May 06, 2015 at 02:58:42PM +0000, Romascanu, Dan (Dan) wrote:

Ready with minor comments.

I liked the operational considerations section and the security
consideration section - very useful in putting this work in the
context of other similar contributions.

Thanks.

Minor issues:

As the document uses heavily the term 'downgrade' (downgrade attack,
downgrade-resistant) it would be nice to either explain or provide a
reference for what it means in the context of this work.

In RFC 4949, at the bottom of page 112 we find:

    downgrade attack
      (I) A type of man-in-the-middle attack in which the attacker can
      cause two parties, at the time they negotiate a security
      association, to agree on a lower level of protection than the
      highest level that could have been supported by both of them.

We could add "downgrade attack" to the terminology, and briefly define
"downgrade resistance" under the same heading.  Alternatively, since the
primary downgrade at issue is stripping of STARTTLS, some additional text
could be added in 1.3.1 to introduce the terms.

Any advice on how to proceed?


I personally preferring having all key terms in one place - this makes reading 
easier. So I would go for inserting text in the terminology section with proper 
reference to RFC 4949. 

Nits/editorial comments:

The last paragraph in section 2.2.1, page 15 has a comment marked
twice by --. This may be an editorial left-over to be corrected.

That's what the RFC editor's xml2rfc does with "—".  When I run
xml2rfc, it produces "richer" HTML output, in which the mdashes remain as
such.  Should I avoid "—"?

Yes - and talk with the tools team, this may be a bug


--
      Viktor.


<Prev in Thread] Current Thread [Next in Thread>