Re: [TLS] Adoption Call for draft-davidben-tls-key-share-prediction
I support adoption On Sat, 4 May 2024, 00:05 Joseph Salowey, wrote: > This is a working group call for adoption > for draft-davidben-tls-key-share-prediction. This document was presented > at IET 118 and has undergone some revision based on feedback since then. > The current draft is available here: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/. > Please read the document and indicate if and why you support or do not > support adoption as a TLS working group item. If you support adoption > please, state if you will help review and contribute text to the document. > Please respond to this call by May 20, 2024. > > Thanks, > > Joe, Deidre, and Sean > ___ > 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] Adoption call for 'TLS 1.2 Feature Freeze'
I support adoption of this draft. On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly wrote: > At the TLS meeting at IETF 118 there was significant support for the draft > 'TLS 1.2 is in Feature Freeze' ( > https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This > call is to confirm this on the list. Please indicate if you support the > adoption of this draft and are willing to review and contribute text. If > you do not support adoption of this draft please indicate why. This call > will close on December 20, 2023. > > Thanks, > Deirdre, Joe, and Sean > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 deprecation and RFC 7627
Dear Martin, On Sat, 1 Apr 2023, 19:36 Martin Thomson, wrote: > On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote: > > Are the things like national-wide standards considered as new features > > (until they don't pretend to be Internet-wide standards)? > > I would not expect the IETF to be specifying national standards (that's an > obvious contradiction anyway). > > It is also unnecessary. The registration policies for TLS registries > allow people to register extensions without IETF involvement (unless you > consider IETF-appointed experts), so they should feel free to extend in any > way that makes them happy. > Right, but national standards often go through Independent stream > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.2 deprecation and RFC 7627
Dear Rich, Are the things like national-wide standards considered as new features (until they don't pretend to be Internet-wide standards)? On Fri, Mar 31, 2023 at 2:11 AM Salz, Rich wrote: > > FWIW, my plan for the draft (which I hope to submit for adoption within a > month) is to include text that says, basically, while no new features will be > ADDED to TLS 1.2, the WG may decide to deprecate or remove things that have > become security risks. I think it's better to keep specifics in separate > documents; ideally this one can be read, understood, and appreciated by those > not steeped in the gory technical details. > > On 3/31/23, 8:59 AM, "Martin Thomson" <mailto:m...@lowentropy.net>> wrote: > > > Just a thought, but in the discussion of TLS 1.2, we might start to consider > the use of TLS 1.2 **without the session hash/EMS** extension to be > deprecated sooner. RFC 7627 basically rescued TLS 1.2 from a whole swathe of > problems; so maybe requiring it (or not supporting TLS 1.2 if that cannot be > negotiated) offers a short term step toward eventual deprecation, while > allowing those who find themselves stuck on TLS 1.2 more time to adjust. > > > ___ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!UNB0h17Crh0iXqtbjQkhlf5180NWCg6SrAVjadF2H-Era8IqokFYAERHtHrNs3kfu9iwp7h9kw$ > > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!UNB0h17Crh0iXqtbjQkhlf5180NWCg6SrAVjadF2H-Era8IqokFYAERHtHrNs3kfu9iwp7h9kw$> > > > > _______ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXTERNAL] Opt-in schema for client identification
On Fri, 16 Sep 2022, 21:35 Andrei Popov, wrote: > >- - processing of invalid session ID, if it is repeated in the 2nd >attempt, can be omitted using a smaller cache on the server side > > Invalid session ID should not lead to handshake failure; it results in a > full handshake and an updated session ID/ticket. > > > Fair point. > >- - a server having more than one valid certificate for the domain >name, can switch between them in various attempts. > > Sure, but arguably TLS has reasonable methods for driving certificate > selection, in terms of signature/hash suites. > TLS doesn't have methods for selecting RSA key length. Too short keys may be rejected by client, and using long key always is too expensive when done for each handshake. > > >- A cleartext correlator between different requests like this would >also be a privacy concern and seems to run counter to the work in RFC 8446, >appendix C.4. > > Correct. I’m trying to see what the use-case would be, regardless of the > proposed design. > > > > *From:* Dmitry Belyavsky > *Sent:* Friday, September 16, 2022 12:01 PM > *To:* David Benjamin > *Cc:* Andrei Popov ; TLS Mailing List < > tls@ietf.org> > *Subject:* Re: [TLS] [EXTERNAL] Opt-in schema for client identification > > > > From the top of my head I can imagine 2 sort of real-life scenarios: > > > > - processing of invalid session ID, if it is repeated in the 2nd attempt, > can be omitted using a smaller cache on the server side > > - a server having more than one valid certificate for the domain name, can > switch between them in various attempts. > > > > I agree with Andrei that other parameters are chosen either according to > client or to the server preferences. > > > > On Fri, Sep 16, 2022 at 8:53 PM David Benjamin > wrote: > > I too am not seeing the use case here. Could you elaborate? > > > > Since browsers were mentioned as an example, when Chrome makes several > connections in a row (e.g. to measure impacts of a removal more > accurately), we generally do *not* expect the server to change its > selection algorithm across the two connections. A cleartext correlator > between different requests like this would also be a privacy concern and > seems to run counter to the work in RFC 8446, appendix C.4. > > > > On Fri, Sep 16, 2022 at 10:09 AM Andrei Popov 40microsoft@dmarc.ietf.org> wrote: > > >- Server can distinguish the client and alter some parameters in >response to make the new connection successful. > > A TLS server would typically choose either server-preferred parameters > (cipher suite, EC curve, etc.) among those advertised by the client, or > honor the client’s preferences. > > Can you give some examples of what a TLS server would alter, to make the > new connection successful, assuming the 2nd ClientHello has the same list > of options as the 1st one? > > Basically, what types of interop failures is this cookie intended to > resolve? > > > >- Modern real-life applications (e.g. browsers) may perform >several handshakes in a row until the connection to the server is finally >rejected. > > Some TLS clients will vary their offered TLS parameters between these > connection attempts. > > > > Cheers, > > > > Andrei > > > > *From:* TLS *On Behalf Of *Dmitry Belyavsky > *Sent:* Friday, September 16, 2022 4:32 AM > *To:* TLS Mailing List > *Subject:* [EXTERNAL] [TLS] Opt-in schema for client identification > > > > Dear colleagues, > > > > I'd like to suggest an opt-in cookie-style schema allowing the server to > identify the client in case when a client performs several unsuccessful > connection attempts. > > > > Modern real-life applications (e.g. browsers) may perform > several handshakes in a row until the connection to the server is finally > rejected. It may make sense to provide different handshake parameters on > the server side on the consequent attempts. > > > > To distinguish the same client from several different clients, it may be > useful to add a cookie-style extension in ClientHello. The server responds > with an encrypted extension containing a random value in a ServerHello. If > the connection fails, a client may send a value received from the server in > the next connection attempt. Server can distinguish the client and alter > some parameters in response to make the new connection successful. > > > > The schema differs from the current session/tickets mechanism because the > current mechanism implies session resumption only for successfully > completed handshakes. > > > > As
Re: [TLS] [EXTERNAL] Opt-in schema for client identification
>From the top of my head I can imagine 2 sort of real-life scenarios: - processing of invalid session ID, if it is repeated in the 2nd attempt, can be omitted using a smaller cache on the server side - a server having more than one valid certificate for the domain name, can switch between them in various attempts. I agree with Andrei that other parameters are chosen either according to client or to the server preferences. On Fri, Sep 16, 2022 at 8:53 PM David Benjamin wrote: > I too am not seeing the use case here. Could you elaborate? > > Since browsers were mentioned as an example, when Chrome makes several > connections in a row (e.g. to measure impacts of a removal more > accurately), we generally do *not* expect the server to change its > selection algorithm across the two connections. A cleartext correlator > between different requests like this would also be a privacy concern and > seems to run counter to the work in RFC 8446, appendix C.4. > > On Fri, Sep 16, 2022 at 10:09 AM Andrei Popov 40microsoft@dmarc.ietf.org> wrote: > >> >>- Server can distinguish the client and alter some parameters in >>response to make the new connection successful. >> >> A TLS server would typically choose either server-preferred parameters >> (cipher suite, EC curve, etc.) among those advertised by the client, or >> honor the client’s preferences. >> >> Can you give some examples of what a TLS server would alter, to make the >> new connection successful, assuming the 2nd ClientHello has the same list >> of options as the 1st one? >> >> Basically, what types of interop failures is this cookie intended to >> resolve? >> >> >> >>- Modern real-life applications (e.g. browsers) may perform >>several handshakes in a row until the connection to the server is finally >>rejected. >> >> Some TLS clients will vary their offered TLS parameters between these >> connection attempts. >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> *From:* TLS *On Behalf Of * Dmitry Belyavsky >> *Sent:* Friday, September 16, 2022 4:32 AM >> *To:* TLS Mailing List >> *Subject:* [EXTERNAL] [TLS] Opt-in schema for client identification >> >> >> >> Dear colleagues, >> >> >> >> I'd like to suggest an opt-in cookie-style schema allowing the server to >> identify the client in case when a client performs several unsuccessful >> connection attempts. >> >> >> >> Modern real-life applications (e.g. browsers) may perform >> several handshakes in a row until the connection to the server is finally >> rejected. It may make sense to provide different handshake parameters on >> the server side on the consequent attempts. >> >> >> >> To distinguish the same client from several different clients, it may be >> useful to add a cookie-style extension in ClientHello. The server responds >> with an encrypted extension containing a random value in a ServerHello. If >> the connection fails, a client may send a value received from the server in >> the next connection attempt. Server can distinguish the client and alter >> some parameters in response to make the new connection successful. >> >> >> >> The schema differs from the current session/tickets mechanism because the >> current mechanism implies session resumption only for successfully >> completed handshakes. >> >> >> >> As the schema is opt-in, it doesn't provide any extra surveillance >> opportunities. >> >> >> >> I understand that the proposed schema may badly work with CDNs. >> >> >> >> If there is an interest to my proposal, I could draft it and present on >> the upcoming IETF meeting. >> >> >> >> -- >> >> SY, Dmitry Belyavsky >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Opt-in schema for client identification
Dear colleagues, I'd like to suggest an opt-in cookie-style schema allowing the server to identify the client in case when a client performs several unsuccessful connection attempts. Modern real-life applications (e.g. browsers) may perform several handshakes in a row until the connection to the server is finally rejected. It may make sense to provide different handshake parameters on the server side on the consequent attempts. To distinguish the same client from several different clients, it may be useful to add a cookie-style extension in ClientHello. The server responds with an encrypted extension containing a random value in a ServerHello. If the connection fails, a client may send a value received from the server in the next connection attempt. Server can distinguish the client and alter some parameters in response to make the new connection successful. The schema differs from the current session/tickets mechanism because the current mechanism implies session resumption only for successfully completed handshakes. As the schema is opt-in, it doesn't provide any extra surveillance opportunities. I understand that the proposed schema may badly work with CDNs. If there is an interest to my proposal, I could draft it and present on the upcoming IETF meeting. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] What is "completed handshake"?
Dear colleagues, RFC 8446 refers to "completed handshake" as a prerequisite for some messages. But looking for the word "completed", I don't see any definition. Could you please point me to it (and probably, include this definition into rfc8446-bis)? Many thanks! -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What's it called
Dear Rich, Rekeying (https://datatracker.ietf.org/doc/html/rfc8645). For GOST, the "key meshing" term at least was in use. On Thu, Jun 24, 2021 at 7:32 PM Salz, Rich wrote: > I’m blanking on a term and web searches turn up too much useless info. > > > > What is it called when we have to start using a new symmetric key because > we’ve encrypted too much data with the old one? Key exhaustion fits, but > probably isn’t it. > > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Static DH timing attack
I also want to remind about so called "Enterprise TLS" — if I remember correctly, they introduced this bug to their modified TLS 1.3 specification... ср, 9 сент. 2020 г., 18:04 Salz, Rich : > https://raccoon-attack.com/ > > > > Do we need a short RFC saying “do not use static DH” ? > > > > I am probably not the only one thinking fondly of > draft-green-tls-static-dh-in-tls13 now. > > > ___ > 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
I just want to remind you about my FakeSNI draft https://tools.ietf.org/html/draft-belyavskiy-fakesni-02 The idea behind it was cheating the solutions less sophisticated than GFW. Yes, in real life it will require deep cooperation between DNS and hosting and yes, the resource still can be blocked by IP (with all collateral damage). On Sun, Aug 9, 2020 at 8:15 PM Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote: > I’m pretty sure your reasoning is wrong. In the ideal world, if > *everybody* enabled ESNI - then *maybe* the GFW would relent. > > The way things are - is not smart pretending reality is not what it is. > > Using your terminology - better blend with the crowd, because you aren’t > likely to live long enough to see the crowd change to match you. > > There are a lot of technical details why the whole crowd won’t change > regardless of your wishes - e.g., who controls TLS implementations in > various devices - but I won’t go there. > > Regards, > Uri > > > On Aug 9, 2020, at 11:36, David Fifield wrote: > > > > On Thu, Jul 30, 2020 at 11:16:50AM -0700, Christian Huitema wrote: > >> Thanks for the report. I think this relates to our ambivalence about the > >> requirement for ESNI to not "stick out". That requirement is hard to > >> meet, and designs have drifted towards an acceptation that it is OK to > >> stick out as long as a sufficiently large share of the traffic does it.. > >> If that share is large, goes the reasoning, it would be too costly for > >> censors to just "drop everything that looks like ESNI". Well, given > >> actors like the Great Firewall, one wonders. > > > > There's nothing wrong with that reasoning, in my opinion. To blend in > > with a crowd, you can change yourself to match the crowd; or you can > > change the crowd to match yourself. My feeling is that ESNI is currently > > easy to block (or to put it in terms I like, *inexpensive* to block) > > because very few TLS connections use it--nothing valuable depends on it > > yet. Whereas if encrypted SNI were somehow deployed suddenly and > > massively such that it became a normal feature of TLS connections both > > essential and inessential, it would be more difficult (read: expensive) > > to block. > > > > After all, even the GFW is not all-powerful. Surely it would prefer to > > abolish TLS altogether, but it's too late for that. At this point, > > blocking TLS would cost too much--not in terms of implementing firewall > > rules, but in how much essential communication it would damage. Put > > another way, the GFW itself, and the people who operate/manage it, would > > feel some of the pain of blocking. > > > > I don't mean to imply that coordinated deployment is the only path to > > success, just saying that if SNI encryption were already widespread, > > even an obvious tag like 0xffce would not be a useful distinguisher. And > > though I find it useful to think of these things in terms of the costs > > of overblocking, it's not an infallible guide. A large organization like > > the GFW is made up of many conflicting motivations, and it is as prone > > as any other to making bad decisions and enacting policies that are > > evidently against its own interests. For that reason I believe it's > > possible to reduce the risk surrounding the deployment of encrypted SNI, > > but not eliminate it completely. > > > > ___ > > 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 > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Re-chartering TLS
Dear Christopher, On Fri, Jan 17, 2020 at 6:32 AM Christopher Wood wrote: > Hi folks, > > As discussed in Singapore, it's time to re-charter the working group to > reflect ongoing (e.g., Exported Authenticators and Encrypted SNI/CH) and > future work (e.g., cTLS). For reference, the current charter is available > here: > >https://datatracker.ietf.org/doc/charter-ietf-tls/ > > A draft of the new charter is below, and also available on GitHub [1]. > Please have a look and and send comments, either here on the mailing list > or in the GitHub repo, by 2359 UTC on 30 January 2020. Any and all feedback > is welcome! We would like to complete this in advance of IETF 107 so we can > move forward with items such as cTLS. > > ~~~ > The TLS (Transport Layer Security) working group was established in 1996 > to standardize a 'transport layer' security protocol. The basis for the > work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group > has completed a series of specifications that describe the TLS protocol > v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and > DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 > [draft-ietf-tls-dtls13], as well as extensions to the protocols and > ciphersuites. > > The working group aims to achieve three goals. First, improve the > applicability and suitability of the TLS family of protocols for use in > emerging protocols and use cases. This includes extensions or changes that > help protocols better use TLS as an authenticated key exchange protocol, or > extensions that help protocols better leverage TLS security properties, > such as Exported Authenticators. Extensions that focus specifically on > protocol extensibility are also in scope. This goal also includes protocol > changes that reduce the size of TLS without affecting security. Extensions > that help reduce TLS handshake size meet this criteria. > I think it's worth replacing "the size" with "the resource consumption" in the description of this goal. Otherwise, the tls-batch-signing draft ( https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/) may be left out of the scope of the charter. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-rescorla-tls-ctls
I support the adoption. On Thu, Nov 21, 2019 at 8:36 AM Sean Turner wrote: > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be > adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile > it, as appropriate. The authors revised cTLS and presented the revised > draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS > as a WG item. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ESNIKeys.public_name vs. cleartext SNI
Dear Stephen, I published a draft describing "Fake SNI" designed for the same purpose. It allows (at least in theory) to cheat those who blocks all the handshakes containing ESNI. вс, 28 июля 2019 г., 15:25 Stephen Farrell : > > Hiya, > > ESNI drafts -03 and -04 envisage that the ESNIKeys.public_name > and the TLS h/s cleartext SNI are the same. I'd expect that > they mostly will be. > > But they don't have to be. A client could provide a way to > use a client-chosen cleartext SNI when using ESNI to encrypt > the real SNI. > > For example, my openssl build allows this for s_client. I've > a colleague who's got a first build of curl using that that > also allows such a local over-ride. I think other command-line > clients might be likely to also support that kind of thing, if > for no other reason than the existence of the draft-02 version > that's deployed and has no public_name. But I guess being able > to do a local over-ride may also be generally useful, while > not being so useful for web browsers. For example, if a given > public_name value is being censored, clients might at that > point want to use something else. > > On the server side, my code also make no checks that the > cleartext SNI used was the same as the public_name. And I > don't think that causes any problems, so maybe ought be > allowed too. > > I don't think allowing this (if the WG decide to) requires > any major change to the spec, but there are a couple of > language changes needed in section 5.1.3 and I guess we > should add a sentence to the effect that using the public_name > value from ESNIKeys in the cleartext SNI is recommended > if you've no other value but is not required. > > Cheers, > S. > ___ > 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] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
On Wed, Feb 20, 2019 at 10:35 AM Dmitry Belyavsky wrote: > > > On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann > wrote: > >> Dmitry Belyavsky writes: >> >> >Fake SNI is delivered out-of-band for the handshake >> >> But then won't the DPI check the out-of-band source as well? If you've >> got a >> MITM sitting there then they can do the same lookups and whatnot that the >> client does, unless you're relying on the client being off-path, which >> seems a >> bit of a leap. You'd need to implement it via some sort of subliminal >> signalling mechanism that the DPI can't detect. >> >> > In fact if DPI begins to poll domains whether FakeSNI record is present, > we have a race between changing the value in FakeSNI and DPI polling. > And DoH/DoT ensures that DPI has to poll. > > Let me clarify. I understand that the solution I propose is not perfect. But there is no silver bullet, and this is just another way to make a life of DPI harder. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
On Wed, Feb 20, 2019 at 10:21 AM Peter Gutmann wrote: > Dmitry Belyavsky writes: > > >Fake SNI is delivered out-of-band for the handshake > > But then won't the DPI check the out-of-band source as well? If you've > got a > MITM sitting there then they can do the same lookups and whatnot that the > client does, unless you're relying on the client being off-path, which > seems a > bit of a leap. You'd need to implement it via some sort of subliminal > signalling mechanism that the DPI can't detect. > > In fact if DPI begins to poll domains whether FakeSNI record is present, we have a race between changing the value in FakeSNI and DPI polling. And DoH/DoT ensures that DPI has to poll. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
Dear Peter, On Wed, Feb 20, 2019 at 6:43 AM Peter Gutmann wrote: > Dmitry Belyavsky writes: > > >The draft describes a Fake SNI mechanism intended to cheat DPI systems in > a > >case when a DPI system blocks the connection if ESNI is present. > > Since this mechanism advertises the fact that a fake SNI is present, > wouldn't > the DPI then also block the connection for that? > The suggested mechanism does not advertise the presence of a Fake SNI. Fake SNI is delivered out-of-band for the handshake and an observer has to discover that ClientHello message contains a SNI extension that does not match to any host present at the IP address where we try to connect. Passive collection and blocking the Fake SNI values also has little sense because the value can be changed relatively easily. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
Hello, Please take a look at an initial submission of the draft. The draft describes a Fake SNI mechanism intended to cheat DPI systems in a case when a DPI system blocks the connection if ESNI is present. -- Forwarded message - From: Date: Tue, Feb 19, 2019 at 10:43 PM Subject: New Version Notification for draft-belyavskiy-fakesni-00.txt To: Dmitry Belyavskiy A new version of I-D, draft-belyavskiy-fakesni-00.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-fakesni Revision: 00 Title: Fake Server Name Indication Document date: 2019-02-19 Group: Individual Submission Pages: 3 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-fakesni-00.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-fakesni/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-fakesni-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-fakesni Abstract: The document provides a specification of the Fake Server Name Indication. Being implemented, the Fake SNI specification provides a way to work around the monitoring solutions without providing any additional information to external observers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
On Sat, Dec 1, 2018 at 6:59 PM Tony Arcieri wrote: > This does not seem to address a problem which was brought up when the > similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any > system in possession of one of the non-ephemeral-ECDHE private keys, > ostensibly for the purposes of passive traffic decryption, can arbitrarily > resume decrypted sessions and therefore impersonate any observed clients. > > I'm not a fan of systems like this, but I believe for security reasons > they should be designed in such a way that only the confidentiality of > traffic is impacted, and a "visibility" system isn't able to leverage the > decrypted traffic to resume decrypted sessions and thereby impersonate > clients. > I do not understand why the ETSI solution does not provide ability to impersonate clients/servers. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ETSI releases standards for enterprise security and data centre management
Dear All, JFYI. Via Feisti Duck nerwsletter. https://www.etsi.org/news-events/news/1358-2018-11-press-etsi-releases-standards-for-enterprise-security-and-data-centre-management The eTLS key exchange shall use exactly the same messages and procedures to establish a set of session keys as a TLS 1.3 ephemeral Diffie-Hellman key exchange, except for two differences [2]. 1) the server shall use a static public/private key pair at Step 2 in clause 4.3.1; and 2) the server's certificate at Step 5 shall contain visibility information as defined in clause 4.3.3 to indicate to the client that eTLS is in use. NOTE: Neither the static public key nor the visibility information affects the operation of a TLS 1.3 compliant client, so an eTLS server is therefore fully interoperable with TLS 1.3 compliant clients. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
Hello, пт, 9 нояб. 2018 г., 7:03 Ryan Carboni rya...@gmail.com: > I think I have implied that ClientHello is unneccesary to an extent, it > can be replaced by a DNS TXT record. > > I think I implied that self-signed certificates are acceptable given the > precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence > of DNS spoofing attacks against a CA?). > Sure. At least this proof-of-concept one. https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
Hello, On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich <rs...@akamai.com> wrote: > > > With this in mind, I'm voting in favor of any re-branding of TLS 1.3 > where the > > protocol name remains "TLS" and major version becomes > 1. > > Me too. > > +1 -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3DES diediedie
Hello all, Regarding the discussion of the Sweet32 attack, it's worth mentioning that there is a specification of so called key meshing for the Russian GOST cipher (which has 64-bit block as well). Key meshing is a procedure of a predictable change of the current key after processing an certain amount of data. It is described in RFC 4357, Section 2.3 ( https://tools.ietf.org/html/rfc4357#section-2.3). This key meshing defends against any attack that uses a big portion of data encrypted with the same key. May be it is useful to specify the similar procedure for modern ciphers too. On Thu, Aug 25, 2016 at 5:08 AM, Tony Arcieri <basc...@gmail.com> wrote: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"? > > I believe 3DES is MTI for TLS 1.0/1.1(?) but I think it would make sense > for it to be banned from TLS 1.3. > > [*] Lest anyone claim the contrary, I am not surprised by this attack, and > have pushed to have 3DES removed from TLS prior to the publication of this > attack, and can probably find a TLS implementer who can back me up on that. > > -- > Tony Arcieri > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
Dear Sean, I support the plan in general, but I think that we need to separately indicate that a particular algorithm/ciphersuite is not just "Not recommended" but found insecure. Thank you! On Wed, Mar 30, 2016 at 4:53 AM, Sean Turner <s...@sn3rd.com> wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for > cipher suites to allow anyone with a stable, publicly available, peer > reviewed reference document to request and get a code point and to add an > “IETF Recommended” column to the registry. This change is motivated by the > large # of requests received for code points [0], the need to alter the > incorrect perception that getting a code point somehow legitimizes the > suite/algorithm, and to help implementers out. We need to determine > whether we have consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be > changed to specification required. > > 2. A new “IETF Recommended” column will be added with two values: “Y” or > “N”. Y and N have the following meaning: > > Cipher suites marked with a “Y” the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > “N”. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that > matches the above so that the same information is available to those who > don’t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
Dear Bryan, On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford <brynosau...@gmail.com> wrote: > Hi Dmitry, > > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the important question of whether this (new) > proposal > > could be made to work in the context of DTLS. For the DTLS case, my > > current thinking is that some elements of my earlier proposal is > > probably more suitable: namely using a stream cipher (or AEAD used > as a > > stream cipher) to encrypt and recognize the explicitly-transmitted > > sequence numbers that DTLS needs. This could operate basically the > same > > as I described in my earlier E-mail on this topic. Note that the > length > > field is no longer a problem in DTLS as it is in TLS, because the > > receiver already gets the length of the datagram from UDP. > > > > > > Do I understand correctly that your propose makes difficult to derive > > the key from the original value depending on the sequence number? > > I'm not sure I understand your question; can you clarify? What is the > "original value" you are worried about the key being derivable from? > Certainly if the cipher (stream cipher or AEAD) is working correctly, it > should make it cryptographically infeasible for an attacker to derive > the shared secret key from anything the protocol transmits. > I mean something like http://tools.ietf.org/html/rfc4357#section-7 We have the keys calculated during the handshake and want to modify it for each record. -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
Dear Bryan, On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <brynosau...@gmail.com> wrote: DTLS: > > Now there's still the important question of whether this (new) proposal > could be made to work in the context of DTLS. For the DTLS case, my > current thinking is that some elements of my earlier proposal is > probably more suitable: namely using a stream cipher (or AEAD used as a > stream cipher) to encrypt and recognize the explicitly-transmitted > sequence numbers that DTLS needs. This could operate basically the same > as I described in my earlier E-mail on this topic. Note that the length > field is no longer a problem in DTLS as it is in TLS, because the > receiver already gets the length of the datagram from UDP. > > Do I understand correctly that your propose makes difficult to derive the key from the original value depending on the sequence number? -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
