Minutes IETF99: lamps
minutes-99-lamps-00

LAMPS Session at IETF 99
17 July 2017

Executive Summary

All of the deliverables in the current charter are with the IESG.  Three
potential work items have been suggested for a re-charter.  There was a
lot of interest in re-chartering to work on rfc6844bis and the addition
of the SHAKE128/256 and SHAKE256/512 algorithms for PKIX and S/MIME.
There was almost no interest in including the specification of a
first-issued certificate extension in the re-charter.


0)  Minute Taker, Jabber Scribe, Bluesheets

Yoav Nir will take notes.
Jim Schaad is Jabber Scribe.


1)  Agenda Bash

No agenda changes.


2)  Any issues from documents that have been sent to the IESG
    a)  draft-ietf-lamps-rfc5280-i18n-update
    b)  draft-ietf-lamps-eai-addresses
    c)  draft-ietf-lamps-rfc5750-bis
    d)  draft-ietf-lamps-rfc5751-bis

No comments have been received on any of these documents.


3)  Proposals for additional work items

All of the deliverables in the current charter are with the IESG.  Three
potential work items have been suggested for a re-charter.


3a)  rfc6844bis

Phillip Hallam-Baker suggests that the re-charter include a work item to
update PKIX CAA document.  The CA/Browser Forum will require mandatory
CAA validation starting 8-Sep-2017.  The original intent of the CNAME
and DNAME resource records in the DNS is obsolete because of CDNs.  They
want to administer various CNAMEs as one unit, but CNAME cannot be used
to distinguish between the two needed use cases.  A prefixed SRV record
seems like a better approach.  An update to RFC 6844 is needed to
address this situation.

Proposed charter text: "Specify a discovery mechanism for CAA records to
replace the one described in RFC 6844".

Sean Turner: Yes, let's do it.

HUM to include rfc6844bis in the proposed re-charter.  Many for yes;
silence for no.

Phillip Hallam-Baker volunteered to be editor.


3b)  Adding SHA3 to PKIX and S/MIME

Quynh Dang (NIST) suggested that the SHAKE128/256 and SHAKE256/512
algorithms be specified for use with PKIX and S/MIME as a backup to
SHA-256.  There are no know concerns with SHA-256, but it is prudent
to have an alternative available.  The SHAKE algorithms offer better
performance than other members of the SHA3 algorithm family.
    
Jim Schaad: How exhaustive of a signature algorithm list are you
proposing?

Quynh: They are efficient functions.

Russ Housley: Which set of signature algorithms would you like to use
with the SHAKE functions?

Quynh: They're good for them all.

Quynh: Don't need the HMAC construction for use with the KECCAK.

Jim: The problem is education. People don't know that you can use SHAKE
without HMAC.  Implementations would need to be changed to not do HMAC
for AuthenticatedData.  Everyone is used to using HMAC in this context.

Sean Turner: I don't know we need to pick the actual curves for ECC
signature algorithms right now.  We thought about RSA-PSS and ECDSA,
but we do not need to pick now.

Eric Rescorla: Why? Isn't the SHA2 family good enough?

Quynh: Just in case we find a problem with SHA2.

Eric: We've been trending away from defining points without a clear
advantage.

Quynh: They are very secure.

Eric: SHA2 has a wide margin.

Quynh: SHA3 has an even greater margin. 

Eric: It's just another algorithm.

Phillip Hallam-Baker: We need two algorithms for each primitive: One to
use, another as a spare.  And make them rather different.

Sean Leonard (Jabber): Aren't algorithm agility and cryptographic
diversity sufficient reasons in and of themselves? Also, software
testing of modularity and interoperability is important.

Jim: There is a reason to do the AuthenticatedData stuff with SHAKE.
Since it is one-pass it is going to be faster.

Eric: Where do you use MACs that is not replaced by AEAD?

Russ: There are a few places where confidentiality is not needed.

Bron Gondwana: Having a spare algorithm that is not routinely used is
not enough.

Phillip: Ed448 already includes SHA3. So, this would not really be
adding code. Just adding code points.

Quynh: If you have a code point, some people will use it.

Eric: We have code points for SHA-512, but almost nobody uses SHA-512.

Bron: Some implementations will support it wrong, but nobody will
notice until you have to use it. It needs to be used all of the time
to know that it works.

Max Pala: I think the agility argument is sufficient.

HUM to include the SHAKE functions in the proposed re-charter.
Many for yes; silence for no.


3c)  An first-issued certificate extension (Phillip)

Phillip Hallam-Baker suggests that we specify a first-issued certificate
extension. This is not a new idea; it was previously presented in
Chicago, July 2007. The age of certificate is useful, because an old
certificate is evidence of longevity.  It is like "Member since" on a
credit card. And now, short-lived certificates are coming back (see the
ACME session this Friday).  It offers user accessible safety information,
like "established 1977". Some people object to this extension, saying that
they do not want to deploy it.  Other say that PKIX doesn't work. Others
say the information is available in Certificate Transparency logs.
However, Phillip says that the CT logs do not offer the information in a
way that users can understand it. It requires more processing.
        
Robin Wilton: From the user perspective: you get a warning about a recent
certificate. Is this going to happen a lot?

Phillip: Security UI is garbage.

Robin: So how can we avoid the bad stuff. Most users would not see it
at all.

Paul Hoffman: First Issued by whom?  Same CA? Another trusted CA?

Phillip: There are ways of doing it. Sign the new CSR with the old key.

Eric: Which relying parties will use this information?

Phillip: Not in primary chrome, but while looking at the certificate by
clicking the padlock.

Eric: Which relying parties are interested?

Phillip: We want to tell people how to be safe online, but we don't have
a way to tell them how.  This is one piece of information might help.

Rich Salz: Useful in email.

Sean Turner: Last time we said it was lock-in to one CA.

Jeff Hodges: Don't understand how to link them. I can get owned at any
time.

Phillip: Bad sites are usually short-lived.

Stefan Santesson: It's targeting the wrong end of the problem. The
CA/Browser Forum should need to define it on the policy side. The
extension is the easy part.

Phillip: In ACME we're defining the validation criteria.

Sean Leonard (Jabber): Is this actionable by an end-user?

Paul: I don't want to build the chain and sign new certificate signing
request (CSR) with production key. Let CAs do it. One CA could lie.

Yoav Nir: Don't think it's a good signal to make decisions.

Eric: Doesn't seem like it's useful on the web.

Bron: Banks would send an email to all customers that the name/date is
going to change. An attacker would do the same.

Phillip: It can help users determine whether this is the good or bad
part of the Internet.

Rich Salz: You can't define (algorithmically) good vs bad areas on the
Internet. How long you've been paying a CA is not a good indicator. Yet,
it may be useful for email.

HUM to include the first-issued extension in the proposed re-charter.
Silence for yes; many for no.