[saag] Notes from SAAG meeting today

[Hannes Tschofenig <[e-mail]>]

IETF-92 SAAG Meeting initial Agenda (120 mins)

1. WG/BoF/side meeting reports (10 mins)

See mails sent to the SAAG mailing list.

TLS VPN side meeting happened to understand what those are. Mailing list
will be requested.
Security discussion about IoT/6LO (Pavilion) scheduled for today (in the
evening).

Presentation about draft-mm-wg-effect-encrypt and soliciting
input/feedback.

2. Invited/offered talks
	2.1 Joe Bonneau/HSTS and HPKP in practice (30 mins)

Chrome also supports HSTSP but it has not been turned on. Firefox
supports it already since a few versions.

How to pre-load into Chrome? Enter the data into
https://hstspreload.appspot.com
Firefox: Talk to Richard Barnes

You have to have multiple pins (for redundant) for HPKP.

Cryptocat managed to brick themselves end of last year by changing the
certificate without updating the pre-loaded pins.

Ekr: How many sides out of the 1 M domains from Alexa are using HTTPS?
Joseph: Probably 30%. Don't remember. Out of these 30%, 1.1% use HSTS.
Jeff: The details are in the paper.

Yoav: Is there a tool to test HSTS?
Joseph: Not that I know. Student wanted to write something but then
didn't got to-do it.

Jeff: SSL-Labs they test various SSL/TLS features and they also test
HSTS. We could work with them to do more tests.
	
Richard: Active mixed content may be due to lack of support for HTTPS at
content distribution networks.
Joseph: Yes and scripts from ad networks.

PHB: Concerned about two different registries. The info should be in the
DNS. I proposed to have a harmonized format (in CAA record).
Joseph: There has not been a momentum to align the different proposals.

Joseph: I would suggest to per-default include sub domains. The secure
attribute for cookies could be re-interpreted as well.
Jeff: Thank you for doing this. Too often there are no such survey data.
It is great to have that data.
In terms of the pre-load list. The UI gets you into Chrome's list but
those new requirements where added by the Firefox guys but that only
gets you into additional browser lists.

Adam: The list is also being populated into other browsers.
Jeff: This is all ad-hoc. There might be a way to more formalize.
In terms of sub-domains I have to go back and count the number of mails
on that subject. The people in the room designing HSTS where browser
vendors and relying parties we thought it would be dangerous to include
subdomains when they are populated down the sub-domains. It is not clear
which is the better way.

Mark: Thanks for gathering this data. I appreciate the message on the
last slide regarding developer testing.
I am worried about the low adoption rate. We need to make them more
comprehensible.

DKG: Thanks for doing the work. I think we got the interaction with the
different specifications wrong and we have to keep this in mind for
future work.


	2.3 Adam Langley/QUIC (15 mins)
	
Ekr: Thinking about harmonizing the cookie exchange between DTLS/TLS.
Adam: We are meeting with the QUIC folks tonight.

Paul: Have you given the same presentation in TSVWG.
Adam: No.
Paul: You may want to talk to the TSVWG about QUIC to make them less
worried.

?: There was a presentation some time ago

Wes: Thanks for pushing the boundaries. One question about the
deployment: you talk about it being used today in Google/Chrome.
Adam: Users would not notice.
Wes: I am worried about that. You are lying to the users since they
don't get HTTPS but rather something else.

Adam: That would be a concern if the security concerns are less.
Wes: It has not gotten the same level of review. I am not sure that's true.

Allison: TCPINC is the place where these types of things should be
discussed.
A question: Is there crypto-agility in your proposal?

Adam: It is exactly the same as in TLS since we use the same certs.

Mark: The semantics of the HTTPS URI schemes are not bound to TLS.
Ekr: When we do TLS 1.3 we make experiments as well.


	2.4 Jan Včelák/Authenticated Denial of Existence in DNSSEC (NSEC5) (10
mins)
	
Adam: When the zone is signed offline then you are creating NSEC5
records. Does the DNS server need to have these keys online?
Jan: Yes. The keys are online.

?: I like the technology but I don't think it will be
Message files are a much bigger issue. Your paper don't support ECC.

Jan: We require deterministic signatures. If we use ECDSA then for one
name and one key there may be more than one signature.

Some years we were told that we need to support NSEC3. Given that
everything in DNSSEC is moving forward very slowly I think we should
just deploy DNSSEC instead of playing around with it.

Joseph: We worked on this topic as well. There is an ECC way to do it.
We went through the same problem and there is a way to do it but it is a
bit messy.

	2.5 Ladar Levinson/Darkmail (20 mins)
	
Jeff: I got a bit lost. I have a software I downloaded and I wanted to
send you a message. I have not contacted you before.

Ladar: You would type in the email address. The client would query the
DNS for a record. Once it has the record it has the signing key for that
domain.
Then, you contact that organizational domain. Subsequently, you query
the users signet and use the public key to encrypt the message with that
key.

Adam: Why did you choose two different curves?
Ladar: I wanted different curves for signing and encryption.

Ladar: Is the ChaCha TLS ciphersuite ever going to become a standard?
Sean: We are starting a working group adoption of the ChaCha TLS
ciphersuite.

Adam: Signatures are designed to provide integrity and authenticity but
not confidentiality.
Ladar: The signatures are inside the encrypted part of the message.

BarBOF happening this evening.

Adam: You asked for tree signatures. Merkle tree signatures are totally
fine.




	2.6 Paul Wouters/Opportunistic IPsec update (1 minute)

Paul pointed to the oe.libreswan.org.



	2.7 Eric Rescorla/Secure Conferencing (5 mins)

Adam: Does the key server know the key?
Ekr: Yes.
Adam: It does not need to be.
DKG: Happy to talk to you afterwards.

	3. Open-mic, ~30

Joe: Question about the QUIC talk. The information shown to the user
needs to correct.
Adam: It says QUIC. QUIC started with formal analysis of the crypto

Wes: My concern was not that there are many failures with TLS. The HTTPS
and the URI specification says that it is TLS.
I am not saying it is bad todo experimented but I want to know whether I
am experimented on.

Adam: We cannot change the URI scheme. We also cannot change the icon
either.
Wes: I understand the need for experimentation.

Adam: We are not going to deploy another URI scheme again.

Paul: We could solve this using a pop-up, for example when downloading

?: Haven't there been a experiments with the lock icon?

Adam: We are experimenting with you all the time, for example, when
switching to ChaCha.

Ekr: There are three things: URI scheme, a lock icon and then the crypto.

Jeff: This is a layer 9 problem. You agree to it when you download the
browser.