Re: [saag] Notes from SAAG meeting today

[Stephen Farrell <[e-mail]>]

Thanks Hannes. And also thanks to Mike Jones for notes and
to PHB for watching the jabber room

S.

On 26/03/15 19:59, Hannes Tschofenig wrote:
> 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.
> 
> 
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>