Re: [TLS] a slightly different DTLSShortCiphertext
On 05/03/2018, 00:27, "Eric Rescorla" mailto:e...@rtfm.com>> wrote: I genuinely can't see what advantage we get by not having its presence explicitly signalled. Could you elaborate a bit on that? Well, you're making every packet 1 byte bigger, for starters. If the cost of having simple, straightforward implementations while at the same time easing the operational side of the world is 1 byte per packet, I’m happy to pay the price. People with use cases where a 1-byte overhead really matters already think (D)TLS is too chatty. In fact, that’s one of the main reasons OSCORE exists. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Op 01-03-18 om 22:50 schreef Viktor Dukhovni: > > >> On Mar 1, 2018, at 2:13 PM, Shumon Huque wrote: >> >>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams >>> wrote: >>> IF there's an objection to modifying the extension in order to add a >>> pin-to-DANE TTL field, I would propose the following instead: >>> >>> Make the pin-to-DANE be "forever" but make it so it can easily be >>> cleared if DANE is undeployed for the service. >> >> This option is already covered in the draft. It doesn't use the term pinning, >> but does mention caching the existence of DANE on first contact and >> requiring it subsequently (if clients want to do so). >> >> I do not know if the draft authors and/or WG have an appetite to do the much >> more major change suggested by Viktor (i.e in-protocol pinning TTL commitment >> and requiring subsequent denial of existence proof if DANE is removed). > > Avoiding an explicit TTL, and clients unilaterally assuming the DANE extension > will always be available is not IMHO a good idea.> > Websites that initially implement the extension should be able to eventually > stop using it, if for some reason they decide that they no longer want to do > so. While the server can clear the caches of clients that see a denial of > existence of the TLSA records, or proof an unsigned delegation from a parent > domain, without a max TTL there are always clients that have not yet connected > since the policy change, and will be broken indefinitely if the extension is > no > longer delivered. > > Therefore, any long-term caching of a destination's support for the extension > should require server opt-in, and must have a maximum duration. How do you (all) feel about using the expiry date on the RRSIG for the TLSA to be used for this purpose? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Op 26-02-18 om 15:26 schreef Paul Wouters: > On Thu, 22 Feb 2018, Shumon Huque wrote: > >> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters wrote: >> On Wed, 21 Feb 2018, Shumon Huque wrote: >> >> Okay, got it. For people that have already implemented >> this, I think >> there has been an implicit understanding that the format >> of the chain >> data is a sequence of concatenated wire format RRs exactly >> as they appear >> in a DNS message section >> >> >> Note, I would not call it "sequence of concatenated wire format >> RRs", as >> it is simply the wireformat of a DNS message. >> >> The fact that some parts >> are concatenated RR's is just part of the wireformat of the DNS >> reply >> message. That is, this isn't introducing some new form of >> concatenated >> content - it is _just_ a regular DNS wire format message, and the >> document should not go deeper into its explanation. >> >> >> It would _not_ be correct to say that this is a "DNS wire format >> message" - that >> would mean there is a DNS header section with flags and response codes, >> and other sections. The chain data structure as currently specified >> really is >> concatenated wire-format RRs (as they appear _within_ a DNS message >> _section_). Let me know if that is unclear in the draft (or my >> proposed edits). > > So it was decided to not use a full DNS packet format? And then since you > miss the structure of the Answer Section and Additional/Authority > Section, you require the "answer RR's" come first where you basically > emulate an Answer Section? No Paul, the division in sections is irrelevant for a verifier. The only bit of information in a DNS message that is used by a verifier is the question. From the question, validation starts and the relevant records are followed and verified. But the question section is also not needed as the question can be derived from the name and port of the service, i.e. ._tcp.. TLSA The order described in the draft is both an optimization to reduce the number of times a verifier has to go over the RRs, and it makes the content easier to read (and understand) for humans too. Also, for non existence answers, DNSSEC validators (and thus also a verifier for the chain extension) simply ignore the DNS message header. Proof of non-existence can and must be derived from the set of RRs in the message body/sections too. The extension already supports Denial of Existence proof b.t.w., because it is also needed for wildcard expansions (which are supported). Personally, I do not have very strong feelings whether or not the extension content is a DNS message or not, but a verifier would ignore the header and the question anyway, so why bother with that overhead? Also, you *can* use the content of the RFC7901 chain query. You just have to skip the header and question section, and then include the rest. > > Isn't that an indication that we should really use the wireformat of an > entire DNS message here? Maybe some DNS library/tools people can chime > in here to tell us if this matters much to them (assuming they are > adding support for creating/consuming these chains of RRsets in wire > format. > > I am personally a little sad we cannot have a dig +chainquery command > where we write out the entire answer packet format to a blob, to be > loaded by > the TLS server. And where a TLS client cannot just hand over the blob > "as if it came in as a reply from a DNS server" to its DNS/cache > receiving code path. > >> I recall at one point way back there was a discussion about whether >> the chain >> data should just be a fully formed DNS message, but I don't believe >> that idea >> had much support in the working group (personally I would have been >> fine with >> that choice too, if it did have support). > > Do you remember why not? I'll see about checking the archives, but to me > the hint that you are losing information and require some kind of > ordering seems to suggest there is a need for using the full DNS message > reply format > >> There is some residual wording in the draft about ordering of CNAMEs >> etc in >> the answer records part. Assuming the WG agrees, I am fine with relaxing >> that requirement - that ended up in there because although there is no >> defined >> ordering of RRs within a DNS message section, as a practical matter >> CNAMEs >> are almost always ordered since there are some DNS queriers that get >> confused >> otherwise. This is a new protocol though, so we can be more faithful >> to the DNS >> spec. > > I would prefer the residual wording to go away. Any hints at order being > important should be squashed. > >> I don't think getting unrelated DNSSEC records would be an >> issue. TLS >> has its maximum sizes for the handshake. In fact, it could allow >> the >> extension to have some useful data in the case of MX or SRV. >> (and could >> be a fe
[TLS] TLS 1.3 IANA Considerations
Should the TLS 1.3 draft request a new registry for psk_key_exchange_modes? Initially, I thought that there was no way to extend it, but the email below from Martin Thomson suggests adding a new codepoint, so I thought it best to check that this wasn't an oversight in the draft. -- Tony -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: 01 March 2018 21:55 To: Russ Housley Cc: IETF TLS Subject: Re: [TLS] New Internet-Draft: draft-housley-tls-tls13-cert-with-extern-psk-00 Hi Russ, This seems like a welcome addition. I'm not sure why you think that PQ needs are a good motivation for this work though. Managing external PSKs is so unwieldy that it almost seems like this would do more harm than good in that regard. I find this more interesting from the perspective of providing continuing proof of possession for keys while also permitting the use of 0-RTT (and session continuation more generally). FWIW, I don't see any reason that this approach would be a problem given that it is additive, the problem that Sam Scott et. al. from before was a result of important contextual information being omitted from the transcript. Why didn't you consider a new codepoint on psk_key_exchange_modes that permits/requires use of the certificate? The purpose of that extension is to signal that a) you want PSK, and b) what additional things are permitted alongside that PSK. It's not clear from your text on client certificate authentication whether your mode permits the server to omit its Certificate, but then send CertificateRequest. You should clarify that one way or other. --Martin On Fri, Mar 2, 2018 at 8:37 AM, Russ Housley wrote: > I would like to get comments on this Internet-Draft. Once a round of > comments have been received and folded into -01, I would like to work with > folks that did the earlier proofs with Tamarin to make sure that the this > does not negatively impact the TLS 1.3 protocol changes that were made to > eliminate the man-in-the-middle attack that they found in 2015. > > Thanks, > Russ > > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-housley-tls-tls13-cert-with-extern-psk-00.txt > Date: March 1, 2018 at 4:13:44 PM EST > To: "Russ Housley" > > > A new version of I-D, draft-housley-tls-tls13-cert-with-extern-psk-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. > > Name: draft-housley-tls-tls13-cert-with-extern-psk > Revision: 00 > Title: TLS 1.3 Extension for Certificate-based Authentication with an > External Pre-Shared Key > Document date: 2018-03-01 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-housley-tls-tls13-cert-with-extern-psk-00.txt > Status: > https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/ > Htmlized: > https://tools.ietf.org/html/draft-housley-tls-tls13-cert-with-extern-psk-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-housley-tls-tls13-cert-with-extern-psk-00 > > > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external pre- > shared key (PSK). > > > > > 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 > > > > ___ > 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 Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLSv1.3 - Draft 26 - small typo need correction
The double “the” got fixed, but the double and didn’t I submitted a PR so we don’t forget this. spt > On Mar 4, 2018, at 22:52, M K Saravanan wrote: > > Hi, > > In TLSv1.3, draft 26, there is a small typographical error. It needs > to be corrected. > > > (1) > > Appendix D. Backward Compatibility > > Second Paragraph. Second sentence. There is a double "and". > > /* Original */ > = > Servers can also handle clients trying to use future versions of TLS as long > as > the ClientHello format remains compatible and and there is at least > one protocol version supported by both the client and the server. > == > > /* Corrected */ > > == > Servers can also handle clients trying to use future versions of TLS as long > as > the ClientHello format remains compatible and there is at least > one protocol version supported by both the client and the server. > == > > (2) > > Section 4.2.8.2. ECDHE Parameters > > First paragraph, first sentence. There is a double "the". > > /* Original */ > = > ECDHE parameters for both clients and servers are encoded in the the > opaque key_exchange field of a KeyShareEntry in a KeyShare structure. > = > > /* Corrected */ > = > ECDHE parameters for both clients and servers are encoded in the > opaque key_exchange field of a KeyShareEntry in a KeyShare structure. > = > > (3) > > Appendix E.5. Replay Attacks on 0-RTT > > Second paragraph, second line. There is a double "the". > > /* Original */ > === > If data can be replayed a large number of times, additional attacks > become possible, such as making repeated measurements of the the > speed of cryptographic operations. > === > > /* Corrected */ > == > If data can be replayed a large number of times, additional attacks > become possible, such as making repeated measurements of the > speed of cryptographic operations. > == > > Please correct them. > > with regards, > Saravanan > > ___ > 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] TLSv1.3 - Draft 26 - small typo need correction
Spoke too soon I got the double the in the following PR: https://github.com/tlswg/tls13-spec/pull/1164 spt > On Mar 5, 2018, at 08:30, Sean Turner wrote: > > The double “the” got fixed, but the double and didn’t I submitted a PR so we > don’t forget this. > > spt > >> On Mar 4, 2018, at 22:52, M K Saravanan wrote: >> >> Hi, >> >> In TLSv1.3, draft 26, there is a small typographical error. It needs >> to be corrected. >> >> >> (1) >> >> Appendix D. Backward Compatibility >> >> Second Paragraph. Second sentence. There is a double "and". >> >> /* Original */ >> = >> Servers can also handle clients trying to use future versions of TLS as long >> as >> the ClientHello format remains compatible and and there is at least >> one protocol version supported by both the client and the server. >> == >> >> /* Corrected */ >> >> == >> Servers can also handle clients trying to use future versions of TLS as long >> as >> the ClientHello format remains compatible and there is at least >> one protocol version supported by both the client and the server. >> == >> >> (2) >> >> Section 4.2.8.2. ECDHE Parameters >> >> First paragraph, first sentence. There is a double "the". >> >> /* Original */ >> = >> ECDHE parameters for both clients and servers are encoded in the the >> opaque key_exchange field of a KeyShareEntry in a KeyShare structure. >> = >> >> /* Corrected */ >> = >> ECDHE parameters for both clients and servers are encoded in the >> opaque key_exchange field of a KeyShareEntry in a KeyShare structure. >> = >> >> (3) >> >> Appendix E.5. Replay Attacks on 0-RTT >> >> Second paragraph, second line. There is a double "the". >> >> /* Original */ >> === >> If data can be replayed a large number of times, additional attacks >> become possible, such as making repeated measurements of the the >> speed of cryptographic operations. >> === >> >> /* Corrected */ >> == >> If data can be replayed a large number of times, additional attacks >> become possible, such as making repeated measurements of the >> speed of cryptographic operations. >> == >> >> Please correct them. >> >> with regards, >> Saravanan >> >> ___ >> 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] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
> On Mar 5, 2018, at 4:32 AM, Willem Toorop wrote: > >> Therefore, any long-term caching of a destination's support for the extension >> should require server opt-in, and must have a maximum duration. > > How do you (all) feel about using the expiry date on the RRSIG for the > TLSA to be used for this purpose? I don't think the expiry date is adequate for this purpose. To reduce the scope for replay attacks, my domain has 14 day RRSIG lifetimes, and automated re-signing happens as records age, so they are often as close as ~4 days away from expiration when re-signed. And yet, if were to deploy a web server that implements this extension, I'd want to commit to DANE for a considerably longer time. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
On Mon, 5 Mar 2018, Viktor Dukhovni wrote: On Mar 5, 2018, at 4:32 AM, Willem Toorop wrote: Therefore, any long-term caching of a destination's support for the extension should require server opt-in, and must have a maximum duration. How do you (all) feel about using the expiry date on the RRSIG for the TLSA to be used for this purpose? I don't think the expiry date is adequate for this purpose. To reduce the scope for replay attacks, my domain has 14 day RRSIG lifetimes, and automated re-signing happens as records age, so they are often as close as ~4 days away from expiration when re-signed. And yet, if were to deploy a web server that implements this extension, I'd want to commit to DANE for a considerably longer time. There is also the reverse problem of pinning something you don't have anymore. With TTL, you can tune your commitment and risk. Also in general, DNS data should not be used beyond its TTL unless the data itself has some kind of TTL on it (eg a full cert payload or openpgp key with expiry) Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-exported-authenticator-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename: draft-ietf-tls-exported-authenticator-06.txt Pages : 11 Date: 2018-03-05 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-06 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-06 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/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3
Hi folks, Here's another entry in the DH-only pile. I've just posted: draft-rescorla-tls13-semistatic-dh-00 This implements a semi-static DH exchange mostly borrowed from OPTLS [0]. There are obviously connections with draft-putman, but this is more oriented towards implementing a 1-RTT style exchange where the client has no foreknowledge of the server's capabilities (though it's extensible to 0-RTT) than towards pre-distributed DH keys, and has less invasive changes to the key schedule. We'd like 10 minutes to discuss this in London. Thanks, -Ekr [0] http://ieeexplore.ieee.org/abstract/document/7467348/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-fenter-tls-decryption-00.txt
All, I have just submitted a draft outlining enterprise use cases for out-of-band TLS decryption. Please review. Thanks Steve Fenter -- Forwarded message -- From: Date: Mon, Mar 5, 2018 at 1:05 PM Subject: New Version Notification for draft-fenter-tls-decryption-00.txt To: Steve Fenter A new version of I-D, draft-fenter-tls-decryption-00.txt has been successfully submitted by Steve Fenter and posted to the IETF repository. Name: draft-fenter-tls-decryption Revision: 00 Title: Why Enterprises Need Out-of-Band TLS Decryption Document date: 2018-03-05 Group: Individual Submission Pages: 21 URL:https://www.ietf.org/internet-drafts/draft-fenter-tls- decryption-00.txt Status: https://datatracker.ietf.org/doc/draft-fenter-tls- decryption/ Htmlized: https://tools.ietf.org/html/draft-fenter-tls-decryption-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fenter-tls- decryption-00 Abstract: Some enterprises are heavily TLS encrypted within their own enterprise network boundaries. Many of these enterprises are also utilizing out-of-band TLS decryption in order to inspect their own traffic for purposes of troubleshooting, network security monitoring, and for other kinds of monitoring. These monitoring functions are mission critical, and cannot just be done without when TLS 1.3 (draft-ietf-tls-tls13-26) is released or when the RSA key exchange is someday deprecated from TLS 1.2 (RFC5246). This draft will outline the use cases for out-of-band TLS decryption, as well as alternative suggestions for monitoring and troubleshooting and the limitations of those alternatives. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-ietf-tls-exported-authenticator-06.txt
FYI, I've published an updated version of exported authenticators incorporating into account the changes discussed at IETF 100 and on the list. -- Forwarded message - From: Date: Mon, Mar 5, 2018 at 12:28 PM Subject: New Version Notification for draft-ietf-tls-exported-authenticator-06.txt To: Nick Sullivan A new version of I-D, draft-ietf-tls-exported-authenticator-06.txt has been successfully submitted by Nick Sullivan and posted to the IETF repository. Name: draft-ietf-tls-exported-authenticator Revision: 06 Title: Exported Authenticators in TLS Document date: 2018-03-05 Group: tls Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-tls-exported-authenticator-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ Htmlized: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-06 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
