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
