On Thu, Feb 19, 2015 at 5:17 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > > 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. > Well, that brings up another thing that this document should deprecate. ;) As RFC 5246 points out: """ Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. """ In other words, you still know that you're talking to the holder of the private key corresponding to the server's public (DH) key. It's equivalent to a self-signed cert. You could "authenticate" it by checking that it's the right DH key out of band, in the same way as a self-signed cert. The basis of my DISCUSS is I haven't heard anyone say what they would want to change about this document to make it suitable for an "unauthenticated" environment. Regardless of whether there's consensus for changes, if nobody's asking for changes, we shouldn't preemptively open the door. After talking with Pete some last night, I think another confusion here is (predictably) over uses of "opportunistic" (as indeed the title of section 5.2 implies). 1. Using TLS without checking the credentials presented by the remote side 2. Interoperating with legacy things using whatever TLS settings possible I get the sense that a lot of the discussion here, especially from the mail perspective, is related to the second thing, which is so clearly out of scope for this document that it doesn't bear mentioning. And what I'm saying above is that this document *also* doesn't need to say anything about the first thing, because TLS looks exactly the same on the wire whether you check the credentials or not. I would probably be OK if the "Opportunistic" stuff were scoped down to say, "This document doesn't say anything about how you choose whether to use TLS for a given session, just how you use it once you do," and the unauthenticated stuff were removed entirely. --Richard > > 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
