Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

[Paul Wouters <[e-mail]>]

On Tue, 3 Jul 2018, Allison Mankin wrote:

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?
> 
> ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is
> something to be worked on in future too.

Reserved bytes are always under specified, that is why they are reserved.

For instance, yesterdy ekr filed a draft for encrypted SNI with this:

 	 struct {
 	           uint8 checksum[4];
 	           KeyShareEntry keys<4..2^16-1>;
 	           CipherSuite cipher_suites<2..2^16-2>;
 	           uint16 padded_length;
 	           uint64 not_before;
 	           uint64 not_after;
 	           Extension extensions<0..2^16-1>;
 	       } ESNIKeys;

 	 extensions  A list of extensions that the client can take into
 	      consideration when generating a Client Hello message.  The format
 	      is defined in [I-D.ietf-tls-tls13]; Section 4.2.  The purpose of
 	      the field is to provide room for additional features in the
 	      future; this document does not define any extension.

So there is a whole extension block with no specification and no idea
even if it would ever be needed. That is much weaker then the need for
TLS extension pinning.

Additionally, let me remind you of the direction that the solution
would take if this is punted completely to a new document:

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

The smithee draft is a terrible idea. We can do better.

Paul