Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
On Fri, 27 Nov 2020 23:43:42 -0500 Keith Moore wrote: > I'm aware of that. But what really is the point of a cert > (especially one issued by a public CA) that has an RFC1918 address as > its subject? Not that it matters that much because the vast majority > of sites using embedded systems aren't going to bother with them. > Most of those systems probably don't support cert installation by > customers anyway. You won't get such a certificate from a public CA (presumably meaning a CA issuing in the Web PKI). They're subject to the CA/B Baseline Requirements which explicitly forbid this (in 7.1.4.2.1): CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name. As I understand it the purpose of the IETF is to develop and promote Internet standards, to the extent that people enjoy using some of these standards to do things that aren't part of the Network they are welcome but it doesn't make sense for the IETF to focus on these uses. As an IETF draft the die-die-die work addresses the Internet, and it seems to me that ekr's assessment is entirely correct in that context. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
Hi Nancy On Mon, 26 Oct 2020 02:55:52 + "Nancy Cam-Winget (ncamwing)" wrote: > [NCW] The specific conditions are more deployment and vendor specific > and proprietary so it'd be difficult to enumerate (and enumerate them > all)...as well as which we believe is out of scope for the document. > I did add a paragraph to state that as well as we (the authors) are > not proponents for these techniques but as it had been asked to how > the deployments 'inspect' we thought it important to document the > most common known practices. Please look over the updates and see if > that clarifies intent. I see. I focused on the modifications to the document rather than re-reading the document. Thanks for correcting the typographical error and I acknowledge that the two new paragraphs reflect the intent you've described. > [NCW] Right, our intent was not to prescribe what should or should > not be done, but rather educate as to what is being done in practice > today. Unfortunately words like "effective" and "capability" give the impression that instead of describing practices which don't work neutrally so as to educate about what is done, this documents techniques that actually worked. My previous emails explained some problems with that back in August. Your co-author Roelof has argued that they can work under some specific circumstances, but this revision does not explain what those circumstances would be in the document itself and my impression from your reply is that you believe doing so would be "out of scope". Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)
On Fri, 02 Oct 2020 14:15:48 -0400 "Michael D'Errico" wrote: > > > You can't possibly implement [stateless HelloRetryRequest] the > > > way the spec suggests with just a hash in a HRR cookie extension. Lots of people have and it works just fine, so it seems to me that "You can't possibly" here means something closer to "I still don't understand how to" and as such would be more appropriate to some sort of programming Q site like Stack Overflow than an IETF working group. > Many of the fields in HelloRetryRequest are fixed or predictable, but > the legacy_session_id_echo is not, for example. Also, relying on the > client to remind you what the hash of ClientHello1 is seems extremely > "optimistic" (in my opinion). The client MUST use the same value for legacy_session_id in its retried ClientHello. As a result this value will be available alongside the cookie. Section 4.4.2 is clear that a hash used this way in the cookie should be "protected with some suitable integrity protection algorithm". For example some implementations use an HMAC construction, but you could do other things here successfully. So in fact this is not especially optimistic. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
On Wed, 23 Sep 2020 05:51:24 -0700 Eric Rescorla wrote: > I think this misunderstands the point. > > Suppose I want to add feature X. There are (at least) two scenarios: > > 1. Add a new feature and it just works. > 2. I have to get it added to the YANG module, then get middlebox > vendors to change their software which may involve introducing some > new parser for that feature, then I can publish a policy, and it > works. > > Option (2) is going to take much longer to happen than option (1). > Depending on how slow the vendors are, it could be indefinitely long. > Given that it's often not viable to roll out new networking features > if they introduce any significantly increased risk of failure, this > seems like a recipe for ossification. Perhaps the draft could instead be written in terms of allowing any TLS behaviour *except* behaviours the Thing promises (via a MUD file) never to use. For example a Thing might promise it doesn't do outbound TLS 1.1 or earlier, and then a compliant MUD manager can block or alert on TLS 1.1 or TLS 1.0 connections purportedly coming from the affected Thing. Or perhaps this Thing is designed to receive connections from another Thing and the MUD policy promises these will never use RSA kex, so the MUD manager can block or alert an attempt to use RSA kex. This seems like it avoids the MUD TLS YANG module needing to chase the bleeding edge of TLS development. A TLS feature only becomes relevant for this "ratchet" approach once there are better alternatives that Things should reasonably be doing instead of that feature, likely years after the feature is in wide use and well understood. That could apply appropriate back pressure to Thing vendors. If your Thing lacks the "I don't do outbound TLS 1.0" node in its MUD file then the question is, does it actually still do TLS 1.0? If it doesn't, a newer MUD file can be provided which says it promises not to. If it does still do TLS 1.0 that's a security policy risk for the owner to understand and perhaps decide to mitigate by whatever means they prefer. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
On Fri, 11 Sep 2020 12:32:03 +0530 tirumal reddy wrote: > The MUD URL is encrypted and shared only with the authorized > components in the network. An attacker cannot read the MUD URL and > identify the IoT device. Otherwise, it provides the attacker with > guidance on what vulnerabilities may be present on the IoT device. RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and over LLDP without - so far as I was able to see - any mechanism by which it should be meaningfully "encrypted" as to prevent an attacker on your network from reading it. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
On Thu, 20 Aug 2020 09:58:58 -0400 Roelof DuToit wrote: > As co-author I am not a proponent of passive TLS inspection - not > least because of the ossification implications. It cannot be labeled > as ineffective though (see further comments below), even if the > document strongly hints at not using passive TLS inspection in a > post-TLS-1.2 world. Mostly I endorse Ekr's comment that a document like this should actually spell out any convolutions and conditions necessary to the effective use of passive inspection. I would try to find time to examine a revised document that did this. But I do want to address one such in particular now: > 1. Policy-based control over the use of RSA key exchange. It should > not be allowed. Qualys estimates that when TLS 1.3 was finalised RSA was required for about 5.7% of web sites (it had been larger previously). That's a pretty huge caveat. The same document we're discussing, draft-ietf-opsec-ns-impact-02 actually several times relies upon RSA key exchange (in section 5.3) for methods it says will now be impacted by TLS 1.3 because that doesn't allow RSA key exchange. As written there's no problem, but it seems to me that if you add a condition saying to disallow RSA key exchange in section 5.1, this has the effect of implicitly rebuking this approach from section 5.3. That would be a little bit silly in a single document but it's even sillier when you recall that actually products in this space straddle both categories. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
On Wed, 19 Aug 2020 18:45:44 + Nancy Cam-Winget (ncamwing)" wrote: > Section 4.2 Encrypted Server Certificate describes a practice > which is inherently unsound. Passive inspection of the Certificate > message from TLS 1.2 or earlier isn't a reliable source of > information because a passive eavesdropper isn't able to discern > whether the X.509 document presented corresponds to this server or > not. The Client can confirm this using the TLS protocol but an > eavesdropper can't. So the change in TLS 1.3 does not impact the > practical security policy available, only an appearance is altered. > [NCW] The document describes what is in practice today with TLS 1.2 > and 1.1 whether we believe it is unsound or otherwise, it is what is > done today. It's not a problem for the document to describe today's practices but it's a mistake to label them "effective" if we know they are not. > Passive systems described throughout Section 5.1 fall to this same > error, using the phrase "reduced effectiveness" which the document > defines as not being "as effective on TLS 1.3 traffic" but in fact > since this practice didn't work, it will remain exactly as > effective (not at all) as before. > [NCW] Again, the document is describing what is in practice today. Describing something as "effective" when it is not effective isn't a matter of today's practice but of a misunderstanding of what's possible at all. > A related consequence passes into Section 5.2. Since the > Certificate message is only reliable for a Client, it has in fact > always been necessary to fully proxy the TLS session in order to rely > on this data, so this is not in fact an impact from TLS 1.3 but (if > it wasn't done previously for all versions) a vulnerability in such > products. [NCW] With TLS 1.2 the observer can see the handshake thru > completion with the Finished message before affecting a policy > decision. The passive eavesdropper can indeed see the handshake in TLS 1.2, but since they were not a participant they don't actually know what it means even though it wasn't encrypted. For example, suppose an RSA certificate is sent and the handshake seems to agree RSA key exchange and Client sends an EncryptedPreMasterSecret. The passive eavesdropper has no idea if that's actually encrypted to the RSA public key from the certificate, it's just an opaque blob. Thus it's easily possible for an eavesdropper to witness a handshake in which the eavesdropper believes what happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret to the local hospital both agreed this all worked fine and continue encrypted The eavesdropper's "Don't eavesdrop on people's medical stuff" policy kicks in and it allows the connection unmolested. Unfortunately what really happened is: Client proposed to do RSA key exchange Server showed a certificate for www.local-hospital.example Client sent an EncryptedPreMasterSecret for the GRU data exfiltration server ignoring the bogus certificate $5Bn of stolen commercial documents are uploaded to the server Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
I am not very familiar with IETF working group practices, however it strikes me as surely unusual to have a document enter Last Call (supposedly believed by its owners to be ready for publication) and yet immediately then be revised showing it was in fact not ready at all. However this seems to be what happened to draft-ietf-opsec-ns-impact. The below comments concern draft-ietf-opsec-ns-impact-02, the newer document. Section 4.1 Perfect Forward Secrecy ends: > TLS session data.ss I think this is a typographical error and the trailing "ss" should be removed from the document. If not it should be explained. Section 4.2 Encrypted Server Certificate describes a practice which is inherently unsound. Passive inspection of the Certificate message from TLS 1.2 or earlier isn't a reliable source of information because a passive eavesdropper isn't able to discern whether the X.509 document presented corresponds to this server or not. The Client can confirm this using the TLS protocol but an eavesdropper can't. So the change in TLS 1.3 does not impact the practical security policy available, only an appearance is altered. Passive systems described throughout Section 5.1 fall to this same error, using the phrase "reduced effectiveness" which the document defines as not being "as effective on TLS 1.3 traffic" but in fact since this practice didn't work, it will remain exactly as effective (not at all) as before. A related consequence passes into Section 5.2. Since the Certificate message is only reliable for a Client, it has in fact always been necessary to fully proxy the TLS session in order to rely on this data, so this is not in fact an impact from TLS 1.3 but (if it wasn't done previously for all versions) a vulnerability in such products. As it stands then, this document is misleading. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-camwinget-tls-use-cases-05 fix/remove §2.2.1
Hi, My impression from watching Tuesday's session is that this probably can't end up as a Working Group document, but nevertheless people seem to keep looking at it and so it's worth fixing errors. Eric Rescorla touched on this I think briefly, but I want to be more forthright: Section 2.2.1 of the draft-camwinget-tls-use-cases-05 document says: In TLS 1.2, the ClientHello, ServerHello and Certificate messages are all sent in clear-text, however in TLS 1.3, the Certificate message is encrypted thereby hiding the server identity from any intermediary. But the contents of Certificate are merely public data, an adversary can arrange for a server under their control to present any certificate of their choosing, thereby in fact hiding the server identity from any intermediary under prior versions of TLS too. If this document is to continue in any form, even as an individual submission, it should be updated to either erase 2.2.1 altogether and any "use cases" that rely on it, or make clear that this technique couldn't actually work in TLS anyway and is mentioned only because some products erroneously rely on it. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Mail regarding draft-ietf-tls-esni
In section 7.1 the -02 draft says: Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by attackers on the local network, which is a common case where SNI. Where SNI what? I'd be tempted to just say that yes, an active adversary can force you to choose between privacy and connectivity, and hard fail DNSSEC is the only existing way to choose privacy. The current text feels more like an attempt by people who don't want to face the Dancing Pig problem to justify why their latest seat-belt that snaps in a crash (to borrow Adam Langley's phrase) is a good idea anyway. But regardless of whether I'm correct about that, the sentence is confusing as it stands now. Nick. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
