Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Richard Barnes <[e-mail]>]

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