[TLS] comments on draft-subcerts
Dear, list, Sorry for sending this past the last call. Few comments on the draft, which are: - On Section 1: "For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC"." I think this sentence can be their own paragraph, so it does not get lost with the rest of the text. It will be good to clarify as well the usage of 'credential', 'delegation', 'delegator' terms used through out the document. It will be really nice to clarify the term 'credential' as it sometimes seems to be used to refer to 'delegated credential', and sometimes to the 'Credential' struct. - On section 7.3 "Delegated credentials do not provide any additional form of early revocation. Since it is short lived, the expiry of the delegated credential would revoke the credential. Revocation of the long term private key that signs the delegated credential also implicitly revokes the delegated credential." Not sure how the implicit revocation will work. It is my understanding that the sole way to check that a DC is revoked is by verifying its valid time, and this is the way that renders it 'invalid'. Maybe, the DC is valid until it expires regardless if the long-term private key is revoked, as I don't see a way to mark the DC invalid when the long-term private key revokes. But perhaps, I'm understanding this incorrectly. In that case, how the DC signed by a revoked key will be treated? Should it wait until they expire to render them completely explicitly invalid? I have other minor editorial changes that I'll send as a PR. Thanks! -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD 4558 91BB 6B45 6F44 2D02 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] On SNI and middleboxes
Dear list, Two of my colleagues, Morten Marstrander and Matteo Malvica, just published a bit of research on using the SNI field to bypass middleboxes for TLS inspection / filtering. They’ve made a nice writeup and PoC (linked below), which also gives some insight into how these solutions are commonly implemented. The work reminds me of several previous discussions on this list, and I hope it may be of interest. The quick summary is that middleboxes working as a half-open proxy often let the ClientHello through, even for disallowed domains, and that the content of those packets is not necessarily logged and alerted quite as one might expect. So they use the SNI to establish a 2-way channel that is basically invisible to the monitoring solution. Not sure if they’ve also looked into the particulars of TLS 1.3 and ESNI, otherwise that might be a good follow-up topic. I put Morten on CC, he can provide additional technical details. Products from Palo Alto, F5, and Fortinet were successfully bypassed in the lab. I expect that there are additional bug-compatible solutions out there. References: * Blogpost: https://www.mnemonic.no/blog/introducing-snicat * PoC tool: https://github.com/mnemonic-no/SNIcat * Vendor advisory: https://support.f5.com/csp/article/K2010 * Vendor advisory: https://security.paloaltonetworks.com/CVE-2020-2035 Kind regards, Tor E. Bjørstad ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Draft minutes for TLS at IETF 108
From: Benjamin Kaduk Sent: 11 August 2020 18:06 On Wed, Aug 05, 2020 at 10:30:39AM +, tom petch wrote: > From: TLS on behalf of Christopher Wood > > Sent: 04 August 2020 19:16 > > The official minutes are now up: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e= > > > What is Benjamin talking about at the end? > > It looks as if you are proposing action on all or some RFC that have TLS 1.0 > or 1.1 as MTI, related to oldversions-deprecate but that is a guess from > reading between the lines and that topic is a live one for me so I would > appreciate clarity. oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or 1.1 as MTI (there are some 80-odd documents in the Updates: header). The particular itesm I was mentioning in the meeting relate to various subsets of those documents that may need some additional handling on top of the basic "don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content of the updates. Details are at https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ So: - RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the document as a whole should be historic - The downgrade-detection SCSV of RFC 7507 is probably in a similar boat - We should be more clear about "if the document being updated says you MUST use TLS 1.0/1.1, that part is removed" Benjamin This is the bit I could not guess; the rest of the minutes I could guess but your explanation is much easier to understand. I have been tracking 'diediedie', including the AD review, since it first appeared and more a comment on that for Kathleen and Stephen is that RFC5953 does not get a mention although since it is Obsoleted and the Normative Reference is to RFC4347 then that is a category that does not seem to fit in any of the paragraphs of the I-D; Obsolete and TLS1.0 yes, Obsolete and DTLS1.0 no. RFC6353 I did expect to find; Internet Standard, STD0078, Normative Reference to RFC4347; the Security Considerations of that RFC say 'MUST NOT negotiate SSL 2.0' which might not be considered sufficiently strong for 2020 but how do you update a Standard? Tom Petch - No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers are no longer considered very good) Were there additional specific items you were unsure about? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fw: Draft minutes for TLS at IETF 108
Kathleen I have some thoughts below on RFC5953 and RFC6353 which I cannot find in deprecate but thought that I would. Tom Petch From: TLS on behalf of tom petch Sent: 13 August 2020 12:33 To: Benjamin Kaduk Cc: TLS Chairs; TLS@ietf.org Subject: Re: [TLS] Draft minutes for TLS at IETF 108 From: Benjamin Kaduk Sent: 11 August 2020 18:06 On Wed, Aug 05, 2020 at 10:30:39AM +, tom petch wrote: > From: TLS on behalf of Christopher Wood > > Sent: 04 August 2020 19:16 > > The official minutes are now up: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e= > > > What is Benjamin talking about at the end? > > It looks as if you are proposing action on all or some RFC that have TLS 1.0 > or 1.1 as MTI, related to oldversions-deprecate but that is a guess from > reading between the lines and that topic is a live one for me so I would > appreciate clarity. oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or 1.1 as MTI (there are some 80-odd documents in the Updates: header). The particular itesm I was mentioning in the meeting relate to various subsets of those documents that may need some additional handling on top of the basic "don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content of the updates. Details are at https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ So: - RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the document as a whole should be historic - The downgrade-detection SCSV of RFC 7507 is probably in a similar boat - We should be more clear about "if the document being updated says you MUST use TLS 1.0/1.1, that part is removed" Benjamin This is the bit I could not guess; the rest of the minutes I could guess but your explanation is much easier to understand. I have been tracking 'diediedie', including the AD review, since it first appeared and more a comment on that for Kathleen and Stephen is that RFC5953 does not get a mention although since it is Obsoleted and the Normative Reference is to RFC4347 then that is a category that does not seem to fit in any of the paragraphs of the I-D; Obsolete and TLS1.0 yes, Obsolete and DTLS1.0 no. RFC6353 I did expect to find; Internet Standard, STD0078, Normative Reference to RFC4347; the Security Considerations of that RFC say 'MUST NOT negotiate SSL 2.0' which might not be considered sufficiently strong for 2020 but how do you update a Standard? Tom Petch - No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers are no longer considered very good) Were there additional specific items you were unsure about? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote: > Most of the functions of the Great Firewall work bidirectionally, and > the ESNI detection and blocking are no exception. Sending an > ESNI-containing ClientHello from *outside* of China to a server > *inside* results in temporary blocking, just the same as sending one > from the inside to the outside. This makes it easy to experiment with, > even if you don't control a host in China. Triggering blocking from the outside no longer works. ESNI connections that originate inside the firewall are still blocked. This was first observed by GFW report, who were able to isolate the change from bidirectionality to unidirectional to a five-minute window: between 06:27 and 06:32 UTC on 2020-08-13. I tried it myself, and I confirm that I am not now able to trigger ESNI blocking from outside the firewall. https://github.com/net4people/bbs/issues/43#issuecomment-673322409 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06
Hi Kathleen,
Also inline.
On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> Hi Ben,
>
> Thanks for your review. Some initial responses are inline.
>
> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk wrote:
>
> > Thanks for putting together the -06 based on my preliminary comments, and
> > my apologies for taking so long to get back to it. It turns out that going
> > through the 80-odd documents we update takes a while!
> >
> >
> > I have a bunch of suggestions that are basically editorial, that I'll
> > make a pull request for (along with suggested changes for several of the
> > following comments). It's up at:
> > https://github.com/tlswg/oldversions-deprecate/pull/3
>
>
> Thanks for that!
>
> >
> >
> > We mention in the Abstract (but not Introduction!) that this document
> > moves 2246 and 4346 (but not 6347!) to the historic state.
> > Unfortunately, this is slightly problematic from a process perspective,
> > since the current way to make things Historic
> > (
> > https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20
> > )
> > requires a separate "status change document" that gets its own IETF LC,
> > to effectuate the status change. Most references to the status change
> > document can be replaced by this RFC after it's published, but formally
> > the move to historic is *not* done by this document. I've pulled into
> > my pull request the language used in RFC 8429 to describe moves to
> > Historic; please make sure to reproduce that language in the
> > Introduction as well as the Abstract.
> >
>
> Do you need us to submit a draft to request that status change?
No -- it's done purely in the datatracker without an I-D, so I will plan to
do that. (Unfortunately, it has to be one status-change document per
status-change, so it'll be a lot of clicking for me, but that's life.)
> >
> > I found three documents (3656, 4540, 7562) in the list of update targets
> > that are on the ISE (not IETF) stream. I had talked to Adrian during my
> > preliminary review, and in principle it is permissible to make those
> > updates as part of this document, but we will need specific ISE approval
> > to do so. I am supposed to sync up with him during IETF LC, but the
> > document needs to be updated to clarify that the updates of ISE
> > documents are/will be done with permission of the ISE. (Please also try
> > to double-check that the list is complete; I didn't find an
> > authoritative list of "all documents on the ISE stream" to grep against,
> > and I didn't try to have something parse rfc-index.xml to output such a
> > list.
> >
>
> OK, so you'd like a list added and that's not in your pull request, is that
> right? We'll figure it out. Thanks in advance with the coordination with
> Adrian.
That's correct, this is not in my pull request (not least because that list
of three documents is incomplete -- I sent a more-likely-complete list of 6
documents in an off-list follow-up.
https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent&page=All
will get a (presumably authoritative) list of ISE-stream documents, FWIW.
>
> >
> > I note that in addition to our BCP 195 update (called out in Section 6),
> > we also update 3552, which is BCP 72. This update is quite incidental
> > (compared to our BCP 195 update), so it seems clear that having this
> > document be part of BCP 195 is correct.
> >
>
> Are you asking here to include an update to RFC3552? Thanks.
No change needed here, I think -- just noting that we already list RFC 3552
as being updated, but that we don't need to be part of BCP 72, since the
update in question is largely incidental.
> >
> > Section 1.1
> >
> > I went through all 83 of the references in the big list, that are
> > supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> > as well as the shorter list of already-obsoleted documents.
> >
> > I won't bore you with my full notes, but there are some particular
> > things that stood out from the review:
> >
> > - We have a separate list of updates for documents that are already
> > obsolete (but don't say much about why we're going go the extra
> > bother). However, three of the documents in our main list of updates
> > (4743, 4744, and 6460) are already Historic, and presumably should be
> > treated more like the already-obsolete ones.
> >
>
> Obsolete does not mean the same thing as deprecate though. TLSv1.2 has
> been obsoleted by TLSv1.3, but not deprecated. The deprecation goes the
> extra step to say not to use it and it triggers many to begin phase out
> plans. Am I misunderstanding the question?
I think you're misunderstanding the question, yes, sorry.
I think we want the documents that are Historic to be listed separately
from the other ("regular") updates, in a manner akin to what is already
done for the documents that are currently obsolete. Or, perhaps, to say
that there is no point in deprecating something
[TLS] Handshake-level vs record-level padding in TLS ECH
Hi all, In discussing ECH (draft-ietf-tls-esni) with some QUIC folks, we identified some places where the extension would not easily apply to QUIC unmodified. One of them is ECH’s integration of handshake information (anonymity set of certificates, etc.) with TLS record-level padding. Since QUIC both replaces the record layer and runs over UDP, that means this padding crosses TLS/QUIC public APIs and must be integrated into QUIC retransmission logic. I wrote some notes up in the GitHub issue here: https://github.com/tlswg/draft-ietf-tls-esni/issues/264 I wanted to find out both WGs’ thoughts on how to handle padding here, as it seems we have a mismatch between the interfaces TLS assumes and QUIC provides. The HTTP/3 draft briefly mentions a similar issue and has its own stream-level padding story alongside the transport-level one. https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-padding-and-traffic-analysi We could match that in ECH, which would remove the need for TLS and QUIC to coordinate here but adds another padding mechanism. Or we could leave things as-is, which means ECH will require folks to add a parameter to their TLS/QUIC APIs and then implement more complex retransmission logic before usefully deploying ECH. (Something that should probably be reflected in the QUIC spec.) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
Weird. Thanks for the update. How are you confirming that it's blocked from inside-out? > On Aug 13, 2020, at 10:30 AM, David Fifield wrote: > > On Fri, Aug 07, 2020 at 05:56:30PM -0600, David Fifield wrote: >> Most of the functions of the Great Firewall work bidirectionally, and >> the ESNI detection and blocking are no exception. Sending an >> ESNI-containing ClientHello from *outside* of China to a server >> *inside* results in temporary blocking, just the same as sending one >> from the inside to the outside. This makes it easy to experiment with, >> even if you don't control a host in China. > > Triggering blocking from the outside no longer works. ESNI connections > that originate inside the firewall are still blocked. This was first > observed by GFW report, who were able to isolate the change from > bidirectionality to unidirectional to a five-minute window: between > 06:27 and 06:32 UTC on 2020-08-13. I tried it myself, and I confirm that > I am not now able to trigger ESNI blocking from outside the firewall. > https://github.com/net4people/bbs/issues/43#issuecomment-673322409 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible blocking of Encrypted SNI extension in China
On Thu, Aug 13, 2020 at 01:04:48PM -0700, Carrick Bartle wrote: > Weird. Thanks for the update. How are you confirming that it's blocked from > inside-out? I couldn't test it myself, so I am relying on the reports of colleagues in China. GFW Report is able to test directly from China. Measurement vantage points in China are tricky to get ahold of. A possible alternative is to use a reflected measurement system in the style of Quack, which uses infrastructural echo servers: https://censorbib.nymity.ch/#VanderSloot2018a https://www.usenix.org/conference/usenixsecurity18/presentation/vandersloot https://github.com/net4people/bbs/issues/2 Censored Planet does regular Quack measurements, but I don't think they are testing ESNI yet: https://censoredplanet.org/data/raw ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Open issues for draft-ietf-tls-esni
Hi list, Some of you might have noticed a barrage of issues filed recently against draft-ietf-tls-esni on GitHub. These are all relatively minor, but resolving some of them may require changes for the next draft, so I wanted to summarize them here. These were flagged while Chris Wood and I were working through some editorial changes. Links to the issues are given below, including a brief description. We'd welcome any feedback you might have on these. Thanks, Chris P. https://github.com/tlswg/draft-ietf-tls-esni/issues/261: The spec assumes that HPKE uses an HKDF cipher suite. https://github.com/tlswg/draft-ietf-tls-esni/issues/262: Possible bug in "outer_extensions" extension logic. https://github.com/tlswg/draft-ietf-tls-esni/issues/263: Role of the hash in "outer_extensions" is unclear. https://github.com/tlswg/draft-ietf-tls-esni/issues/265: Question about "outer_extensions" usage guidance. https://github.com/tlswg/draft-ietf-tls-esni/issues/266: Security considerations around SNI leakage. https://github.com/tlswg/draft-ietf-tls-esni/issues/267: "ech_accept" is undefined. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
