# SAAG (Session 1) @ IETF112
Tuesday, November 9, 2021, 12:00-14:00 UTC
SAAG chairs/security ADs: Roman Danyliw, Benjamin Kaduk

Original at: https://notes.ietf.org/notes-ietf-112-secdispatch#
Jabber: xmpp:secdispatch@jabber.ietf.org
Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=secdispatch&short=&item=1

## Agenda

### Introduction (ADs) - 10 minutes
slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-secdispatch-saag-session-1-chairs-slides-01

### Update on NIST PQC Project (Dustin Moody)
slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-secdispatch-saag-session-1-update-on-nist-pqc-project-01

* (John Mattson) How many changes are coming?
** A: Typicaly on minor changes; no major redesigns

* (Watson Ladd) There was a long gap with EC deployment due to IPR and performance concerns.   Are NIST's recommendations going to consider this?
** A: NIST is going to continue on after Round 3 and considering additional research to be responsive

* (Phillip Hallam-Baker) Could any of these algorithms be adapted to threshold approaches?
** A: This would be future work. Some of the existing candidates could be suitable, but there has been little analysis.

* (Eric Rescorla) Can you say a bit more about KEMs?
* ** A: At the onset we looked at DH replacements but nothing came in during R1.  There is not focus on this right now.

* (Stephen Farrell) Encumbered algorithms are a problem. I hope there won't be a number of options to choose from since this complicates standardization.
** A: Yes, We recognize this issue and have heard it from industry. 

* (Benjamin Schwartz) Have you looked at hybrid approaches with Merkle ...
** A: Yes, we are aware of the research in batch signing.  It is a consideration.

* (Ben Kaduk) Can you say a bit more about the expected key size expansion?
** A: The candidates are likely around a thousand bytes (at a minimum) for category 1 coming out of Round 1.

* (Mike Ounsworth) At the Florida workshop, there was an idea to consider hybrid scheme ...
** A: Unaware if there was follow-on work

### SAAG Open Mic
* (Florence/NCSC) Beyond the proposed PQC Agility (PQCA) WG, what coordination is going to happen on the PQC topic?
** A: (Roman Danyliw) Right now this is happening informally between LAMPS, IPSECME and TLS which are thre three WGs formally chartered with PQC milestones.  The proposed PQCA WG wouldn't take on work which could be done in an existing WG.  However, it could provide a forum to start discussions.

# SAAG (Session 2) @ IETF112
Thursday, November 11, 2021, 16:00-18:00 UTC
SAAG chairs/security ADs: Roman Danyliw (RD), Benjamin Kaduk (BK)

Original at: https://notes.ietf.org/notes-ietf-112-saag#
Jabber: xmpp:saag@jabber.ietf.org
Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=saag&short=&item=1

## Agenda

### Welcome, Administrivia, and Agenda Bashing (5 mins)
 
 - No SecDispatch portion today.
 
### WG and AD Reports (15 mins)
slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-saag-saag-session-2-chairs-slides-00

- COSE, no report
- DANCE, LAKE, TEEP not yet met.

- Richard Barnes (RB): OHAI most time reviewing proposed drafts, document adoption calls going to the list
- SECEVENT may be closing

- Sean Turner (SPT): MLS just sent summary to list, about to WGLC for their drafts

- Roman Danyliw: Held PRIV BOF, successful, support voiced for it. Some action items, will be revisions to draft-charter. In the coming weeks will have some community discussion. 

- Ben Kaduk AD Sponsored drafts: 

- Roman Danyliw AD Sponsored drafts
    - ers-asn1-modules: w/ RFC editor
    - eastlake-rfc6931bis just started processing 6931bis for updated URIs, need W3C concurrance before IETF LC

- ADs updated the Security wiki.  Looking for review if there are things that are missing.  This includes a list of 'typical SECArea Issues'

- There is a list on the datatracker which shows both AD's review queues.
    - https://datatracker.ietf.org/doc/ad/roman.danyliw
    - https://datatracker.ietf.org/doc/ad/benjamin.kaduk

- Thread on PQ agility - we pulled together a summary. We need some commentary on the mailing list to figure out how to proceed. 

### "Recommended" guidance for TLS for other WG (20 min, TLS WG chairs)
slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-saag-tls-iana-recommended-column-rfc8447bis-00


Joe Salowey (JS) presenting: There are more than two options (currently Y/N). 
There are multiple reasons for N. The proposal was to add '' (null) which would mean unevaluated.  The wg added D and L to mean deprecated and limited use. Giving 5 options.

Stephen Farrell (SFtcd): slightly more complicated than needed, can combine N & D. N likely needs an explanation.  Doesn't understand difference between N & L.  We should not use N for the meaning presented; conflicts with the ' ' as presented (unevaluated).


Stephen Farrell : The current state of play is better. None of the proposed suggestions are improvements. What does "not evaluated by the IETF" even mean? People will come and argue it. Anything more than one negative value is useless in my opinion.

Hannes Tschofenig(HT): In the start of the slides you said "People have different perspectives etc.". TLS is often used outside the Web space, and sometimes there is some ignorance of non-Web cases. People say "non-Web is not general use". We have separate documents, etc. defining all these things. It would be fine if people read the documents, but they just look at the table. 

Joe Salowey: (missed clarifying question to Hannes)

Phillip Hallam Baker (PHB): I'm also a "two-state"-er. We eshould not distinguish between stuff we don't recommend and the stuff we have not evaluated. We should have one column of "we have evaluated this and approved it." The only way we have of evaluating crypto is through a multi-year crypto competition. We shouldn't be in the business of evaluating crypto. I want the smallest number of approved algorithms as possible, preferably no more than two. We should just give people code points and no evaluation. 

John Preuß Mattsson (JPM): I see nowehere in the document where it says this is for general use. 

Joe Salowey: Column recommended use vs. support is just a mistake on Joe's part.

John Preuß Mattsson: This shows that this is hard to understand.

Yoav Nir (YN): One of the things that 8447 did that I thought was wrong was that it made the same column for all the IANA registries for TLS. This makes sense for cipher suites, but what does it mean for, say, extensions. Three values of no / yes / read the document are all that we need.

Rich Salz: use this to the "die die die" - need to change; we need to change the ' ' to something that is a character.  Any values selected, it should be unabigiously understand what they are.  Need an algorithm that is determinable so that the reviewers can put the feedback in the table; the reviewers (of which is 1) don't want to be doing their own qualification judging.

Watson Ladd (WL): I see a lot of discussion about wanting to do not recommended. Really I think we should be making changes here as the start of the deprecation process. When we say about limited use, I'm not really sure what the value is. Also "" is a bad idea. 

Yaron Sheffer (YS): If we want to have documents that explain why things are deprecated or not recommended for use, that would be okay, but then we have to chase possible other authors of the original work; it creates coordination issues, and its hard to do; 7525 did it well to deprecate things; maybe do that more than every 5 years

Joe Salowey: Are you concerned that it's a coordination issue, or should we not be deprecating things.

YS: I think it's currently a coordination issues, but I'm also not sure we should be deprecating things.

Ekr: Yes we absolutely do need this column for extensions, lots of extensions, 3TLSP1 (?) that aren't created by TLSWG I needed TLS SALT password protect password salt, etc. We need three things, this is good, this is bad, and we haven't looked at it.

This is just a column to memorialise the decision that the IETF already made. We're already doing all these things, this is just recording that. 
THere are a bunch of cases where we've had to make unpleasant compromises with the security of the system e.g. CCM8, for things like CPU, so they should get their own marker. 

Joe Salowey:  makes sense.

Sean Turner: Should we hum on DKG's idea of 2, 3, maybe more?

Joe Salowey: The discussion suggests that N and '' can be combined as they're more states than anyone has asked for. The could still be debated about what D means.

Sean Turner: Options for hum is status quo, increase to 3, or more. 


Results:
Status Quo (Y/N)
| Hand | No Hand | Participated | Room | 
| --- | ---| --- | --- | 
| 15 | 20 | 35 | 117 |

Yes / No / Bad (winner)
| Hand | No Hand | Participated | Room | 
| --- | ---| --- | --- | 
| 32 | 16 | 48 | 117 |

More
| Hand | No Hand | Participated | Room | 
| --- | ---| --- | --- | 
| 18 | 24 | 42 | 117 |

Sean Turner: Call for write-ups

Ben Kaduk: UTA group vs having a column at all discussion from chat should continue on the list.

Roman Danyliw: Other topic for the list is what happens to the 'L' category.

Sean Turner: You can add references to the references column. That's what it's there for. A lot of people aren't reading the documents referenced in the IANA section, but at some point we have to push them to do a little work. 

Chris Inacio: automotive use cases, do those algorithms (or extensions) get 'N' for general use cases, but are 'ok' for the automotive case?

Sean Turner: I was confusing the algorithm and extension uses in my head, references get pulled in there. With an extension it's perhaps a little more direct. 

### Open Mic (remaining time)

none