Re: [Acme] Minutes from IEtf 99

[Daniel McCarney]

Hi Yoav,

Thanks for clarifying. I still think that the notes would be a better aid
for both the chairs and everyone else if they we're a closer representation
of the meeting contents and not memes.

I think it's safe to drop the discussion here. If the chairs want meme
notes for their aid I won't make a fuss about it. Thanks for engaging with
my feedback.

- Daniel


On Fri, Jul 21, 2017 at 11:25 AM, Yoav Nir  wrote:

> Hi, Daniel
>
>
>
> It should be noted that Richard’s notes are just an aid to the chairs
> (that's Rich and me now that Ted is moving on)
>
>
>
> The real minutes are what we will upload in a few days or weeks, and they
> are usually in plaintext form.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> *From: *Daniel McCarney 
> *Sent: *Friday, July 21, 2017 16:00
> *To: *Richard Barnes 
> *Cc: *Salz, Rich ; IETF ACME 
> *Subject: *Re: [Acme] Minutes from IEtf 99
>
>
>
> Hi Richard,
>
> Thank you! No need to apologize.
>
>
>
> On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes  wrote:
>
> Of course you're right.   I apologize.  I will go through the audio
> recording and produce some proper notes.
>
>
>
> On Jul 21, 2017 3:32 PM, "Daniel McCarney"  wrote:
>
> I think this is the second time (in my memory) the WG notes have been
> distributed in "meme form". At the risk of being the stick in the mud I
> want to express an opinion that "meme notes" are distracting and I think
> the time spent producing the memes would have been better spent capturing
> the content of discussions during the working group.
>
> I was unable to attend physically and the timezone delta made it difficult
> to attend virtually. Looking at these notes as they exist presently hasn't
> given me much understanding of the topics discussed. In the future could
> the WG consider returning to plain old ASCII for meeting notes and sticking
> to the content instead of punchlines?
>
>
>
> Thanks!
>
>
>
> On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich  wrote:
>
> Please take a look at the minutes/memes and post corrections by the next
> week.
>
>
>
> Minute-taker gets to choose if he accepts changed pictures or not J
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> Member, OpenSSL Dev Team
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Richard Barnes [mailto:r...@ipv.sx]
> *Sent:* Friday, July 21, 2017 11:02 AM
> *To:* acme-cha...@tools.ietf.org
> *Subject:* Memes
>
>
>
> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-
> TwWD82rd7QdwDCo5WNfkX41ae8/edit
> 
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Minutes from IEtf 99

[Yoav Nir]

Hi, Daniel

It should be noted that Richard’s notes are just an aid to the chairs  (that's 
Rich and me now that Ted is moving on)

The real minutes are what we will upload in a few days or weeks, and they are 
usually in plaintext form.

Sent from my Windows 10 phone

From: Daniel McCarney
Sent: Friday, July 21, 2017 16:00
To: Richard Barnes
Cc: Salz, Rich; IETF ACME
Subject: Re: [Acme] Minutes from IEtf 99

Hi Richard,

Thank you! No need to apologize.

On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes  wrote:
Of course you're right.   I apologize.  I will go through the audio recording 
and produce some proper notes.  

On Jul 21, 2017 3:32 PM, "Daniel McCarney"  wrote:
I think this is the second time (in my memory) the WG notes have been 
distributed in "meme form". At the risk of being the stick in the mud I want to 
express an opinion that "meme notes" are distracting and I think the time spent 
producing the memes would have been better spent capturing the content of 
discussions during the working group.

I was unable to attend physically and the timezone delta made it difficult to 
attend virtually. Looking at these notes as they exist presently hasn't given 
me much understanding of the topics discussed. In the future could the WG 
consider returning to plain old ASCII for meeting notes and sticking to the 
content instead of punchlines?

Thanks!

On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich  wrote:
Please take a look at the minutes/memes and post corrections by the next week.
 
Minute-taker gets to choose if he accepts changed pictures or not ☺
 
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
 
From: Richard Barnes [mailto:r...@ipv.sx] 
Sent: Friday, July 21, 2017 11:02 AM
To: acme-cha...@tools.ietf.org
Subject: Memes
 
https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82rd7QdwDCo5WNfkX41ae8/edit

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Minutes from IEtf 99

[Daniel McCarney]

Hi Richard,

Thank you! No need to apologize.

On Fri, Jul 21, 2017 at 9:38 AM, Richard Barnes  wrote:

> Of course you're right.   I apologize.  I will go through the audio
> recording and produce some proper notes.
>
> On Jul 21, 2017 3:32 PM, "Daniel McCarney"  wrote:
>
>> I think this is the second time (in my memory) the WG notes have been
>> distributed in "meme form". At the risk of being the stick in the mud I
>> want to express an opinion that "meme notes" are distracting and I think
>> the time spent producing the memes would have been better spent capturing
>> the content of discussions during the working group.
>>
>> I was unable to attend physically and the timezone delta made it
>> difficult to attend virtually. Looking at these notes as they exist
>> presently hasn't given me much understanding of the topics discussed. In
>> the future could the WG consider returning to plain old ASCII for meeting
>> notes and sticking to the content instead of punchlines?
>>
>> Thanks!
>>
>> On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich  wrote:
>>
>>> Please take a look at the minutes/memes and post corrections by the next
>>> week.
>>>
>>>
>>>
>>> Minute-taker gets to choose if he accepts changed pictures or not J
>>>
>>>
>>>
>>> --
>>>
>>> Senior Architect, Akamai Technologies
>>>
>>> Member, OpenSSL Dev Team
>>>
>>> IM: richs...@jabber.at Twitter: RichSalz
>>>
>>>
>>>
>>> *From:* Richard Barnes [mailto:r...@ipv.sx]
>>> *Sent:* Friday, July 21, 2017 11:02 AM
>>> *To:* acme-cha...@tools.ietf.org
>>> *Subject:* Memes
>>>
>>>
>>>
>>> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82r
>>> d7QdwDCo5WNfkX41ae8/edit
>>> 
>>>
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Minutes from IEtf 99

[Richard Barnes]

Of course you're right.   I apologize.  I will go through the audio
recording and produce some proper notes.

On Jul 21, 2017 3:32 PM, "Daniel McCarney"  wrote:

> I think this is the second time (in my memory) the WG notes have been
> distributed in "meme form". At the risk of being the stick in the mud I
> want to express an opinion that "meme notes" are distracting and I think
> the time spent producing the memes would have been better spent capturing
> the content of discussions during the working group.
>
> I was unable to attend physically and the timezone delta made it difficult
> to attend virtually. Looking at these notes as they exist presently hasn't
> given me much understanding of the topics discussed. In the future could
> the WG consider returning to plain old ASCII for meeting notes and sticking
> to the content instead of punchlines?
>
> Thanks!
>
> On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich  wrote:
>
>> Please take a look at the minutes/memes and post corrections by the next
>> week.
>>
>>
>>
>> Minute-taker gets to choose if he accepts changed pictures or not J
>>
>>
>>
>> --
>>
>> Senior Architect, Akamai Technologies
>>
>> Member, OpenSSL Dev Team
>>
>> IM: richs...@jabber.at Twitter: RichSalz
>>
>>
>>
>> *From:* Richard Barnes [mailto:r...@ipv.sx]
>> *Sent:* Friday, July 21, 2017 11:02 AM
>> *To:* acme-cha...@tools.ietf.org
>> *Subject:* Memes
>>
>>
>>
>> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82r
>> d7QdwDCo5WNfkX41ae8/edit
>> 
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Minutes from IEtf 99

[Daniel McCarney]

I think this is the second time (in my memory) the WG notes have been
distributed in "meme form". At the risk of being the stick in the mud I
want to express an opinion that "meme notes" are distracting and I think
the time spent producing the memes would have been better spent capturing
the content of discussions during the working group.

I was unable to attend physically and the timezone delta made it difficult
to attend virtually. Looking at these notes as they exist presently hasn't
given me much understanding of the topics discussed. In the future could
the WG consider returning to plain old ASCII for meeting notes and sticking
to the content instead of punchlines?

Thanks!

On Fri, Jul 21, 2017 at 7:23 AM, Salz, Rich  wrote:

> Please take a look at the minutes/memes and post corrections by the next
> week.
>
>
>
> Minute-taker gets to choose if he accepts changed pictures or not J
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> Member, OpenSSL Dev Team
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> *From:* Richard Barnes [mailto:r...@ipv.sx]
> *Sent:* Friday, July 21, 2017 11:02 AM
> *To:* acme-cha...@tools.ietf.org
> *Subject:* Memes
>
>
>
> https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-
> TwWD82rd7QdwDCo5WNfkX41ae8/edit
> 
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt

[Salz, Rich]

Sean, at the meeting we agreed to do more in this area; look for new content 
from the editors.


--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

> -Original Message-
> From: Sean Leonard [mailto:dev+i...@seantek.com]
> Sent: Thursday, July 20, 2017 7:17 PM
> To: ACME WG 
> Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-07.txt
> 
> I reviewed this draft.
> 
> The concerns raised about the textual transmission of certificates, have not
> been fully addressed. But at least they have been partially addressed, so that
> progress is appreciated.
> 
> However since it’s my bad that I have not had the time to flesh out a
> response, we can let this go if the certificates are just transmitted 
> “according
> to [RFC7468]”, and as text/plain. I would also advocate stronger language
> about the format, namely, that it is just -BEGIN CERTIFICATE- and 
> -
> END CERTIFICATE-, separated only by newlines (no other text,
> supplemental or otherwise). I also don’t see why a client “‘SHOULD’ verify
> that the ‘file’ contains only encoded certificates. “MUST” would be better,
> and closes security holes. (MUST is also essentially stated by the sentence
> that follows.) If there is any “SHOULD”, the client “SHOULD” verify that the
> public key of the certificate matches the public key of the submission. Also
> it’s not a ‘file’, it’s unnamed content.
> 
> Given that the payload is text (and, in particular, no supplementary text), 
> you
> may want to note that it’s charset=us-ascii. However that is the default
> anyway.
> 
> I can supply draft text if desirable.
> 
> Regards,
> 
> Sean
> 
> > On Jun 21, 2017, at 12:00 PM, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Automated Certificate Management
> Environment of the IETF.
> >
> >Title   : Automatic Certificate Management Environment (ACME)
> >Authors : Richard Barnes
> >  Jacob Hoffman-Andrews
> >  James Kasten
> > Filename: draft-ietf-acme-acme-07.txt
> > Pages   : 74
> > Date: 2017-06-21
> >
> > Abstract:
> >   Certificates in PKI using X.509 (PKIX) are used for a number of
> >   purposes, the most significant of which is the authentication of
> >   domain names.  Thus, certificate authorities in the Web PKI are
> >   trusted to verify that an applicant for a certificate legitimately
> >   represents the domain name(s) in the certificate.  Today, this
> >   verification is done through a collection of ad hoc mechanisms.  This
> >   document describes a protocol that a certification authority (CA) and
> >   an applicant can use to automate the process of verification and
> >   certificate issuance.  The protocol also provides facilities for
> >   other certificate management functions, such as certificate
> >   revocation.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-acme-acme-07
> > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Minutes from IEtf 99

[Salz, Rich]

Please take a look at the minutes/memes and post corrections by the next week.

Minute-taker gets to choose if he accepts changed pictures or not ☺

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

From: Richard Barnes [mailto:r...@ipv.sx]
Sent: Friday, July 21, 2017 11:02 AM
To: acme-cha...@tools.ietf.org
Subject: Memes

https://docs.google.com/document/d/18zB3ZiPGpqUi23qB-TwWD82rd7QdwDCo5WNfkX41ae8/edit
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ATIS/SIP Forum NNI documents for SHAKEN

[Mary Barnes]

HI all,

Per the discussion during this ACME WG session, here are the documents
related to draft-ietf-acme-service-provider and here's a general overview
of the activity:
https://www.sipforum.org/activities/nni-task-force-introduction/

SHAKEN (describes the use of STIR in the context of VoIP Service Provider
networks):
https://www.sipforum.org/download/sip-forum-twg-10-signature-based-handling-of-asserted-information-using-tokens-shaken-pdf/?wpdmdl=2813

SHAKEN: Governance Model and Certificate Management:
https://www.sipforum.org/download/joint-atissip-forum-standard-signature-based-handling-asserted-information-using-tokens-shaken-governance-model-certificate-management-atis-180/?wpdmdl=3360

Regards,
Mary
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Stale DNS and high-risk issuance

[Ilari Liusvaara]

On Thu, Jul 20, 2017 at 11:20:58PM -0700, Kevin Borgolte wrote:
> Hi Ilari,
> 
> 
> > The methods in base spec just fundamentially rely on security of DNS.
> > The only way to remove dependence on routing would be:
> >
> > 1) Deploy DNSSEC and
> > 2) Add acme-CAA record restricting validation to DNS.
> 
> This would indeed be an alternative solution to our proposal, as it
> would similarly solve the problem of DNS-related issues. However, a
> DNS-based solution would not be as practical for most ACME users (yet)
> because they might not have full control over their nameservers (the
> web interface of their registrar that they might have to use might not
> even support CAA), or it might require manual work to renew the
> certificate. Further considering regular key renewals, a DNS-based
> solution appears to be less practical and could hamper adoption.

Yes, requiring this would have very large impact, so it would be
nonstarter.

There are substantial amount of DNS APIs that can be used to automate
DNS updates for DNS validation, making DNS validation totally automatic
(and most of the time DNS validation is used, it is totally automatic).

The nasty part would be requiring DNSSec, which is substantially more
difficult than automated record updates.

> > > For example: Consider that Let's Encrypt is used by a service running
> > > a.example.com, where the A record of a.example.com points to 192.0.2.1 and
> > > 198.51.100.1, with the record pointing to 198.51.100.1 being a stale DNS
> > > record, and 198.51.100.1 being an address for a VM instance in a cloud
> > > provider's pool. If an attacker now finds a way to allocate 198.51.100.1,
> > > she might also use Let's Encrypt to obtain a valid certificate. The
> > > certificate request by the attacker is indistinguishable from the outside
> > > and from interpreting the certificate transparency logs from what the
> > > legitimate operator would do to fix the service behind 198.51.100.1, which
> > > previously went stale.
> 
> > Stale IP addresses cause problems when renewing (however, that does not
> > occur that often). Also, due to recent "fixes", IPv6 stale addresses can
> > be missed (there are just so many folks with busted DNS configuraiton).
> >
> > And I think that would also cause large amounts of problems for users
> > if the stale record is IPv4 (if it is IPv6, then "happy eyeballs" hides
> > the problem).
> 
> We are not 100% sure what you mean exactly here, but for us, the
> problem with stale DNS records is not with renewing itself, but with
> an attacker exploiting the stale DNS information combined with the
> high IP address churn (which we see particularly for cloud providers).

I would think that having any stale IPv4 addresses in the RRset would
cause major issues for users accessing the site.
 
> > In the "order flow" change, did put the CSR first so one can look up
> > the requested key first. However, this would cause major problems if
> > trying to change keys (and many (I am not among them) believe that
> > rotating private keys often is important).
> 
> Would you mind elaborate where this would cause major problems exactly
> when changing keys?

The ACME server can detect if the key requested is the same as the
last time.
 
> > This would also complicate "disaster recovery" where the previous keys
> > are lost (usually due to admin mistake, and backups being AWOL like
> > usual). You would not believe how often that happens (and I hear just
> > a small subset).
> 
> Correct, disaster recovery would be made slightly more manual by
> requiring a second channel to verify the request (e.g., setting a DNS
> record in addition to HTTPS). Although this might happen quite
> frequently, we strongly believe that we should opt for secure by
> default, instead of allowing a practical attack because of disaster
> recovery eventualities. The burden of our solution is not significant
> in that case (see below) and what is to be expected for recovering
> lost credentials (e.g., your email account): a second channel.

"slightly"? You obviously have very different definition of "slightly"
thn me.

At scale like LE, this would have large impact. There would be huge
amount of users locked out. They can't (mostly skill) to validate
using DNS or any othe second factor.

If I knew I was dealing with anything like that, I would basically
take HPKP-level precauntions (which are far beyond most users). And
which will lock the key in place (well, the key would be locked
for me anyway)


Basically, I think this would cause huge amount of problems for users
without much gain, hurting HTTPS adoption greatly.




-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme