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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
