Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
Hi Nick, Please see inline On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: > I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. > > The grease_extension parameter shouldn't exist, and there should be no > special handling for GREASE values. GREASE doesn't need to be mentioned in > this draft, except to say that a client may send values (cipher suites, > extensions, named groups, signature algorithms, versions, key exchange > modes, ALPN identifiers, etc.) that are unknown to the middlebox and that > the middlebox MUST NOT reject connections with values unknown to the > middlebox. > The grease_extension parameter in the YANG model is a "boolean" type to indicate whether the GREASE values are offered by the client or not. The MUD YANG model does not convey the GREASE values. > (This can be stated without mentioning GREASE specifically.) > > There is also an issue where this draft does not describe how an observer > identifies whether a TLS ClientHello is compliant with a MUD profile. > For example, an alert could be triggered to quarantine and remediate the compromised device, and will update the draft to clarify. -Tiru > > On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd wrote: > >> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear >> wrote: >> > >> > >> > >> > My concern is not with "new extensions" per se. The hidden assumption >> here is that "extensions" are the only way TLS can evolve. In fact, future >> TLS versions are not constrained to evolve in any particular way. For >> example, future versions can introduce entirely new messages in the >> handshake, or remove messages that are currently visible in the handshake. >> QUIC is arguably just an extreme version of this observation. >> > >> > >> > I understand. I used TLS extensions merely as an example. >> >> There is no reason that a firewall should expect to parse TLS 1.4. TLS >> 1.3 had to go through significant hoops due to middleboxes that >> assumed they could see into everything like it was 1.2. This easily >> added a year to the development time. The final hunt for incompatible >> devices involved attempting to purchase samples, with no real >> guarantee that they would find an intolerant device. Encouraging this >> sort of behavior is a bad idea IMHO, as it will substantially burden >> the TLS WG when designing TLS 1.4 in all sorts of unexpected ways. >> >> > >> > >> > Even within the realm of ClientHello extensions, there is significant >> inflexibility here. For example, consider the handling of GREASE >> extensions. GREASE uses a variety of reserved extension codepoints, >> specifically to make sure that no entity is attempting to restrict use of >> unrecognized extensions. This proposal therefore has to add a flag >> declaring whether the client uses GREASE, because otherwise the set of >> extensions is dynamic, and the number of potential codepoints is >> impractically large. Any change to the way GREASE selects and rotates >> extension codepoints would therefore require a revision of this YANG model >> first. There has also been discussion of adding GREASE-type behavior to >> the "supported_versions" extension; that would similarly require a revised >> YANG model here. >> > >> > >> > Probably greasing is something that needs a certain special handling. >> Indeed that’s a form of fingerprinting (greases field XYZ). >> >> The whole point of grease is keeping extensions open. Coding special >> handling defeats the purpose. >> >> Sincerely, >> Watson Ladd >> >> > >> > Eliot >> >> ___ >> TLS mailing list >> t...@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A Layer 2/3 VPN Common YANG Model Authors : Samier Barguil Oscar Gonzalez de Dios Mohamed Boucadair Qin Wu Filename: draft-ietf-opsawg-vpn-common-01.txt Pages : 41 Date: 2020-09-16 Abstract: This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN Network Models. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC ;" o "RFC : A Layer 2/3 VPN Common YANG Model"; o reference: RFC Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-01 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vpn-common-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-01.txt
Hi all, The main changes in this version are as follows: * implements the edits agreed with Dhruv (https://mailarchive.ietf.org/arch/msg/opsawg/Cc-jP96OuuOqR0QV4gkhSg6jWQ8/) * address the comment from Italo about covering items that are common between at least two modules (https://mailarchive.ietf.org/arch/msg/opsawg/SCvr6kzo9ghoLPsmS5armrTXB8o/) * many edits to enhance the module * add more reference clauses and update the Reference Section accordingly Please review and share your comments. Cheers, Med > -Message d'origine- > De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de internet- > dra...@ietf.org > Envoyé : mercredi 16 septembre 2020 11:30 > À : i-d-annou...@ietf.org > Cc : opsawg@ietf.org > Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area > Working Group WG of the IETF. > > Title : A Layer 2/3 VPN Common YANG Model > Authors : Samier Barguil > Oscar Gonzalez de Dios > Mohamed Boucadair > Qin Wu > Filename: draft-ietf-opsawg-vpn-common-01.txt > Pages : 41 > Date: 2020-09-16 > > Abstract: >This document defines a common YANG module that is meant to be > reused >by various VPN-related modules such as Layer 3 VPN and Layer 2 > VPN >Network Models. > > Editorial Note (To be removed by RFC Editor) > >Please update these statements within the document with the RFC >number to be assigned to this document: > >o "This version of this YANG module is part of RFC ;" > >o "RFC : A Layer 2/3 VPN Common YANG Model"; > >o reference: RFC > >Also, please update the "revision" date of the YANG module. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-01 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-vpn-common- > 01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-vpn-common-01 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
On Sep 16, 2020, at 1:08 PM, Nick Harper wrote: > On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote: > Hi Nick, > > Please see inline > > On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: > I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. > > The grease_extension parameter shouldn't exist, and there should be no > special handling for GREASE values. GREASE doesn't need to be mentioned in > this draft, except to say that a client may send values (cipher suites, > extensions, named groups, signature algorithms, versions, key exchange modes, > ALPN identifiers, etc.) that are unknown to the middlebox and that the > middlebox MUST NOT reject connections with values unknown to the middlebox. > > The grease_extension parameter in the YANG model is a "boolean" type to > indicate whether the GREASE values are offered by the client or not. The MUD > YANG model does not convey the GREASE values. > > This is still problematic. > > Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to > check that their peers correctly ignore unknown values (instead of closing > the connection). If a device special-cases GREASE values when processing TLS > messages, that device has completely missed the purpose of GREASE and is > likely to cause interoperability failures when in the future it sees a TLS > message that contains a new extension/cipher suite/etc. that isn't a GREASE > value. > > The IETF should not be encouraging devices to special-case GREASE values. I > can see no use of the grease_extension parameter in the YANG model that does > not involve special-casing GREASE values. Hence it needs to be removed. Yes, that is the better way to handle GREASE: expect Grease from any client, on any TLS value (as Ben pointed out supported_versions may well be Grease'd next). -d ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
Taking a step back from details, ISTM that the whole design of this document is antithetical to extensibility: TLS is a protocol with a number of extension points. What this document does is allow an endpoint to restrict its use of a certain set of extension points. However, the language provided here is insufficiently rich to allow the client to properly describe the use of those points. As a concrete example: for extensions the model knows about (e.g., supported_versions) you can indicate the contents of the extension, but for extensions the model does not know about (e.g., ECH) you cannot. That means that you're either stuck with allowing anything in those extensions (which means that your filtering effectiveness is reduced) or you don't allow those extensions, in which case you create ossification. As a thought example, consider a hypothetical TLS 1.4 which decided to adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated CH/SH in extensions in a stereotyped outer CH/SH. The system described here would be unable to do anything useful with that, which creates pressure to block TLS 1.4 entirely, which obviously is not awesome. If we want to pursue this kind of idea -- and I'm not at all sure we should -- ISTM that rather than trying to invent some new DSL for filtering TLS we allow the client (who by hypothesis is trusted as to what it will generate) to provide a general program that the middlebox can interpret that will describe what it will do. For instance, you could provide a WASM file which gets fed the CH and just says "this is me" or "this doesn't look like me". That way we don't need to continue extending the language here whenever TLS evolves. Note that that doesn't prohibit having a language like this as a programming convenience, but it wouldn't restrict the semantics of what you could say about the connection. -Ekr On Wed, Sep 16, 2020 at 1:09 PM Nick Harper wrote: > > > On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote: > >> Hi Nick, >> >> Please see inline >> >> On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote: >> >>> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft. >>> >>> The grease_extension parameter shouldn't exist, and there should be no >>> special handling for GREASE values. GREASE doesn't need to be mentioned in >>> this draft, except to say that a client may send values (cipher suites, >>> extensions, named groups, signature algorithms, versions, key exchange >>> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that >>> the middlebox MUST NOT reject connections with values unknown to the >>> middlebox. >>> >> >> The grease_extension parameter in the YANG model is a "boolean" type to >> indicate whether the GREASE values are offered by the client or not. The >> MUD YANG model does not convey the GREASE values. >> >> > This is still problematic. > > Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to > check that their peers correctly ignore unknown values (instead of closing > the connection). If a device special-cases GREASE values when processing > TLS messages, that device has completely missed the purpose of GREASE and > is likely to cause interoperability failures when in the future it sees a > TLS message that contains a new extension/cipher suite/etc. that isn't a > GREASE value. > > The IETF should not be encouraging devices to special-case GREASE values. > I can see no use of the grease_extension parameter in the YANG model that > does not involve special-casing GREASE values. Hence it needs to be removed. > ___ > TLS mailing list > t...@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
