Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 13/12/2013 21:43, Yoav Nir wrote:

> I mostly agree with the facts presented below. However: - I object
>  to characterizing this as a "cryptographic protocol".

Fair enough. Poor choice of words on my part. ALPN is a metadata
extension to the cryptographic protocol, TLS.

> [...]we now have TLS tell us whether there's HTTP/1 or HTTP/2 
> inside.

The I-D doesn't seem to limit this to HTTP/1 or HTTP/2: it's a general
extension, which suggests a general use case.

If HTTP/(1|2) is all it's really intended to be used for at this time,
(your and Martin's response makes me think maybe it is), then perhaps
we SHOULD only use it for that at this time.

I think that would substantially weaken my objection. How would others
feel about that?

And then later (TLS 1.3?), if we can encrypt the ClientHello [How?
Ed25519+Elligator2 key from DNSSEC, or something? Hm... not sure.],
then ALPN is fine. That might be a way forward, perhaps.

> - Mass surveillance is a concern. It is not the only concern.

I agree (though it is of growing importance). Little metadata leaks
can still be important where they intersect.

> We haven't heard anyone explain what good knowing the version of 
> HTTP does to a nation state adversary.

Hypothetical case study:

If NSA had, for example, a practical attack on the RSA-RC4-(SHA|MD5)
ciphersuites that used likely known-plaintext prefixes ("GET /"...?)
along with biases in the keystream to, as they would say, "enable"
partial key recovery, ALPN would mean they don't even have to guess
which prefix to try, and might be able to make it easier for non-HTTP
use of TLS.

Of course, that's just my own guess, and the BIG vuln there is RC4
(which can be (I hope) dealt with by Adam's draft).

ALPN would, I appreciate, be a help in packet classification/shallow
analysis, mostly if more widely deployed among other protocols.

I note Stephan's comments about NPN's own leaks, and so NPN could be
more useful to them in "CNE" (hacking), when the gloves come off.
There are benefits and drawbacks to both - I accept that.

> - The chairs did not ignore the requests. They rejected them.

They said that no substantive new information had been presented since
the initial consensus call and therefore the consensus should stand.
(They did state that objections could be raised during IETF LC: that's
what's happening now.)

The disclosures re: BULLRUN and the IETF 88 TP seemed simply
unaddressed. I find that baffling. It is, as you say, rushed. It looks
like railroading, and I'm sure all want to avoid that appearance.

If the WG indeed knew then what we know now, then if we took a quick
consensus on-list, it'd have a similar result, and all would see that
it has been reached openly and transparently, which would address the
concerns that have been raised?

> While I prefer ALPN, I wouldn't consider it tragic to have had 
> NPN.

Similarly, I prefer NPN, but I'm not vehemently against ALPN,
particularly if limited in scope to HTTP/1 or /2 until ClientHello can
be encrypted in TLS 1.3.


On 13/12/2013 22:46, Martin Thomson wrote:

> As the editor of the spec that stands most to be affected by 
> faffing around here, I'd be strongly opposed to further delays.

Sorry! I do thank you for baking TLS in - I feel that's important -
and I really do apologise for the 'faff'. (This is not really how I
wanted to introduce myself, believe me!)

I feel that, as an extension to a protocol with a billion-dollar
target painted on it, it needs to be thought through, not rushed through.

I want to make sure legitimate concerns raised on-list are addressed,
not shortcutted, and that a transparent consensus, with current
information, not stale, can be reached.

A week or so, maybe?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSq6teAAoJEOyEjtkWi2t6WvUQAJgCudaxqlway/54sjALvc0+
lHqJJD93zvPOP5zUzWQn/UaSE07ky4GviCIGfDkeKCtPlvUOX6gaUDg785o9QB//
FjT3Fp4s+81vMux0/dtZQmqAfMjYlibr+6Ak/4iL3Q1oiV0XmCdDRAs4dxn2oYy8
0wxUtyGVxsGN8U6hyuyIP1GbrA/a4RJXf2dF7/mZnP3AfrTZJmfTUgTgeC2u1kAj
vv13S4kg8hgm+2VzKsgHisPz10F+LvkAwXrdAEQPNSVmE7Fy9kkXjEnmSnpi/RvH
LKGZGvB+kXMJnjZdz2HvD4Tgvxz9cCB7/jXfsycj1bZtyWUUU7xQvoGkvjgS6/LG
hXAfgXWDTEraIrkCmZPb2Ru1rriSjxYdWJAdsFPh64bS+0VBzhuooyyt6Ic1u3hT
Gid48dH36++gG8ZzaZfN3RbpJgZX951xUzePKQdk8IGmwbQG4yihTqJIyBsxaP71
pAp0GSmH38SgTyQb84zwObpQXChxBCOhAMCtjtA5wWEoTbU5AYWNl2NIegOpaFzj
YhsXff41pWC7TZIAuM0mXgCZEQoKi3D2lMWCMMbfS5Ky/cKMDx2vg2ZWGtihTjpN
qdkqhz3TPIJ75SLecDndco4TUp///g3Y13mCdfETRBSyO7JLXIxorm+FSF5/D8uX
6clY6ac9beSNDfGPsumf
=wcSZ
-----END PGP SIGNATURE-----