[TLS] draft-housley-tls-tls13-cert-with-extern-psk
In London, I was on the agenda to talk about certificate-based authentication with external pre-shared key (PSK). We ran out of time, and I did not get to make the presentation. The slides are in the proceedings; see https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-certificate-based-authentication-with-external-psk-00. Please review the document and send comments to the list. I would like the TLS WG to adopt this document. Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
We've had a lot of discussion on this thread that has pointed out that there are enough issues with the current document that we should recommend that the AD pull it back from the RFC editor. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: 1. Scope the document to the assertive use cases 2. Explicitly allow (but do not require) DoE be included 3. Remove current text about pinning 4. Re-submit the document for publication and start work on a separate extension that supports pinning I understand that not everyone is happy with publishing the document scoped down in this way, but there is a community of users who would find it useful. I am soliciting suggestions for text for the 1-3 and I encourage proponents of the more restrictive use case to get a draft together that we can consider for adoption by the working group. I also want to thank the participants for keeping the discussion mostly civil and having patience as we go through this process. Joe On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey wrote: > Hi Folks, > > Some objections were raised late during the review of > the draft-ietf-tls-dnssec-chain-extension. The question before the > working group is either to publish the document as is or to bring the > document back into the working group to address the following issues: > > - Recommendation of adding denial of existence proofs in the chain > provided by the extension > - Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > > This is a consensus call on how to progress this document. Please answer > the following questions: > > 1) Do you support publication of the document as is, leaving these two > issues to potentially be addressed in follow-up work? > > If the answer to 1) is no then please indicate if you think the working > group should work on the document to include > > A) Recommendation of adding denial of existence proofs in the chain > provided by the extension > B) Adding signaling to require the use of this extension for a period of > time (Pinning with TTL) > C) Both > > This call will be open until April 18, 2018. > > Thanks, > > Joe > > > ___ 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 2:22 PM, Joseph Salowey wrote: > We've had a lot of discussion on this thread that has pointed out that > there are enough issues with the current document that we should recommend > that the AD pull it back from the RFC editor. > > Concerns have been raised about the trade-offs associated with pinning and > I do not think we currently have consensus to add pinning. While I think > it may be possible to come to consensus on pinning I think it may take some > time. I believe we can quickly get consensus for the following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate > extension that supports pinning > SGTM > > I understand that not everyone is happy with publishing the document > scoped down in this way, but there is a community of users who would find > it useful. I am soliciting suggestions for text for the 1-3 and I > encourage proponents of the more restrictive use case to get a draft > together that we can consider for adoption by the working group. > > I also want to thank the participants for keeping the discussion mostly > civil and having patience as we go through this process. > > Joe > > > On Wed, Apr 4, 2018 at 10:50 AM, Joseph Salowey wrote: > >> Hi Folks, >> >> Some objections were raised late during the review of >> the draft-ietf-tls-dnssec-chain-extension. The question before the >> working group is either to publish the document as is or to bring the >> document back into the working group to address the following issues: >> >> - Recommendation of adding denial of existence proofs in the chain >> provided by the extension >> - Adding signaling to require the use of this extension for a period of >> time (Pinning with TTL) >> >> This is a consensus call on how to progress this document. Please answer >> the following questions: >> >> 1) Do you support publication of the document as is, leaving these two >> issues to potentially be addressed in follow-up work? >> >> If the answer to 1) is no then please indicate if you think the working >> group should work on the document to include >> >> A) Recommendation of adding denial of existence proofs in the chain >> provided by the extension >> B) Adding signaling to require the use of this extension for a period of >> time (Pinning with TTL) >> C) Both >> >> This call will be open until April 18, 2018. >> >> Thanks, >> >> Joe >> >> >> > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On 4/18/18 10:22 AM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning > and I do not think we currently have consensus to add pinning. While I > think it may be possible to come to consensus on pinning I think it may > take some time. I believe we can quickly get consensus for the > following approach: > > 1. Scope the document to the assertive use cases > 2. Explicitly allow (but do not require) DoE be included > 3. Remove current text about pinning > 4. Re-submit the document for publication and start work on a separate > extension that supports pinning This sounds reasonable. I'll talk with co-editors about text changes. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F signature.asc Description: OpenPGP digital signature ___ 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, 18 Apr 2018, Joseph Salowey wrote: This is a combined response of Viktor, Nico and Paul. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning. While I think it may be possible to come to consensus on pinning I think it may take some time. I believe we can quickly get consensus for the following approach: A slight correction here. The call that there is no consensus on pinning is not entirely correct. The discussion showed a majority of people in favour of some kind of pinning, but with most people being agreeable that this can be in its own document and not hold up this document further. A pinning document is inevitably coming. 1. Scope the document to the assertive use cases This means actually leaving out what some of us think are the most important use case - an alternative for webpki. While we are okay to reduce the scope of this document, it seems logical that such decision comes with some guarantees to allow the other use cases. Which gets us back to a new document about pinning (see below) 2. Explicitly allow (but do not require) DoE be included The document does not currently allow the extension to be empty. So if there is no TLSA record and the extension would be present, it therefore can only contain a DoE chain. So what do you mean with item 2? Possibly you mean to say "if there is no TLSA record, the extension can be omited or the extension can be included with a DoE chain" ? That would be okay with us. 3. Remove current text about pinning That is fine, but one caveat below. 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. Nico, Paul and 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 4:42 PM, Paul Wouters wrote: > On Wed, 18 Apr 2018, Joseph Salowey wrote: > > This is a combined response of Viktor, Nico and Paul. > > Concerns have been raised about the trade-offs associated with pinning >> and I >> do not think we currently have consensus to add >> pinning. While I think it may be possible to come to consensus on >> pinning I >> think it may take some time. I believe we can >> quickly get consensus for the following approach: >> > > A slight correction here. The call that there is no consensus on pinning > is not entirely correct. The discussion showed a majority of people in > favour of some kind of pinning, but with most people being agreeable that > this can be in its own document and not hold up this document further. A > pinning document is inevitably coming. > > 1. Scope the document to the assertive use cases >> > > This means actually leaving out what some of us think are the most > important use case - an alternative for webpki. A down-scoped document can perfectly well be used as an alternative to the Web PKI. As noted before, clients can offer what they support, and servers can switch. > While we are okay > to reduce the scope of this document, it seems logical that such > decision comes with some guarantees to allow the other use cases. > Which gets us back to a new document about pinning (see below) > > 2. Explicitly allow (but do not require) DoE be included >> > > The document does not currently allow the extension to be empty. So if > there is no TLSA record and the extension would be present, it therefore > can only contain a DoE chain. So what do you mean with item 2? Possibly > you mean to say "if there is no TLSA record, the extension can be omited > or the extension can be included with a DoE chain" ? That would be okay > with us. > > 3. Remove current text about pinning >> > > That is fine, but one caveat below. > > 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. > I do not support adding a field to the protocol with semantics to be defined later. Especially a 16-byte field, which is a fair bit of cruft to carry around. This seems perfectly suitable for a separate extension. --Richard > 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. > > Nico, Paul and Viktor > > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > I do not support adding a field to the protocol with semantics to be defined > later. Especially a 16-byte field, which is a fair bit of cruft to carry > around. The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. -- 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 4:48 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > I do not support adding a field to the protocol with semantics to be > defined later. Especially a 16-byte field, which is a fair bit of cruft to > carry around. > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > Secondary point. Still don't think we should deliberately include undefined fields, e.g., because part of the discussion is whether 16 bits is the right size. --Richard > > -- > Viktor. > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > I do not support adding a field to the protocol with semantics to be defined > later. And the semantics are defined. The server must send zero, and the client must read it as zero. The propose semantics PROHIBIT pinning, which is what everyone seems to want presently. Future semantics when BOTH client and server implement a forthcoming spec will to support pinning as described for up to the indicated time (in suitable units). -- 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 Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > Secondary point. Still don't think we should deliberately include undefined > fields, e.g., because part of the discussion is whether 16 bits is the right > size. 16 bits is clearly enough. If the units are hours that gets you ~7.5 years. Pinning for less than an hour is pointless, it then becomes smaller than typical DNS TTLs for the TLSA RRset the client got previously, which it can cache without any pinning. Pinning for more than 7.5 years is absurd, it only protect clients that connect less than twice per decade... -- 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 04:52:14PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > wrote: > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > I do not support adding a field to the protocol with semantics to be > > defined later. Especially a 16-byte field, which is a fair bit of cruft to > > carry around. > > > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether 16 bits > is the right size. It's not as if we've never had reserved fields. ___ 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 4:56 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether 16 bits > is the right size. > > 16 bits is clearly enough. If the units are hours that gets you ~7.5 > years. Pinning for less than an hour is pointless, it then becomes smaller > than typical DNS TTLs for the TLSA RRset the client got previously, which > it can cache without any pinning. > > Pinning for more than 7.5 years is absurd, it only protect clients that > connect less than twice per decade... > 640k should be enough for anyone. `preload`? `includeSubdomains`? Experience with HSTS and HPKP shows you need more than an integer. --Richard > > -- > Viktor. > > ___ > 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] Consensus Call on draft-ietf-tls-dnssec-chain-extension
On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams wrote: > On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > > > wrote: > > > > > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > > > I do not support adding a field to the protocol with semantics to be > > > defined later. Especially a 16-byte field, which is a fair bit of > cruft to > > > carry around. > > > > > > The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry. > > > > > > > Secondary point. Still don't think we should deliberately include > > undefined fields, e.g., because part of the discussion is whether 16 bits > > is the right size. > > It's not as if we've never had reserved fields. > The only "reserved" in RFC 5246 is a few code points that are reserved for private use. No reserved fields. --Richard ___ 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 05:01:54PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni > wrote: > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > > > Secondary point. Still don't think we should deliberately include > > undefined fields, e.g., because part of the discussion is whether 16 bits > > is the right size. > > > > 16 bits is clearly enough. If the units are hours that gets you ~7.5 > > years. Pinning for less than an hour is pointless, it then becomes smaller > > than typical DNS TTLs for the TLSA RRset the client got previously, which > > it can cache without any pinning. > > > > Pinning for more than 7.5 years is absurd, it only protect clients that > > connect less than twice per decade... > > 640k should be enough for anyone. That's just silly. Really, 7.5 years (relative, not absolute) measured in hours is plenty good enough, and more than outlives current device obsolescence. This isn't subject to Moore's law or anything like it. > `preload`? `includeSubdomains`? Experience with HSTS and HPKP shows you > need more than an integer. No, we need none of those things. We want only to pin the presence of this extension. Anything else would be operationally difficult (as seen with HPKP). As to subdomains, we're willing to live with TOFU semantics for all of them. Nico -- ___ 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 Apr 18, 2018, at 5:03 PM, Richard Barnes wrote: > > The only "reserved" in RFC 5246 is a few code points that are reserved for > private use. No reserved fields. The field is NOT reserved, it carries an "extension support lifetime" of 16-bits whose zero value means "DO NOT PIN". Other values will be defined in a follow-on draft, but clients must interpret those also as zero unless they implement the other draft. Therefore, a client implementing this draft has complete semantics for the field, it explicitly prohibits pinning, which might otherwise happen, especially if no follow-on document materializes. -- 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 4:42 PM, Paul Wouters wrote:
>
> 2. Explicitly allow (but do not require) DoE be included
>>
>
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chain. So what do you mean with item 2? Possibly
> you mean to say "if there is no TLSA record, the extension can be omited
> or the extension can be included with a DoE chain" ? That would be okay
> with us.
Yes, my understanding is that's what it means.
Note that Section 8 ("Mandating Use") already did hint at the future
possibility of
this extension carrying a DoE chain that could be deployed in a TLS
application
ecosystem where all servers understood and were prepared to respond to this
extension. The plan is to now add text that allows DoE chains more
generally,
with details of use defined in subsequent documents.
Shumon.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
Nico Williams writes: >That's just silly. Really, 7.5 years (relative, not absolute) measured in >hours is plenty good enough, and more than outlives current device >obsolescence. This isn't subject to Moore's law or anything like it. I don't know what devices you work with, but for the ones where my code is used ten years is the baseline life expectancy, going out to 15-20 years for longer-life ones (I still have to deal with SSH bugs from the late 1990s, because the lifetime of the equipment that's used in is 20 years and counting. I think I've finally managed to get away from having to do SSLv3 within the last year or two). OTOH I doubt any of these devices will do pinning, they just bake in the certs at manufacture/provisioning, so I'm fine with any kind of lifetime. Just wanted to point out, yet again, that the entire world doesn't live in a "we can patch the entire deployed base in 24 hours" situation. peter. ___ 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 Apr 18, 2018, at 11:25 PM, Peter Gutmann wrote: > >> That's just silly. Really, 7.5 years (relative, not absolute) measured in >> hours is plenty good enough, and more than outlives current device >> obsolescence. This isn't subject to Moore's law or anything like it. > > I don't know what devices you work with, but for the ones where my code is > used ten years is the baseline life expectancy, going out to 15-20 years for > longer-life ones (I still have to deal with SSH bugs from the late 1990s, > because the lifetime of the equipment that's used in is 20 years and counting. > I think I've finally managed to get away from having to do SSLv3 within the > last year or two). > > OTOH I doubt any of these devices will do pinning, they just bake in the certs > at manufacture/provisioning, so I'm fine with any kind of lifetime. Just > wanted to point out, yet again, that the entire world doesn't live in a "we > can patch the entire deployed base in 24 hours" situation. Indeed, but if pinning were desired, all the device would have to do is call the mother ship at least twice per decade, it can then work for multiple decades. I agree for many devices that don't wander the web in search of the latest cute kitten photos, and just "call home", a single fixed cert is a more plausible security model than either WebPKI or DANE. -- 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 11:34:14PM -0400, Viktor Dukhovni wrote: > > On Apr 18, 2018, at 11:25 PM, Peter Gutmann > > wrote: > >> That's just silly. Really, 7.5 years (relative, not absolute) measured in > >> hours is plenty good enough, and more than outlives current device > >> obsolescence. This isn't subject to Moore's law or anything like it. > > > > I don't know what devices you work with, but for the ones where my code is > > used ten years is the baseline life expectancy, going out to 15-20 years for > > longer-life ones (I still have to deal with SSH bugs from the late 1990s, > > because the lifetime of the equipment that's used in is 20 years and > > counting. > > I think I've finally managed to get away from having to do SSLv3 within the > > last year or two). > > > > OTOH I doubt any of these devices will do pinning, they just bake in the > > certs > > at manufacture/provisioning, so I'm fine with any kind of lifetime. Just > > wanted to point out, yet again, that the entire world doesn't live in a "we > > can patch the entire deployed base in 24 hours" situation. > > Indeed, but if pinning were desired, all the device would have to do > is call the mother ship at least twice per decade, it can then work > for multiple decades. Exactly. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
