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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Thanks for the quick response and for addressing my comments. 

See in-line. 

Regards,

Dan


> -----Original Message-----
> From: Viktor Dukhovni [mailto:ietf-dane@xxxxxxxxxxxx]
> Sent: Wednesday, May 06, 2015 6:23 PM
> To: ietf@xxxxxxxx; dane@xxxxxxxx
> 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.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]