Minutes IETF104: tls
minutes-104-tls-02

TLS working Group IETF 104
Monday, 25 March, 2019
Prague, CZ

# Working Group Drafts

## TLS 1.3 Extension for Certificate-based Authentication with an External
Pre-Shared Key - Russ Housley

- Draft defines an extension to the TLS handshake, adding an optional parameter
allowing the External PSK to be combined with EC(DHE) as secret inputs to the
key schedule.

- Watson Ladd: does this enable the sending of early data?

- RH: No; explicitly stated to be out of scope in the draft.

- ANO: formal review would be desirable.

- Ekr: don’t think we should pass this until someone has implemented it.

- RH: as the first slide notes, this is experimental.

- one hand in response to question about implementations.

- * Next Steps: additional review (probably WGLC).

# Individual Drafts

## TLS Resumption across Server Name Indications for TLS 1.3 - Erik Sy

- TLS 1.3 recommends against, but doesn’t give a good indication of what
criteria to consider, or a signaling mechanism to say if the server supports
Resumption.

- Performance benefits, CPU time and elapsed time improvements may be valid
criteria - TLS extension would be needed to signal that this option is
available, e.g, a simple flag.

- Privacy impact could be reduced by enforcing shorter session lengths.

- Ekr: where should the extension go? - in the EE. Needs to be made clearer in
the doc.

- Ekr: should also be clear about whether resumption should require a fresh DNS
request

- Ekr: is a 1-bit flag really sufficient? - yes, otherwise would need to
specify a list of values for which Resumption is OK, and that would make
implementation harder.

- Ekr: should TLS, in principle, define a general-purpose extension space
rather than a bunch of specific flags?

- Yoav Nir: 1-bit flag may introduce address space/scope clashes at the server,
and different servers might have different requirements. Not a good idea to
allow reconnection to “any server”. - Server identification could be aided by
reference to the X.509 cert.

- Victor: recommends using a session ticket extension for this, not the
handshake itself.

- Victor: shortening the acceptable resumption period, as proposed, is
rational, but privacy implications probably need further examination. - 10
minutes is a figure of merit.

- Nick Sullivan: Where an X.509 cert has broad scope (across multiple servers),
additional parameters may be needed to ensure Yoav’s concern isn’t an issue.
Relying only on the -.509 cert makes unreasonable assumptions.

## Importing External PSKs for TLS - Christopher Wood

- TLS 1.3 imposes restriction on PSK usage with hash functions; TLS 1.2 did not
impose this restriction - so the resulting incompatibility (and potential for
inappropriate use of PSKs)  must be handled (ideally) without changing the key
schedule.

- Christian Huitema: working on a draft that generalizes DNS-SD technique for
external PSK identifiers in TLS.

- Jon Mattsson: question about using one hash algorithm to generate keys for
use with another.

- ANO: Does the PSK constitute a channel binding? Depending how the External
PSK is generated, this and the Resumption issue may overlap. A subsequent
session has no way of knowing how the previous session was established.

- Ekr: reusing hashes as proposed is secure. [Discussion inconclusive, needs
further examination].

- * No objections to adoption as a work item. Take to list.

## TLS Client Network Address Extension - Tommy Pauly

- Purpose: NAT detection in secure transport protocols

- Relates to these drafts specifying extensions:

- TLS, draft-kinnear-tls-client-net-address

- QUIC, draft-pauly-quic-address-extension

- Wes H.: is this specific to NATv4? - it applies everywhere.

- Wes H: Why is this a TLS-specific problem? - for QUIC, this is a transport
handshake question. For TLS, it would be more complicated to put it elsewhere
(?).

- DKG: what would a client do with this information? - the only real purpose of
this is to check that you’re not behind a NAT.

- * Discussion moved to the list for timekeeping reasons.

## Using Identity as Raw Public Key in Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) - Haiguang Wang

- Using Identity Based Signature exempts the server from having to maintain
records of the binding between a raw public key and the entity presenting it.

- * Next steps: ask to reserve specific code points for this mechanism to use
in implementation and testing.

Tuesday, 26 March, 2019

# Working Group Drafts

## Deprecating TLS 1.0 and 1.1

- TODO: update to deprecate DTLS 1.0

- Update to require NNTP to do the right thing

- * Hearing no objection, headed for WGLC

## DTLS 1.3

- Issue 78 - we will say MUST limit amplification until the path is validated
somehow.

- - … and we will separately say that though there is a CID, there is not a
migration piece - that is, endpoints don't send to new addresses in response to
receiving valid records from those addresses.

- Issue 72 - No change.

- Implementation status - NSS, Mint, mbedTLS.

## Cert Compression

- Add decompressed certificate to transcript?  No.

- * Will write up changes, then WGLC.

## Delegated credentials

- * Ready for LC? Yes, most likely.

## ESNI

- Current solution with PR#137 as an extension? Unclear from the room.

- Will an ESNI RRType Diverge from the A/AAAA results?

- [[lots of discussion, no resolutions]]

# Individual Drafts

## OPAQUE in TLS 1.3

- We should wait for CFRG to opine.

- Cisco has a use case, some possibility of web API?

- * No action, due to novelty.

## Hybrid key exchange

- Probably too early, given that research on combinations still active.

## CWTs in TLS / DTLS

- Would need to restrict to PoP tokens.

- * No action, due to novelty

## Fake SNI

- Should be compared to earlier draft on attacks against SNI approaches.

- * No action, due to novelty.