Last Call: <draft-ietf-tram-alpn-06.txt> (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In the introduction of this document[1], the first example appears to
endorse the idea that a firewall would inspect a TLS handshake and
quash the communication if it saw an ALPN identifier that it didn't
like.

If I'm not misunderstanding this example, then it's contradictory to
the work that the TLS WG is chartered to do[2]:

"Develop a mode that encrypts as much of the handshake as is possible
to reduce the amount of observable data to both passive and active
attackers."

It would be disappointing if an RFC explicitly endorsed middleware
that tries to parse high-level protocols and interferes with the
network based on the result. There might not be much that we can do
about it, but we don't have to condone it.


Cheers

AGL


[1] https://tools.ietf.org/html/draft-ietf-tram-alpn-06#section-1
[2] https://datatracker.ietf.org/doc/charter-ietf-tls/

-- 
Adam Langley agl@xxxxxxxxxxxxxxxxxx https://www.imperialviolet.org





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]