On 19/02/15 04:57, Richard Barnes wrote: > On Wed, Feb 18, 2015 at 11:19 PM, Peter Saint-Andre - &yet <pe...@andyet.net >> wrote: > >> Hi Richard, thanks for the thoughtful review. Comments inline. >> >> On 2/18/15 8:34 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-uta-tls-bcp-09: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I really can't abide by the abdication in Section 5.2. >>> >> >> Abdication is an awfully strong word. >> > > And deliberately so. Maybe it's just late here, but the current text reads > to me as incredibly weak. > > > >> Getting a cert is >>> hard. Running reasonably recent software and configuring it properly is >>> not. The possibility that a connection will not be authenticated is no >>> excuse for using bad versions of TLS or using insecure ciphersuites. >>> >>> I appreciate that normally deference to WG consensus is appropriate, but >>> this is a recommendation that could be actively harmful to the Internet >>> by encouraging the continued use of broken code. >>> >> >> I think the document, then, does not provide clear enough text. >> >> I do not think we intended to actively recommend that anyone run broken >> code, use outdated versions of TLS, use insecure ciphersuites, etc. > > > Good. I'm glad we agree on this. > > Could I ask the opposite question? Which recommendations in the document > did people think *could* be violated in an unauthenticated context? > > > >> However, we are saying that this document was not written specifically to >> cover unauthenticated TLS usages because that was a point of strong >> contention in the WG and we were not able to reach consensus. The thread >> beginning here is illustrative: >> >> http://www.ietf.org/mail-archive/web/uta/current/msg00625.html >> > > Thanks for the link. That adds some helpful context. > > It also seems to me to illustrate that there's not much clarity in the > group about what problem this section is trying to solve. > > Part of the source of my confusion here is that from the pure perspective > of TLS, the server is *always* authenticated (and the client,
Factually incorrect. Anon-DH has been present in TLS since the beginning. If your DISCUSS is based on that misapprehension then you need to re-consider. S. > if mutual > auth is used) -- you always know what key you're talking to. Any binding > of that key to an identity is exogenous to TLS. > > Everything in the document besides Section 5 gets this right. There's no > mention of requirements on PKIX, or PGP certs, etc, except for some > indirect mentions in the Security Considerations. > > So it seems to me that this section is pure harm. It takes a document that > got the layering right, introduces semantic confusion, and thereby arrives > at a giant loophole. > > Can we just delete it? > > > > If you are insisting that this document be remanded to the WG with >> instructions that it reach consensus one way or the other, then please let >> us know. >> >> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> These COMMENTs are right on the edge of being DISCUSS points, because I >>> think there are some pretty critical references missing. Please consider >>> this a COMMENT of Unusual Strength. >>> >>> Section 1. "which together are the most widely deployed ciphers" >>> >>> Actually, at least in the web context, this isn't totally true. >>> According to Firefox telemetry, AES-GCM has been the most widely deployed >>> cipher since at least 3Q14, and is currently used in the majority of TLS >>> handshakes that Firefox does (52%) [1]. >>> >> >> As a result of addressing a comment from another IESG member, we will be >> changing "are" to "have been" in the quoted text. >> > > Great. "among the most" would have been fine too :) > > > >> Section 3.1.1. Implementations MUST NOT negotiate SSL version 3 >>> >>> A reference to draft-ietf-tls-sslv3-diediedie seems in order here. >>> >> >> Are you thinking that would be a normative reference or an informative >> reference? >> > > Informative will be fine. It just provides more background for this > requirement, and FWIW, duplicates it: > https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00#section-2 > > > >> Section 3.1. >>> >>> It would be good for this section to mention that servers MUST implement >>> TLS version negotiation. That is, they MUST NOT abort the handshake if >>> the version offered by the client is higher than the version the server >>> supports. This is, after all, the root cause of fallback. >>> >> >> Good point. >> >> Section 3.1.3. >>> >>> I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV >>> here. Did the WG discuss having any requirement for SCSV? >>> >> >> As I recall, the (brief) discussion concluded that a normative dependency >> on draft-ietf-tls-downgrade-scsv was not yet appropriate because it is too >> new to yet be a best *current* practice. >> >> On a more general note, the WG considered a number of recent proposals for >> TLS hardening, but concluded as well that they were too new to recommend >> quite yet. There is breaking news (pun intended) every week about TLS and >> there's no way that a document like this can reflect the very latest ideas >> and suggestions - we tried to balance practices that are (or might be >> considered) "best" against practices that are implemented and can be >> deployed today. IMHO the most we can do is get this BCP published and, as >> needed, update or replace it with improved recommendations on a regular >> basis (say, every year or two). This document was supposed to be published >> quickly after IETF 88 and is already late. >> > > Fair enough. Thanks for the background. > > > >> Also, if you want a cite for the 3% number, it's in the proceedings of >>> IETF 91 [2]. >>> >> >> Thanks. >> >> Section 3.3. >>> >>> You might point out HPACK [3] as an example of compression that is >>> sensitive to things like CRIME. >>> >> >> I see no harm in an informative reference. >> >> Section 3.5. >>> >>> Shouldn't this refer more specifically to draft-ietf-tls-session-hash >>> [4]? As it is, the recommendations in this section are kind of vacuous; >>> e.g., TLS without session-hash provides no way to "bind the master secret >>> to the full handshake". >>> >> >> Yes, that's what [triple-handshake] cites as well, and I agree that a >> pointer to it would be helpful. >> > > Yes, please make this direct. > > > >> Section 4.4. "Modular vs. Elliptic Curve" >>> >>> I think that "finite field" or "modp" are more common than "modular". >>> >> >> I have been told that elliptic curves are also finite fields, but I am not >> a cryptographer. >> > > /me dusts off his math degree... > > To get very technical, elliptic curves are finite *groups* (they're not > fields; they have no multiplication operation), whereas a modp group is the > multiplicative group of a finite field. > > --Richard > > > >> >> Peter >> >> >> > _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
