On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters <p...@nohats.ca> wrote:
<snip> > > > 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
