Re: [Taps] Benjamin Kaduk's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Tommy,

also inline.

On Wed, Apr 22, 2020 at 10:23:51AM -0700, Tommy Pauly wrote:
> Hi Ben,
> 
> Thanks for the detailed review! You can find an updated version of the document here:
> 
> https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html <https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html>
> 
> We did rename IKEv2 + ESP to simply IPsec, at the recommendation of ipsecme. We explain those individual protocols in the IPsec section, but do not reference them elsewhere.
> 
> Responses to your specific points inline.
> 
> > On Apr 8, 2020, at 3:35 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-taps-transport-security-11: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > I do wonder whether the Generic Security Service API (RFC 2743) was
> > considered by the WG in the production of this document.  It reflects a
> > somewhat dated snapshot of what was believed to be necessary security
> > APIs, but may not be entirely without value for this type of survey.
> 
> Thanks for the pointer to that document. We did review it (and I for one had not seen it before!). We chose not to add a reference for now, as there didn’t seem any obvious place to put a reference. That document seems to specify a specific generic API, whereas we’re more talking about how the shape of security protocols fit into transports.

Thanks for taking a look.  I can't say I'm surprised that it ended up not
really matching what you're doing, but think it was worth the time to
check.

> > It's a little surprising to not list a reference for QUIC in its
> > mentions in Sections 1 and 3, with the first reference occuring in
> > Section 3.3.1.
> 
> We’ve moved the reference for this earlier in the document.
> > 
> > Section 1
> > 
> >   set, protocols that do not offer new features are omitted.  For
> >   example, newer protocols such as WireGuard make unique design choices
> >   that have implications and limitations on application usage.  In
> > 
> > nit: "implications for" and "limitations on”.
> 
> Indeed! Fixed.
> > 
> >   protection.  Despite these improvements, neither protocol sees
> >   general use and both lack critical properties important for emergent
> >   transport security protocols: confidentiality, privacy protections,
> >   and agility.  Such protocols are thus omitted from this survey.
> > 
> > I don't think I see how TCP-AO and IPsec AH lack "agility".  Could you
> > clarify what was intended?
> 
> Removed this, and just list confidentiality and privacy protections now.
> > 
> > Section 1.2
> > 
> >   It is not a goal to allow software implementations to automatically
> >   switch between different security protocols, even where their
> >   interfaces to transport and applications are equivalent.  Even
> >   between versions, security protocols have subtly different guarantees
> >   and vulnerabilities.  [...]
> > 
> > Another impactful distinction between security protocols is in how they
> > name and authenticate the communications peer -- I can't imagine writing
> > a useful API that tries to abstract out the X.509 DNS-ID naming for TLS,
> > SSH host key fingerprints, etc.
> 
> Good point! Added:
> 
> "Different security protocols also can use incompatible notions of peer identity and authentication, and cryptographic options. It is not a goal to identify a common set of representations for these concepts."

Thanks.

> > Section 2
> > 
> > Should we reference RFC 8095 at the appropriate definitions [that we
> > duplicate from it]?
> 
> Added the reference.
> > 
> >   *  Transport Protocol: an implementation that provides one or more
> >      different transport services using a specific framing and header
> >      format on the wire.  A Transport Protocol services an application.
> > 
> > (whether directly or with an intermediating security protocol?)
> 
> Used your suggested text.
> 
> > 
> > Section 3.1.1
> > 
> >   protocol.  The handshake protocol is used to authenticate peers,
> >   negotiate protocol options, such as cryptographic algorithms, and
> >   derive session-specific keying material.  The record protocol is used
> >   to marshal (possibly encrypted) data from one peer to the other.
> > 
> > My inference is that the "possibly encrypted" is supposed to refer to
> > the encryption performed by the TLS record layer itself, as opposed to
> > having already-encrypted data supplied to TLS as "Application Data".  If
> > correct, I'd suggest rewording to "is used to marshal and, once the
> > handshake has sufficiently progressed, encrypt, data from one peer to
> > the other".
> 
> Used your suggested text.
> > 
> > Section 3.1.2
> > 
> > DTLS doesn't provide "the same security guarantees as TLS" in the
> > general case.  Specifically, redord replay detection is only optional in
> > DTLS whereas it is inherently provided in TLS.
> 
> We added a reference to DTLS 1.3, and shameless lift the text from that draft:
> 
> "DTLS modifies the protocol to make sure it can still provide equivalent security guarantees to TLS with the exception of order protection/non-replayability."

Oh good, someone other than me has put some thought into whether that's the
only point of divergence, becuase I did not put a huge amount of thought
into it...
Reusing the text from DTLS 1.3 sounds reasonable (though I guess my AD
Evaluation of DTLS 1.3 could in theory produce changes ... all the more
reason to clear that part of my backlog)

> > Section 3.4.2
> > 
> >   WireGuard is an IP-layer protocol designed as an alternative to IPsec
> >   [WireGuard] for certain use cases.  It uses UDP to encapsulate IP
> > 
> > Please move the location of the reference; it currently scans like it's
> > a reference for IPsec(!).
> 
> Good point, fixed!
> > 
> > Section 5.1
> > 
> >   *  Identities and Private Keys (IPK): The application can provide its
> >      identities (certificates) and private keys, or mechanisms to
> >      access these, to the security protocol to use during handshakes.
> > 
> > I think it would be more accurate to say "provide its identity,
> > credentials (e.g., certificates), and private keys" -- a certificate is
> > not exactly an identity, but rather an attestation thereof provided by a
> > (nominally) trusted authority.  Not all security protocols use
> > certificates in all cases, so I also think the "e.g." is appropriate.
> 
> Fixed.
> > 
> > Section 5.2
> > 
> >   *  Source Address Validation (SAV): The handshake protocol may
> >      delegate validation of the remote peer that has sent data to the
> >      transport protocol or application.  This involves sending a cookie
> >      exchange to avoid DoS attacks.
> > 
> > I'm not sure I understand the intent of using the word "delegate" here.
> 
> Changed to "The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.”

Ah, thanks.  You would think that the name of the bullet point being
"source address validation" would key me into using that interpretation of
"validation" and not a cryptographic one, and yet I still managed to
confuse myself the first time I read the old text.

Thanks for the updates!

-Ben

> >   *  Mobility Events (ME): The record protocol can be signaled that it
> >      is being migrated to another transport or interface due to
> >      connection mobility, which may reset address and state validation
> >      and induce state changes such as use of a new Connection
> >      Identifier (CID).
> > 
> > I think it's expected that DTLS 1.3 will do this (though I note that you
> > aren't currently referencing DTLS 1.3).
> 
> Added a reference to DTLS 1.3 and listed it here.
> > 
> > Section 8
> > 
> >   omitted from this survey.  All security protocols surveyed generally
> >   improve privacy by reducing information leakage via encryption.
> > 
> > nit: I suggest "improve privacy by using encryption to reduce
> > information leakage" (to avoid the misparse of "reducing (information
> > (leakage via encryption))").
> 
> Used your suggested text.
> 
> Thanks,
> Tommy
>