On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
