Sean et al.,
<hat="individual">
I agree with Paul and Yoav and think the coordination between dane and
websec on HSTS and key-pinning is ok. Both WGs are aware of potential
coordination issues when mechanisms in both (DNSSEC and HTTP header)
will be implemented eventually. I don't think we need an operations
statement yet. Maybe at some point in the future an informational Best
Practice or if you wish a Std Track can help.
With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning,
I am not so sure about potential conflicts here and whether we need or
want both.
</hat>
Best regards, Tobias
Ps.:
<hat="WG chair">
And on a personal note, one thing I am not so happy about is that I can
see from the tls-tack draft, that the authors are aware of key-pinning
(which is nice) and perceive that there would be flaws, yet they chose
to not post their comments on it to websec nor inform the WG about their
new draft.
To make it easier in the future to coordinate the two drafts and
possibly discuss and decide whether to boil down to one, it might make
sense to inform websec about draft-perrin-tls-tack and have a discussion
about it at some point there.
Just my 5cents.
</hat>
On 05/06/12 23:01, Paul Hoffman wrote:
On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote:
The similarity of pinning and DANE has been discussed before. DANE relies on
DNSSEC being deployed, which key-pinning does not.
Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the
client being able to establish a TLS session using non-key-pinning semantics.
Key-pinning in TLS relies works with any lower-layer protocol and relies on the
client being able to establish a TLS session using non-key-pinning semantics.
Come to think of it, the draft needs a section comparing with DANE, but that's
for another thread.
draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead
of the pins getting attested to in HTTP headers, you have a special
public/private key pair, that you use to sign the SPKI from the server
certificate within the a TLS extension. Like key-pinning there's a TOFU element
here, because the client only learns about the special key when it encounters
it in a TLS handshake.
The obvious question is why would we need both key-pinning and tack.
It would be clearer if you said "both key-pinning in HTTP and key-pinning in TLS
(tack)".
--Paul Hoffman
_______________________________________________
saag mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
