Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 20, 2018, at 12:09 AM, Joseph Salowey wrote: > > [Joe] This can also be done with a new extension code point that defines a > replacement extension that adds the pinning policy. This seems like viable > possibility, we are not running short on extension code points. This looks like the lose-lose version. * The present extension loses all downgrade from original LC, and gets a reduced scope, all without a clear consensus to limit the scope or lose all downgrade protection, with the path forward on restoring it more uncertain. * No explicit do not pin signal in the present extension. * Should a second extension be defined later, clients have to signal two separate extensions, and servers have to respond with two separate extensions. Complicating implementation, all to save two bytes in the present extension, with those two bytes providing a clear do not pin signal, not pinning at this time does have consensus. * With the extra two bytes the next specification merely needs to allow new interpretations of non-zero values, with no new wire formats for anyone to implement. THe upgrade path for both clients and servers becomes simple, just extend the capabilities of an extension they may already support, or which existing code can be found. The requested 2-bytes carry no implementation burden for parties that would implement the extension without those bytes. Worst-case they'll never be used, but they do signal good-will on the part of those who want a minimal extension now to allow the follow-on specification to be developed. The close attention to the content of this document that resulted from the disparate views of its proper scope has found important issues that were missed, and corrected an unnecessary limitation (prohibition of denial of existence). Though some delay has resulted, the document is better off for it. I think it is fair to ask for good faith in return, at a negligible cost of 16 bits that might if things don't go to plan forever remain zero, but will at least explicitly signal to the client that pinning based on prior observation of the extension should not take place. Refusing to make a trivial concession to gain a broader base of support for the document, just to save two bytes does not look like an inclusive process to me. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters wrote: > > > 4. Re-submit the document for publication and start work on a separate >> extension that supports pinning >> > > While we agree we can move pinning to a separate document, it makes much > less sense for this to become an additional fully independent TLS > extension, especially since the pinning will depend on DNSSEC properties > only delivered by the TLS-DNSSEC extension. So as we suggested before, the > best solution therefore would be to define this two byte pin in the > current document, and be defined as "ignore completely unless you > implement this other RFC". That is, > > The proposed 16-byte "extension support lifetime" field will: > >* Have 0 as the only value defined in the present draft >* Servers that implement only the present draft SHALL send 0. >* Clients that implement only the present draft SHALL treat > any value received as though it were 0. >* A zero "extension support lifetime" field prohibits the > client from unilaterally mandating the extension based > on prior observation of its presence (pinning). > > This a win-win for both opponents and proponents of pinning. And not > only that, it will allow us to put the pinning inside the extension > it relates to. > > Additionally, with no pin set to 0 in the current document, and no > mentioning of pinning since the consensus agrees to remove it that, > client implementations will not be told to not pin, and will start doing > something like TOFU like pinning. It would actually be better to specify > this zero pin to prevent this from happening. > > If you take it as a given that we will write this document, then it only > makes logical sense to already reserve these two bytes in the current > document, even it if states "must be 0". Our document will Update: > this document to describe the pinning in detail. > > [Joe] This can also be done with a new extension code point that defines a replacement extension that adds the pinning policy. This seems like viable possibility, we are not running short on extension code points. > Nico, Paul and Viktor > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] potential attack on TLS cert compression
Did we ever reach any agreement about what to do here? For me, the threat model here seems fairly far-fetched and infeasible, in the sense that the threat only exists in some very specific bugs in multithreaded decompressor. I'd be less reluctant to do this if it were not for the fact that all solutions I've considered for this are quite annoying. Putting the hash on the wire means wasting bytes, and altering the transcript hash introduces a lot of complexity into some implementations. On Thu, Mar 22, 2018 at 11:39 AM, Thomas Pornin wrote: > > Certificate compression would be challenging to implement, though. > Usually, compression relies on at least a "window" over the decompressed > data (32 kB for Zlib/Deflate). Some rudimentary forms of compression > don't need that (e.g. run-length encoding) but usually offer poor > compression ratios. A 32 kB window is a lot for the kind of architecture > that BearSSL targets. > This is roughly my intuition -- you could parse certificate messages in a streaming manner, but if you're on a sufficiently limited platform that this is a worthwhile investment, you're probably not going to use certificate compression anyways. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-exported-authenticator
All, This is the working group last call for the "Exported Authenticators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. Please review the document and send your comments to the list by 2359 UTC on 4 April 2018. Thanks - J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New Version Notification for draft-ietf-tls-exported-authenticator-06.txt
To make sure nobody is caught off guard, I’m going to issue the WGLC shortly for this draft. We were waiting on getting a security review and we got that in London and from the security proofs perspective it looks like we’re good to go for a WGLC. spt > On Mar 5, 2018, at 20:07, Nick Sullivan wrote: > > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
